I don't think we've been specific enough about what goes where for
jason's proposal to make sense yet, as gianni points out.
I'm sure we don't want all 100K artifacts we produce all under o.a.g
or o.a.g.server
I was assuming that o.a.g.server would basically have the kernel and
system stuff in it and little else -- maybe some basic naming support.
then e.g. o.a.g.connector would have connector, transaction, jpa,
connector-builder, persistence builder in it with the appropriate
configs as well
etc.
That way no group would be too large to understand at once. However
I think it might still be good to have some easy way to distinguish
the code subprojects from the car/module subprojects and I'm not sure
how to do that well yet. Right now there are 2 indications: whether
the artifact ends up in modules or configs, and whether it starts
with "geronimo-" or ends with .car.
thanks
david jencks
On Mar 20, 2007, at 8:39 AM, Gianny Damour wrote:
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
