Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=15BCIgCcsreFKmTdtYQHjVpPZiyA/SFTRG7RjF6lFrw1ZLK5E3kwT4as8NnMWrQT94X/B+xTL/gis8fHV520/BPQM1zrJbC5QQYjxadwbYHVMacgZdoaB4dyP92WnMgQnP/3h5xhBx+lhs1IibtuxtfgCPHUnwJ/DZkJjRg1Wio=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <B83B0076-6F59-4F54-B02F-65F50A3DFF3A@planet57.com>
References: <B83B0076-6F59-4F54-B02F-65F50A3DFF3A@planet57.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <77632D65-F8DD-418E-BE83-1A7D1C516BD6@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Restructuring trunk (LONG)
Date: Fri, 30 Mar 2007 14:50:18 -0700
To: dev@geronimo.apache.org

This is great! thanks for looking into this!

So far I have only a couple minor quibbles.

-- connector + transaction should be a component
-- I don't understand why you want the "server" in the base groupId.   
why not o.a.g.activemq, o.a.g.connector, o.a.g.openejb, etc?   
o.a.g.server.client seems especially odd to me :-)

thanks
david jencks

On Mar 30, 2007, at 2:29 PM, 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 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
>
>