geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Restructuring trunk (LONG)
Date Tue, 03 Apr 2007 19:03:10 GMT
On Apr 3, 2007, at 7:11 AM, Donald Woods wrote:
> I like your proposal, but this feels like a major change to make in  
> the last month of a release, when we are just now seeing and fixing  
> Console bugs and the Samples still need work for 2.0.
> Waiting until after M5 (or after CTS setup is finished) to start  
> changing any of the groupIds could cause us another several weeks  
> of churn to find and fix all of the unpredictable ripple affects  
> through the server, daytrader and any Plug-ins we create or help  
> others to produce (like Liferay or Roller....)
> Seems like if we want to do any of this for 2.0, we need to make  
> the changes this week and then cut a M5 or Beta, to give everyone  
> time to verify that their apps and favorite Console portlets still  
> work....

I don't think any of these changes will be made to trunk for quite a  
few weeks, I did mention this...

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.

I do believe this should be done, but I don't want it to distract  
from the current 2.0+TCK work, so merging these changes into trunk  
will have to wait until most of that stuff is sorted.


> -Donald
> Jason Dillon wrote:
>> 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, 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] 
>> tf2175344s134.html#a6014657

View raw message