One suggested solution is to define a jboss-pojo macro
which takes components from jboss-head module
To try to avoid breaking other developers in JBoss HEAD
we will have working copies of
jboss-system -> jboss-system2 (for the new deployers and service controller wrapper)
jmx -> jmx2 (for the Uniified Interceptor work)
We definitely need a new system module as a number of things beside jmx are changing in the deployment, dependency, state area.
I suppose we do need a new jmx module as well. Could we move the common javax.management.* classes to the j2ee module and have jmx* depend on that?
I would prefer a j2se module.
There will be use cases where jmx is required but not the full j2ee stack.
Those classes only need to be maintained by us for pre jdk1.5 jvms.
One final issue that springs to mind is how to handle
tools, thirdparty and branching.
Essentially what I have to do with the current build is:
1) Define an alias that incorporates all the components that make up checkout
2) Create a "build" project so I can override the groups definition of buildmagic,
this could also be done by creating a branch within JBossAS build
3) Define an alias for the thirdparty jars I want
4) Modify tools if I want to include new projects/thirdparty - I cannot remove unused
stuff unless I create a branch in the tools module
The downside of using a Branch for the pojo project is that modifications
need to merged across yet another branch (it is already becoming unmanageable with
three active branches).
As a positive though, I don't need to create a system2 or jmx2 since I can work in the
branch and merge the changes later back into the main line.
Branches on jmx and system are not that big a deal as these are not seeing much active development. Its going to be a big impact to force the projects that are under very active development to have to deal with multiple branches. I'm fine with working with multiple branches, but I think the branch phobic will be better served by another alias on head.
Branches are probably a cleaner way to do this in the long term, as will other wise have ghost system2 and jmx2 directories at some point (yes I know about pruning, but still creates them on the root CVS disk). Intellij (and I think Eclipse) are now capable of making merges fairly simple (even makes conflict resolution a lot easier).
Only reasons IMHO to not do branches is if more than a handful of people will be working on the branch.
Long term this work is going back to the head branch so I don't know what term you mean here. If its easiest to get the core micrkernel with jmx support, deployments, etc working on a branch, let's do it and then decide from there how to deal with migration of the existing services.
That's what I mean by long term. Once is put back into HEAD, would leave ghost directories (system2 and jmx2), where as using a branch wouldn't. Is not a big deal, but just gets confusing when browsing repository and see a lot of meaningless directories.
Actually, the ghost directories will be jmx and system
jmx2 and system2 will become the new definitions.
I am not branch phobic.
I like branches, but I don't like the idea of continously merging lots of branches.
If there was something like bitkeeper's pull in cvs where you can "automatically"
merge change sets and it remembers how you resolved conflicts
it wouldn't be such a problem.
I'll go with the jmx2/system2 idea for now and only create a branch if it becomes
unmanageable, i.e. we see a need to do major modifications to other projects.
Ok. In the end my only concern is that there is NOT a jmx2 and system2 (or any XXX2) directory for the jboss-head checkout This is just going to cause confusion for anyone who has not been keeping up with this thread.
The basics of this have been done, see the task for further work that can be done.
cvs ... co jboss-pojo
Be careful when modifying thirdparty and tools. They are shared with jboss-head for now.
Something is amiss:
[starksm@lamia JBossHead]$ cvs -z3 co jboss-pojo ... U server/src/resources/schema/xml.xsd cvs checkout: Updating server/src/resources/stylesheets cvs checkout: Updating server/src/resources/uuid-key-generator cvs checkout: Updating server/src/resources/uuid-key-generator/META-INF U server/src/resources/uuid-key-generator/META-INF/jboss-service.xml cvs [checkout aborted]: there is no repository /cvsroot/jboss/jboss-system2
Is this still a problem? I though I fixed this on Tuesday?
User: ejort Date: 05/01/05 16:35:46 Modified: . modules Log: Fix the name of system2 Revision Changes Path 1.440 +2 -2 CVSROOT/modules Index: modules =================================================================== RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.439 retrieving revision 1.440 diff -u -r1.439 -r1.440 --- modules 6 Jan 2005 00:05:07 -0000 1.439 +++ modules 6 Jan 2005 00:35:46 -0000 1.440 @@ -1,4 +1,4 @@ -# $Id: modules,v 1.439 2005/01/06 00:05:07 ejort Exp $ +# $Id: modules,v 1.440 2005/01/06 00:35:46 ejort Exp $ # Three different line formats are valid: # key -a aliases... @@ -83,7 +83,7 @@ _jboss_security -d security jbosssx _jboss_server -d server jboss _jboss_system -d system jboss-system -_jboss_system2 -d system jboss-system2 +_jboss_system2 -d system system2 _jboss_testsuite -d testsuite jbosstest _jboss_transaction -d transaction jboss-transaction _jboss_varia -d varia contrib/varia