geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Restructuring trunk (LONG)
Date Fri, 30 Mar 2007 21:29:48 GMT
Awhile back I sent some email [1] about restructuring server/trunk  
into smaller groups of modules organized by function/feature.

I had been waiting for svk2 to be usable enough to manage  
restructuring in a branch while pulling in new changes to src files,  
and the latest updates to the svk2 trunk has working support to -- 
track-renames when merging.  Last night I spent a few hours and  
whipped up a POC, using svk to move modules around into groups.  I've  
been tracking changes made to trunk since then and merging them into  
my local svk repository and it appears that the --track-rename  
feature is working... yay!

I just wanted to provide a little details on this, how it is working  
out so far and start up some discussion about eventually making these  
changes to server/trunk.  Right off the bat, I want to mention that  
these changes should probably be implemented *after* we are done with  
the bulk of 2.0 work.  I don't want to limit this to 2.1, since with  
the --track-rename feature it may be very feasible to implement this  
change before we are done with 2.0, but should definitely not be done  
until we are sorted on the features and TCK muck.

When we do decide to implement something like this, I think we should  
also re-groupId things under org.apache.geronimo.server, and use that  
namespace for a fresh start... meaning we should not re-groupId to  
o.a.g.server until then.

  * * *

Below are _examples_ of how modules _might_ be organized, nothing in  
stone, probably not completely accurate.  I did leave the actual  
names of modules as they were, we can deal with the naming of them  
later.

So far what I have done was to create 2 new top-level modules:

  * framework
  * components

These are just pom modules which serve to group other modules.  The  
'framework' module contains the core (code and configuration) modules  
that make up the backbone of the server.  Each of these modules only  
has dependencies on other modules in this group, or on modules in  
testsupport or buildsupport, both of which are built prior to  
building framework (except for a wee bit of magic to get the car- 
maven-plugin working, see details on that below).

For example:

     framework
     framework/geronimo-activation
     framework/geronimo-client
     framework/geronimo-client-builder
     framework/geronimo-clustering
     framework/geronimo-common
     framework/geronimo-connector
     framework/geronimo-connector-builder
     framework/geronimo-core
     framework/geronimo-deploy-config
     framework/geronimo-deploy-jsr88
     framework/geronimo-deploy-jsr88-bootstrapper
     framework/geronimo-deploy-tool
     framework/geronimo-deployment
     framework/geronimo-gbean-deployer
     framework/geronimo-interceptor
     framework/geronimo-j2ee
     framework/geronimo-j2ee-builder
     framework/geronimo-j2ee-schema
     framework/geronimo-jmx-remoting
     framework/geronimo-kernel
     framework/geronimo-management
     framework/geronimo-naming
     framework/geronimo-naming-builder
     framework/geronimo-security
     framework/geronimo-security-builder
     framework/geronimo-service-builder
     framework/geronimo-system
     framework/geronimo-test-ddbean
     framework/geronimo-timer
     framework/geronimo-transaction
     framework/geronimo-transaction-jta11
     framework/geronimo-transformer
     framework/geronimo-util
     framework/geronimo-web-2.5-builder

NOTE: this ^^^ is not a complete list, there are still a bunch of  
bits in configs/* which I'm trying to figure out where they should  
live.  See the bits below about framework and javaee stuff.

The 'components' module contains modules for each of the major non- 
framework feature components, which in turn contain the (code and  
configuration) modules that implement/configure that feature.  For  
example:

     components
     components/activemq
     components/axis
     components/axis2
     components/converter
     components/corba
     components/cxf
     components/derby
     components/directory
     components/hotdeploy
     components/jasper
     components/javamail
     components/jaxws
     components/jetty6
     components/jetty6-wadi
     components/jpa
     components/myfaces
     components/openejb
     components/tomcat6
     components/upgrade
     components/wadi
     components/webservices

As mentioned, each of the component modules contains the (code and  
configuration) modules that implement the feature, so for example for  
ActiveMQ, we have:

     components/activemq
     components/activemq/activemq-broker
     components/activemq/activemq-ra
     components/activemq/geronimo-activemq
     components/activemq/geronimo-activemq-management
     components/activemq/geronimo-activemq-ra

Where possible, the <dependencyManagement> configuration for  
artifacts used by feature components should be put into the  
component's pom.xml.  For example, the components/activemq/pom.xml has:

----8<----
     <modules>
         <module>geronimo-activemq-management</module>
         <module>geronimo-activemq</module>
         <module>geronimo-activemq-ra</module>
         <module>activemq-broker</module>
         <module>activemq-ra</module>
     </modules>

     <dependencyManagement>
         <dependencies>
             <dependency>
                 <groupId>org.apache.activemq</groupId>
                 <artifactId>activemq-core</artifactId>
                 <version>4.1-SNAPSHOT</version>
             </dependency>

             <dependency>
                 <groupId>org.apache.activemq</groupId>
                 <artifactId>activemq-ra</artifactId>
                 <version>4.1-SNAPSHOT</version>
             </dependency>

             <dependency>
                 <groupId>org.apache.activemq</groupId>
                 <artifactId>activeio-core</artifactId>
                 <version>3.0.0-incubator</version>
             </dependency>
         </dependencies>
     </dependencyManagement>
---->8----

This isn't going to be possible for all of our dependencies, though I  
think that if we can move to this model it would help improve the  
maintainability of version information. While that information might  
not be in one place anymore, I think that it would help improve  
things as it will move the relevant versions close to the modules  
that actually use them and thus make management of those version much  
easier (as well as making it clear where those deps are used).  The  
top-level pom's dependencyManagement section is quite difficult to  
manage at the moment IMO.  I think for the most part we can do this  
for most feature components, and for situations where other modules  
need those deps, it would be best to have dependent modules depend on  
the components/*/* module instead of on the dependency directly, and  
if needed create modules simply to provide the dependencies for this  
reason.

