geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Restructuring trunk (LONG)
Date Mon, 09 Apr 2007 18:08:49 GMT
Went through your (quite interesting) doctoral dissertation and added
some comments inline :-)

Cheers
Prasad.

On 3/30/07, Jason Dillon <jason@planet57.com> 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.

How about the repositories for these dependencies. Do you envisage
these being split up too or maintained in a single place ? Or would
that become a moot point with the impl of a single (dedicated) repo ?

>
> 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,

If we ever took this route, then could we put the components under a
"components" name in the groupId ?  Eg:
geronimo.server.components.activemq

Just a thought. This will make the framework/* and the components/*
modules consistent w.r.t their groupIds. The groupIds can be mapped to
their source dir layout.

This will also prevent a proliferation of sub-dirs under the
geronimo.server directory in the m2 local repo.
Eg:
geronimo/server/framework
geronimo/server/javaee
geronimo/server/buildsupport
geronimo/server/testsupport
geronimo/server/components
geronimo/server/activemq
geronimo/server/openejb
...
...
...

It would be nice to keep the artifacts of our logical piece called
components grouped together and by themselves. Just wondering out
aloud.

> 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