How to Organise Applications, Workspace, Projects... in the

Hi Ron,

I'll assume you've already read the other topic in here about projects. I'll also assume you're using 10.1B. I'm not going to suggest a single setup for you, but here are some additional things to consider. You have basically unlimited options based on how you prefer to work. Having a prescribed method within your company for every project may make supporting OEA easier. If all of your applications consist of server side, client side, include files and shared code then having a single way of doing things is a good thing.

Some things to consider.

Database connections: If you setup multiple workspaces, you'll have to manage databases connections between multiple workspaces. This means that if you change a database parameter that multiple projects connect to in one workspace, you'll need to export/import the database connections into the other workspace. With everything in a single workspace you can share database connections between projects.

Source code control: How does your source code control system handle the different projects? Is the code well separated into separate directories? If it is, then it makes the one workspace/multiple projects thing easier. I've found its helpful to have one workspace per version of the code with all the projects in a single workspace.

Project dependencies: If you have dependencies between projects you will need to manage this through propath settings. If making changes to one application tends to require changes in the shared source folder, it would make sense to go with option A spelled out above. This way any runtime dependencies between the shared folder and all the projects that use that code can be seen immediately. Having multiple workspaces (one for each application) would mean more switching between them to validate your changes between each application.

Project Modules Depending on the size of your applications it sometimes makes sense to split individual modules out into separate projects. If you don't have separate modules or they are not particularly large, then this doesn't make sense. The more projects you have the more settings management you have to do. Since you have multiple separate applications with only a single point of cross-over, then having one workspace per application, and having that one application split into multiple projects makes sense. The drawback to this is that you'll end up with many workspaces if you need to support multiple versions of your application

Project Setting Management: Each project that you have requires separate setup of the parameters. For example, if you have 5 projects in OEA, that means you have 5 sets of propath settings, and 5 sets of startup parameters to manage. It also means more memory consumption. Having 5 projects means having 5 copies of prowin32.exe running. Generally this means less than 10 MB using the default startup parameters, but it could become a problem if there are many projects within a single workspace. With a modern workstation with 1G of RAM, this shouldn't be a problem, but on older memory constrains systems this might be an issue.

Team Based Development: This one goes along with source code control. In a team based environment, everyone ends up sharing the code. This means that everyone working on a project needs to setup their environment the same way or the project settings that get shared need to be setup in a flexible manner. What is the possibility that a developer will need to work on one part of an application on a regular basis (e.g. server side) and not another.

If you read the other

thread here about this topic, I think that one might venture to say

that no one has quite figured this out yet. And, as I think that

from that thread and Matt's comments above, it is also clear that

one can't really answer the question about OEA in isolation because

it depends both on the nature of development at your company and

the other tools which you will be using.

Another consideration to throw into the muddle is that so far, the workspace from one version has not been compatible with the workspace for another version. Depending on how many project you have and how many applications, if you divide the applications into workspaces, you may find yourself with a fair amount of reconstruction work to do with each version change. Thus far, I have been through 10.1Abeta, 10.1A, 10.1Bbeta, and 10.1B, so it is a fair amount of nonsense. I hope that this stabilizes or there is a migration tool in the future, but it can mean a fair bit of work.

Depending on how interrelated these applications are, you also might want to take a look at this thread http://www.psdn.com/library/thread.jspa?threadID=2582&tstart=0 on namespaces. With the right use of namespaces, you could have everything under one workspace and use projects more in terms of released code, current development code, code in QA and that sort of lifecycle staging. It means more "stuff" in your base project, but it also means no artificial separation of shared code and no issues about not being able to check dependencies.

Note too that if you are wanting to use tools like ProRefactor and CallGraph, there would be real benefit to having all of the base code in one project.

You might want to take a look at the Multiple Versions thread in this forum. While that is still being clarified, it might have some impact on your workspace design if you have multiple Progress versions that you need to support.

Database connections: If you setup multiple

workspaces, you'll have to manage databases

connections between multiple workspaces. This means

that if you change a database parameter that multiple

projects connect to in one workspace, you'll need to

export/import the database connections into the other

workspace. With everything in a single workspace you

can share database connections between projects.

So all the advantages of having your code in projects vanish when you need to develop across those projects in your big workspace.

Let's say you have 15 developers, all going to the development database using TCP, twice (SQL and 4GL). Now, let's say I have 9 projects, 5 of them with lot's of activity.

Db connections: 30 + 5 * 15 = 105 remote connections

It would be great if I could reduce this number back to 30, but that means you need to be able to share one single prowin32 across the opened projects.

That's how I initially interpreted the Project References.

I had one master project, defining all the connections and opening them. The other projects would reference the master project and receive the same connection tunnel.

You might also want to check out Sunil's talk from Exchange this year at http://www.psdn.com/library/entry!default.jspa?categoryID=1380&externalID=3300&fromSearchPage=true

Yes, very interesting and good to put it into this thread.

But not addressing the problem of the simultaneous opened projects and how they each need their own db connection.

Thomas, would you agree that sharing the same prowin32 across multiple projects

makes sense? Or am I the only one here missing this feature?

Sharing the same instance works for you because you are working all projects against the same database, but isn't going to work for someone else where the project signifies a different database. I, for example, have a project which relates to my ERP code and then I have another project which connects to sports as a place for fiddling with things that I might want to send out as examples.

I think to accomplish what you want and still retain flexibility, "session" would have to become a named entity like DB connection and the rule could be that any projects with the same session name would share a prowin.