I also updated the applications/* tree, to give each application in  
there its own module for grouping.  For example, we had an  
applications/console which grouped the console modules, but most  
other modules were left directly under applications/*, so I made new  
modules for grouping and moved the (code and configuration) modules  
under them.  For example:

     applications
     applications/ca-helper
     applications/console
     applications/dojo
     applications/examples
     applications/ldap-demo
     applications/remote-deploy
     applications/uddi
     applications/welcome

Just like with components, the code and configuration modules are in  
these application group modules:

     applications/ca-helper
     applications/ca-helper/ca-helper-jetty
     applications/ca-helper/ca-helper-tomcat
     applications/ca-helper/geronimo-ca-helper

  * * *

As mentioned several times above, the code (jar) and configuration  
(car) modules are all grouped together.  IMO this is key to keeping  
the functional components together.  It facilitates things like `cd  
components/activemq; mvn install` to build all of the components for  
a specific feature, as well as allows dependencyManagement to for  
feature artifacts to be consolidated into the component groups pom.

Since jar and car modules now can intermingle, that means that the  
bootstrap needs to be updated, so that the car-maven-plugin can be  
used as an extension.  This is relatively easy, we don't really need  
stages for bootstrap anymore, just need a single bootstrap profile,  
as in:

----8<----
     <profile>
         <id>bootstrap</id>
         <modules>
             <module>framework/geronimo-util</module>
             <module>framework/geronimo-kernel</module>
             <module>framework/geronimo-common</module>
             <module>framework/geronimo-system</module>
             <module>framework/geronimo-service-builder</module>
             <module>framework/geronimo-deployment</module>
             <module>framework/geronimo-deploy-config</module>
             <module>framework/geronimo-deploy-jsr88</module>
             <module>framework/geronimo-deploy-tool</module>
             <module>buildsupport/car-maven-plugin</module>
         </modules>
     </profile>
---->8----

NOTE: I did also move all of the bits from maven-plugins/* into  
buildsupport/*, since there are some use cases for modules that  
support our build process that aren't really maven-plugins, and maven- 
plugins support the build so it made sense to just put them all in  
one place.

Then `mvn -Pbootstrap` to get the car-maven-plugin up and running,  
which should still only be needed if there isn't a deployed SNAPSHOT  
available, else its business as usual.

  * * *

The main issues now are really what are the correct components/*  
groups and what should be in framework/* and do we need another top- 
level module, say 'javaee' to hold the modules which add the feature  
non-component modules that support the JavaEE server assemblies?  I  
think the answer to that is YES, though I think that most of the  
modules under javaee/* are going to be configuration modules, like  
for example the client.car, this has dependencies to things like  
openejb, which are at the moment under components/openejb/*.  Other  
configs may also fall under that category, where they depend on  
framework/* and components/*/* modules.

Previously in the discussion it was mentioned to call this like  
'server', though if we change the groupId to o.a.g.server for the  
base, then another .server is just going to be confusing.

That reminds me, for the most part these top-level modules are all  
going under a separate groupId, so for example, the modules in  
framework/* are all o.a.g.framework (or with o.a.g.server as the  
base, then o.a.g.s.framework).  This makes things nice and  
consistent.  The only thing which I think we may want to talk about  
more related to groupIds is for bits under components/*.  One thought  
I had was to give each of these their own groupId, though not under  
o.a.g.s.components, but as peers to that.  For example, the AcitveMQ  
modules might use o.a.g.s.activemq as the groupId.  This would help  
make it easier to match up bits from the src tree to the m2  
repository, and reduce the number of artifacts per groupId as well.

I know that some of you might be thinking about that evil windows  
path length problem... and its always in the back of my mind...  
mostly cursing it for being so dumb, but still its there.  And if  
that ends up becoming an issue, then I think we should really  
consider dropping the org.apache bits from the groupId.  But thats  
just an idea, I know everyone else and their mother is using reverse  
TLD for groupIds, but many don't have a project in the scale of  
Geronimo.  I also think the M2 folks didn't even consider this  
windows limitation when they moved in that direction else they might  
have chosen to implement it differently.  Anyways, its minor... but  
something to think about.  I'd rather we did something different with  
groupId's then limit how we can group our modules based on the lack  
of intelligent filename handling by everyones favorite love to hate  
operation system  (okay, maybe its just my favorite :-P).

  * * *

So, with all that said, a few hours last night I did play around with  
moving bits, and have been sync'ing up changes from server/trunk just  
fine into the reorganized tree.  I've almost go the geronimo- 
framework assembly buildable/runnable.  The other assemblies take a  
little bit more work to handle updating poms to use new parents to  
get configuration correctly as well as to reference modules in the  
new groupIds.

Anyhoo... this is just a POC at the moment, though I hope that we can  
eventually make this a reality, as I believe it will help simplify  
our build configuration as well as facilitate better buildability for  
working on specific features.

I'll probably spend a few more hours on this to get at least one of  
the javaee assemblies up to finish the POC.  The main issue is  
figuring out what depends on what and grouping those modules  
accordingly.  I will probably also merge my local reorg-branch into  
something in the sandbox once its functional so that others can have  
a look at how its setup.  I could have done this already, but I  
didn't want to flood the scm list with all of my POC changes, but I  
may commit a lump'd merge a little later.

I know its a lot to swallow, but I'd appreciate any comments or  
suggestions.

Cheers,

--jason

[1] http://www.nabble.com/Restructuring-trunk%2C-then-next-steps- 
tf2175344s134.html#a6014657



Mime
View raw message