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
