You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2007/03/30 23:29:48 UTC
Restructuring trunk (LONG)
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
Re: Restructuring trunk (LONG)
Posted by Jason Dillon <ja...@planet57.com>.
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...
<snip>
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.
</snip>
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.
--jason
> -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 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
Re: Restructuring trunk (LONG)
Posted by Donald Woods <dr...@yahoo.com>.
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....
-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 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
>
>
>
>
>
Re: Restructuring trunk (LONG)
Posted by Jason Dillon <ja...@planet57.com>.
On Apr 10, 2007, at 7:08 AM, Donald Woods wrote:
>> What repositories? Most of these artifacts live in central... and
>> according to Jason Van Zyl, artifacts in central are never
>> removed. And he isn't so found of adding extra magical repository
>> bits to subvert the system.
>> I was looking at making a magical proxy wagon impl to handle
>> this... though after talking to Jason more I've pushed off that
>> work, not to mention that with the current m2 wagon bits, we can't
>> inject custom handlers for http/https easily, we would have to use
>> a new magical proxy protocol (only to tell the wagon system which
>> provider to pick up), and then we'd have to define a new proxy://
>> repo as central and then add some magical rewriting of dependency
>> poms to strip out any repo muck they have... all too complicated IMO.
>> So for now I'm deferring that work, and for now will try to depend
>> on central having artifacts that never get lost (which I still
>> have very mixed feelings about).
>
> Have you looked at the Maven Proxy project?
> http://maven-proxy.codehaus.org/
>
> We're using it for internal builds of Geronimo and it works nicely
> for everything except SNAPSHOTS, which you either have to configure
> it to always or never look for new artifacts, which is not a
> dynamic configuration setting. Other that that, its great, because
> it lets me create a settings.xml for m2 that says its a mirrorOf *
> and then I can configure the proxy (which is just a servlet I have
> running in Tomcat 5.5) to specify exactly which order of local
> rsync mirrors (either available thru HTTP or local file:// access)
> and remote/live repos to search for artifacts.
Yes, I have used Maven Proxy before, as well as DSMP and Proximity.
But this is not an "internal build" problem, its a problem that
*everyone* *anywhere* who tries to build Geronimo has.... we can not
make them all use a specific proxy server configuration. Not like we
have the resources to host that proxy server either.
Anyways, this email thread is not intended to have muck to do with
proxies or repos, so lets not let it digress please. I've written up
a lot of other emails on this repository issue if you would like to
comment on those threads :-)
--jason
Re: Restructuring trunk (LONG)
Posted by Donald Woods <dw...@apache.org>.
Inline below...
-Donald
Jason Dillon wrote:
> On Apr 9, 2007, at 11:08 AM, Prasad Kashyap wrote:
>> Went through your (quite interesting) doctoral dissertation and added
>> some comments inline :-)
>
> :-)
>
>
>>> 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 ?
>
> What repositories? Most of these artifacts live in central... and
> according to Jason Van Zyl, artifacts in central are never removed. And
> he isn't so found of adding extra magical repository bits to subvert the
> system.
>
> I was looking at making a magical proxy wagon impl to handle this...
> though after talking to Jason more I've pushed off that work, not to
> mention that with the current m2 wagon bits, we can't inject custom
> handlers for http/https easily, we would have to use a new magical proxy
> protocol (only to tell the wagon system which provider to pick up), and
> then we'd have to define a new proxy:// repo as central and then add
> some magical rewriting of dependency poms to strip out any repo muck
> they have... all too complicated IMO.
>
> So for now I'm deferring that work, and for now will try to depend on
> central having artifacts that never get lost (which I still have very
> mixed feelings about).
>
Have you looked at the Maven Proxy project?
http://maven-proxy.codehaus.org/
We're using it for internal builds of Geronimo and it works nicely for
everything except SNAPSHOTS, which you either have to configure it to
always or never look for new artifacts, which is not a dynamic
configuration setting. Other that that, its great, because it lets me
create a settings.xml for m2 that says its a mirrorOf * and then I can
configure the proxy (which is just a servlet I have running in Tomcat
5.5) to specify exactly which order of local rsync mirrors (either
available thru HTTP or local file:// access) and remote/live repos to
search for artifacts.
>>> 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
>
> Sure, I would prefer to use another groupId here, but because of the
> stupid long path muck it becomes difficult. Droping "org.apache." saves
> us 11 chars, adding "components." tacks on 11 more.
>
>
>> 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.
>
> Yup. But I fear that we are already pushing the limits... :-\
>
>
>> 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
>
> Yup, though we are going to have a lot of those anyways... but it is
> ideal to keep the structure similar to what the build tree uses, though
> I only think that is needed for the first few levels, else the groupId
> management gets way out of hand.
>
>
>> It would be nice to keep the artifacts of our logical piece called
>> components grouped together and by themselves. Just wondering out
>> aloud.
>
> I'm not sure what you mean exactly... but if you mean to have all of the
> activemq related modules under one groupId and openejb under its own,
> etc... then ya, that is the idea. Though that will be done either
> way... its just a matter of do we call the groupId:
>
> [org.apache.]geronimo.server.activemq
>
> or:
>
> [org.apache.]geronimo.server.components.activemq
>
> <rant>
> I really hate to have to make special cases for crappy operating
> systems. Thank the gods that winblows can handle longish file names,
> else we'd have to make everything 8.3 with cryptic names. Lucky though
> that the ms foolios hacked in a translation layer for 8.3 to longish
> names years ago. Just too bad they didn't re-write their shizzle to fix
> the problem, instead they just put a fat bandaid on it.
> </rant>
>
> --jason
>
>
>
>
Re: Restructuring trunk (LONG)
Posted by Jason Dillon <ja...@planet57.com>.
On Apr 9, 2007, at 11:08 AM, Prasad Kashyap wrote:
> Went through your (quite interesting) doctoral dissertation and added
> some comments inline :-)
:-)
>> 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 ?
What repositories? Most of these artifacts live in central... and
according to Jason Van Zyl, artifacts in central are never removed.
And he isn't so found of adding extra magical repository bits to
subvert the system.
I was looking at making a magical proxy wagon impl to handle this...
though after talking to Jason more I've pushed off that work, not to
mention that with the current m2 wagon bits, we can't inject custom
handlers for http/https easily, we would have to use a new magical
proxy protocol (only to tell the wagon system which provider to pick
up), and then we'd have to define a new proxy:// repo as central and
then add some magical rewriting of dependency poms to strip out any
repo muck they have... all too complicated IMO.
So for now I'm deferring that work, and for now will try to depend on
central having artifacts that never get lost (which I still have very
mixed feelings about).
>> 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
Sure, I would prefer to use another groupId here, but because of the
stupid long path muck it becomes difficult. Droping "org.apache."
saves us 11 chars, adding "components." tacks on 11 more.
> 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.
Yup. But I fear that we are already pushing the limits... :-\
> 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
Yup, though we are going to have a lot of those anyways... but it is
ideal to keep the structure similar to what the build tree uses,
though I only think that is needed for the first few levels, else the
groupId management gets way out of hand.
> It would be nice to keep the artifacts of our logical piece called
> components grouped together and by themselves. Just wondering out
> aloud.
I'm not sure what you mean exactly... but if you mean to have all of
the activemq related modules under one groupId and openejb under its
own, etc... then ya, that is the idea. Though that will be done
either way... its just a matter of do we call the groupId:
[org.apache.]geronimo.server.activemq
or:
[org.apache.]geronimo.server.components.activemq
<rant>
I really hate to have to make special cases for crappy operating
systems. Thank the gods that winblows can handle longish file names,
else we'd have to make everything 8.3 with cryptic names. Lucky
though that the ms foolios hacked in a translation layer for 8.3 to
longish names years ago. Just too bad they didn't re-write their
shizzle to fix the problem, instead they just put a fat bandaid on it.
</rant>
--jason
Re: Restructuring trunk (LONG)
Posted by Prasad Kashyap <go...@gmail.com>.
Went through your (quite interesting) doctoral dissertation and added
some comments inline :-)
Cheers
Prasad.
On 3/30/07, Jason Dillon <ja...@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
>
>
>
Re: Restructuring trunk (LONG)
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 30, 2007, at 2:50 PM, David Jencks wrote:
> This is great! thanks for looking into this!
>
> So far I have only a couple minor quibbles.
>
> -- connector + transaction should be a component
It might actually turn out that more modules that are currently
listed in framework/* could be moved to a components/* group too.
All depends on how the dependencies are currently for the bits which
are really core to the backbone and which are used to add additional
and optional features to the server.
Anyways, easy to move... svk tracks renames, so I can move them again
until the dependencies/layout is sorted.
--jason
Re: Restructuring trunk (LONG)
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 30, 2007, at 2:50 PM, David Jencks wrote:
> This is great! thanks for looking into this!
Thanks for taking the time to read what I wrote :-)
> So far I have only a couple minor quibbles.
>
> -- connector + transaction should be a component
That should work... though some bits like geronimo-client would need
to find another home, since it depends on geronimo-transaction.
Though that is probably one of the modules that should move from
framework/* into javaee/*.
> -- 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 :-)
This was to give each of the main top-level projects under our svn
root its own groupId. As in:
https://svn.apache.org/repos/asf/geronimo/server/ ->
org.apache.geronimo.server
https://svn.apache.org/repos/asf/geronimo/daytrader/ ->
org.apache.geronimo.daytrader
https://svn.apache.org/repos/asf/geronimo/genesis/ ->
org.apache.geronimo.genesis
...
I don't think there would be a _groupId_ o.a.g.server.client, there
will probably be:
framework/ -> o.a.g.s.framework
javaee/ -> o.a.g.s.javaee
buildsupport/ -> o.a.g.s.buildsupport
testsupport/ -> o.a.g.s.testsupport
...
I don't think we want to go any deeper on groupIds, which is why the
bits under components/* should probably be treated differently.
Giving each component group its own groupId:
components/activemq/ -> o.a.g.s.activemq
components/axis/ -> o.a.g.s.axis
components/axis2/ -> o.a.g.s.axis2
...
--jason
Re: Restructuring trunk (LONG)
Posted by David Jencks <da...@yahoo.com>.
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
>
>