On Mar 20, 2007, at 5:39 AM, Gianny Damour wrote:
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.
I don't believe that folks who are used to m2 repos are going to get
confused... this is how m2 works. I would rather have each set of
related modules use their own groupId, like for AMQ
org.apache.geronimo.activemq, but I fear if we start doing that then
we are going to run our selves into the ground with long path name
problems :-( Or maybe we should rebel and go back to using geronimo
as the root groupId... hrm... that would ruffle some feathers :-P
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 don't follow how organizing modules into related groups is going to
make it hard for folks to follow. "Where are all the activemq
modules? they are in the activemq/* directory.". IMO its more
cumbersome/difficult now for new folks to understand, since part of
things for a feature are in modules/* and part are in configs/* with
a whole lot of other stuff in between to confuse the heck out of
you. Not that it confused me... but if you are talking about getting
new folks up to speed, then having smaller groups of modules which
are *all* related makes *much* more sense than what we have now.
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>?
M2 handles this via the <modules>... definitions in poms. You can
setup an arbitrary tree by configuring the poms list of its child
modules.
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.
<sarcasm>
Magic mvn command? Are you serious? Has Disney taken over the Maven
project? Is Mickey Mouse going to hold my hand while I run the
magically mvn command?
</sarcasm>
But seriously, there is no _magic_ mvn command... and IMO trying to
create one will *only* complicate things more.
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.
Do you remember everyone bitching about the bootstrap command? And
the mess about getting it to work on win32 and unix... and how folks
still wanted to use mvn...
* * *
modules/*, configs/*, applications/* and probably even assemblies/*
to some degree... are relics of the m1 build. m2 is a different
beast which has more features for organization of a multi-module
build. To best suite our build needs and to support our growing
project (which the codebase seems to keep getting larger) we really
need to reorganize the structure.
--jason
