I am curious how it is that people are handing projects and PROPATH in OEA. The idea of a project being a separate set of related work appeals to me, especially when I have multiple ones going on at the same time, but I am finding it a bit clumsy to integrate with an existing code base which the project might reference and setting up the PROPATH and all that, so I am wondering how other people are using this feature.
Let me supplement that question with another, which might be related and that is how you manage workspaces relative to the fact that each new release of OEA seems to require a fresh start and will blow up if opened on a prior version's workspace. Or, maybe not very many people have discovered that little problem yet.
maybe my project needs / requirements are much simpler: I always create a new workspace when changing OEA / eclipse versions. All my projects (df / data / programs etc) are under subversion, so it is a very simple task to checkout a new project, enter the db connections and go.
Like a said, I have a simple environment (single db, temp-table db and empty reference db). I have 4 branches running (each a separate project in the workspace, dev, live, live branches and experimental)
So, your four "branches" are four projects in Eclipse?
It has been suggested to me offline that this needing to start over again on a new workspace is probably an indication of the immaturity of OEA as an Eclipse plug-in since it tends not to be required for other product version changes, even of Eclipse.
yes to your question. As for the workspaces, I like to have separate directories for the different versions just as I have separate directories for the different versions of OE.
So, you have permanent branches which really relate to development stage and aren't using "project" to contain all work on a given piece of work ... something I would like to be able to do in order to keep them separate when I have multiple projects going at the same time. It also seems like it would help in packaging things, e.g., for creating a zip file.
I have a workspace for each application, and projects for each development branch
Right, but not, for example, a project for an update to the Aged Trial Balance or 10.1B modifications to the collection classes and such.
Pre OEA I used cur, dev, tst, and cus directories for current released version, current development, testing & QA, and customer-specific code, but dev only worked cleanly when I was working on one project at a time. Now that I am working on a lot of framework stuff, I find that I am often working on more than one project at a time, but I have no way to easily separate them or, when done, to sweep one project worth into a zip for distribution.
Let me supplement that question with another, which
might be related and that is how you manage
workspaces relative to the fact that each new release
of OEA seems to require a fresh start and will blow
up if opened on a prior version's workspace. Or,
maybe not very many people have discovered that
little problem yet.
did you try this with the -clean start-up option ?
Yes. I actually have -clean on my shortcut so that I don't have to think about it as I make changes. I have had to use a fresh workspace for each new version install.
>>Right, but not, for example, a project for an update to the Aged Trial Balance or >>10.1B modifications to the collection classes and such.
Um, yes: we often create a new branch in subversion for testing / fixing a particular issue or a set of new functionality. We then use a project to work on that branch
But, it is a project in subversion, not in OEA?
it's a branch in subversion and a project in OEA
So, if you have dev, live, live branch, and experimental projects and you start to work on the Aged Trial Balance, does this mean you create an ATB project as well? Then what does in dev?
yes, I create a branch and project for each "unit" of work that we do. A unit can be a bug fix (if it involves a large amount of work), a specific release, experiments etc. I dont know if you use subversion, but it tends to lend itself to being able to have loads of cheap copies. Thus, when it creates a branch (which could be any of the above units) it is actually a copy of the entire project at the point of the branch. merging the changes back into trunk / live etc is a relatively trivial task
No, I'm not using subversion at this point ... and this might help explain why I am finding the overhead of creating the project in Eclipse and dealing with copying things in and out to be burdensome.
Oh, man, just start using it. It is such a time saver.
It's on my list ... but the list is rather full at the moment!
On a slightly different topic, do you separate source and compiled code? And how?
I am used to working with a series of base directories, e.g., cur, cus, tst, dev, etc. and each one has a src and a run subdirectory. I compile into the run directories with the same path relative to the base of the propath and so end up with two duplicate directory structures in src and run. By putting the right ones in the propath for any given instance, I can have tst programs "overlay" the release versions.
But, compiling in OEA, things end up in XYZ/run/src instead of XYZ/run.
What do you do about this?
The joys of 10.1B. Thomas, this issue is addressed in 10.1B. If you have the beta look into the source directory support feature in OEA. We've added the ability to configure alternate source code roots which allows you have have a project "src" directory under which all the code is compiled.
Explanation by example:
In 10.1A if your project looks like this:
/src/module2
Then setup both projects propath to include only the r-code destination which is set to the same thing both projects. The rcode directory appears earlier in the propath than the source directories to ensure that r-code is being run.
Eclipse' integration with source code control makes things a lot easier to manage something like this. If you decide you need to switch between versions of whatever your working on, you simply switch workspaces, Each workspace is configured to work with only one version. That way, there is no copying. The source code control maintains any sort of version context. The only issue is that if you're working with a team, then you need to update from source control to pickup changes (to avoid merges) before doing any work.
Message was edited by:
Matt Baker
Err ... it was 10.1B that I just experienced it on ... where is this feature?
Project properties. Under the OpenEdge node look at the Propath node. It has a second tab on it. The second tab has an "Add Directory". If you use this option you'll be prompted for a directory in your project. This directory becomes "source code root". It has its own special icon in the propath tree view. If you expand the node you'll notice that it has an extra option for specifying the Build Directory that the other normal propath entries don't have.