On 20/03/2007, at 6:15 AM, Jason Dillon wrote:
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?
Let's illustrate:
When we loose the modules part and keep the geronimo- prefix in the
artifactId, a maven repo looks like this from the dir org/apache/
geronimo/server:
geronimo-activation
geronimo-activemq-gbean
geronimo-activemq-gbean-management
<more geronimo- stuff>
apps
<more geronimo- stuff>
assemblies
<more geronimo- stuff>
configs
<more geronimo- stuff and you get the idea>
Intuitively, I classify the folders starting with geronimo- into the
same category and apps, assemblies et cetera stand out.
Now, we also loose the geronimo- prefix and we have:
activation
activemq-gbean
activemq-gbean-management
<more stuff>
apps
<more stuff>
assemblies
<more stuff>
configs
<more stuff and you get the idea>
This is confusing as apps, assemblies et cetera are lost within a
list of other directories.
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 know as I read it :). The point I am trying to make is: if modules/
is dropped, then new developers will have a hard time to understand
the folder organization for reasons very similar to the above maven
repo example.
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.
How does m2 handle the resolution of dependencies on an arbitrary
tree? Is it as simple as: mvn <build these modules:please also build
afferent dependencies>?
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.
I think the same result can be delivered w/o any reorganizing with
the magic mvn <build these modules:please also build afferent
dependencies> command.
E.g., I am in the server/trunk folder and do:
mvn <magic command like partial-build> modules/jetty6
mvn does a first pass to load the dependency graph for the overall
tree; identify the afferent artifacts of modules/jetty6; and build
modules/jetty6 and all of its afferent artifacts.
It seems to me that a single script can do all the above w/o too much
maven magic required. Obviously, everything happens outside of maven;
yet it is simple to implement and more people can maintain and
contribute.
Thanks,
Gianny
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
