On Mar 19, 2007, at 6:52 AM, Gianny Damour wrote:
And perhaps change the 'applications' groupId to simply 'apps'...
anyways, we'd end up with ids like:
testsupport/* org.apache.geronimo.server
modules/* org.apache.geronimo.server
To some extent, I would prefer to keep the "modules" part in the
groupId as it provides a better namespacing. For instance, from the
org/apache/geronimo directory of a m2 repo, it is easy to see the
grouping as configs, applications etc are not lost within a list of
other directories.
As we reorganize the tree the "modules/" directory will be going
away. This is an artifact of the layout setup to facilitate the m1
build, this is not needed nor recommended in an m2 build.
So... I don't see why we would want to keep
"org.apache.geronimo.server.modules" around... and IMO "modules" is
even more confusing here, as in mvn tearms everything is a module,
and in G terms the stuff from "configs/*" are what we call modules.
I think this groupId should just go away.
Also, I believe that losing the "geronimo-" prefixes contributes to
the potential confusion.
How exactly?
configs/* org.apache.geronimo.server.configs
applications/* org.apache.geronimo.server.apps
maven-plugins/* org.apache.geronimo.server.mavenplugins
assemblies/* org.apache.geronimo.server.assemblies
testsuite/* org.apache.geronimo.server.testsuite
If we want to use "org.apache.geronimo.server.maven" for our
plugins, then I suggest we rename "maven-plugins/*" to "maven/*"
to keep things consistent. And actually I would do the same for
"applications/*", rename it to "apps/*".
If modules/* have the groupId org.apache.geronimo.server, then I
assume that you also would like to drop the modules/ directory for
the same reason than above. It seems that this would be confusing
to new developers.
Yes, the point is to eventually drop the "modules/*". I sent mail
about this months ago, we are in line for a significant restructuring
of the project tree to group related mvn modules to simplify the
build as well as organize modules into smaller workable chunks.
I also think that we should still re-organize modules/* configs/*
into groups based on the features they provide (like all activemq,
jetty, tomcat, etc) and I would put the configuration modules in
the same group dirs. For an example of that peep at the structure
of the g1.1-activemq4 stuff I just added:
https://svn.apache.org/repos/asf/geronimo/sandbox/g1.1-activemq4/
This is how I would recommend we eventually get our modules
organized... into directories which contain all of the modules
(and config modules) for a particular integration. This makes it
much easier to work on a specific feature... can simply `cd
<feature>; mvn` to build those modules.
One of my main pain point is that a full build takes ~25 minutes on
my box, allegedly fast. Moving to this directory structure does
help. On top of that, it would be awesome to be able to patch a
geronimo installation assumed to be at a given location (may be
configured as a property in setting.xml) after having build a
feature. For instance, this is a hack I use from configs/ to build
and install cars in the geronimo installation I am working against:
Ya, that is one of the main reasons to reorganize. Now that our
build tool supports this sort of grouping and can handle resolving
dependencies on a set of modules in an arbitrary tree. This would
have been very difficult to setup/main w/m1... which is why
everything was dumped into a relatively flat structure. This
structure is more of a burden to us now that anything else. And it
should be changed so simplify the build and to help speed up partial
builds.
I believe it would be simpler and quicker to implement the proposed
grouping approach via external build helpers targeted to day-to-day
Geronimo developers.
What do you think?
I think if folks want to use a script to build specifics that is up
to them. I don't recommend nor want to see a ton of build scripts
checked into svn though. IMO most of these problems can be fixed by
simply reorganizing the tree and issuing a mvn cmd. But, right now
you have to issue a ton of very specific mvn commands to build
related components/configs/assemblies.
In my mind... the plan (for m2 conversion) has always been to get the
build up and running with the current structure, then work on
restructuring to make effective use of m2 to help organize related
components. This is still what I recommend, and still what I hope to
accomplish, though I am hoping to be able to accomplish this w/o
having any negative impact on work being done to support 2.0.
--jason
