I think this is a move in the right direction, in a more general sense.
It's time we thought of dependencies in a more abstract way, I think.
Rather than talking about them as purely code dependencies, I think it's
important to think of them as things that the project needs in order to
build, whatever that means.
When we start talking about documentation-only projects, the concept of
a dependency must naturally change too. Likewise when we're talking
about an EAR dependency, as there might be several kinds of dependencies
that each may require some handling beyond simply (a) throwing them on a
given classpath, and (b) including them wholesale in a directory when
the assembly is created. But, back to the documentation discussion...
Using inheritance to "roll up" documentation from child projects does
overload the meaning of the modules section, and causes a problem in the
processing of the build as a whole. When are we processing the parent
POM before the child modules? When are we processing the modules first?
When do we have to perform some operation on the parent POM before *and*
after? Using a dependency hierarchy within the build would straighten
this out, it seems, since you will have direct access to the project
artifact and all its attachments of all of your dependency projects by
simply using ${project.artifactMap}.
Finally, to reiterate, this new method will be a more accurate
representation of the dependency hierarchy. Parents don't depend on
children, and a dependency relationship does not always mean a code
dependency.
Hope that helps muddy things up a bit. ;-)
-john
Brett Porter wrote:
Hi folks,
This is pretty important to start punting around as I need to lock in a
best practice that works on Maven 2.0 and can be used in the site
plug-in release. Please give this a review as soon as possible.
I am battling the age old question where we have parent as inheritance
and parent as a build aggregator. I'm still inclined to think that we
should separate the functional from the informational (feedback on
http://www.nabble.com/POM-Problems-and-Inheritence-t642303.html#a1708556
still welcome!), we're stuck with the current situation for right now.
Recently, we've been talking about making the parents produce aggregated
content - assemblies, ears, aggregated site reports. This results in a
src/ directory under the root that sits with the parent. I'd alluded to
this in
http://www.nabble.com/-discuss-change-to-parent-hierachy-t898697.html#a2329650
which I'll revise based on any decision here.
Chatting with Jason, we've agreed it doesn't quite feel right, though
for my part I'm not convinced it's a bad thing yet but rather just
something I'm not used to. The main downside I see remains the inability
to do anything with it in Eclipse :)
The alternative is to make everything a module of the parent, using
dependencies to represent the things to aggregate. This removes the need
to make <modules> act like dependencies and keeps the parent clean as an
inheritance and build entry point. All the outputs of the build end up
in a module.
Practical example:
maven/components/trunk/
pom.xml
maven-artifact/
maven-core/
...
maven-dist/
maven-user-guide/
maven-reference-guide/
The new stuff here:
- maven-user-guide is a site that contains documentation for Maven. It
would have a lot of the stuff from the site now under /guides/, but is
here to be versioned and distributed. It would be of type assembly and
produce an zip of the docs for individual download.
- maven-dist is of <packaging>assembly</packaging> and contains the
assembly descriptors and binary files currently in maven-core. It would
depend on maven-user-guide and bundle that in some binary distributions
that include documentation (I generally prefer a separate bundle as
above, but its an option as I'm thinking general practices here)
- maven-reference-guide is a site that is deployed to include
documentation for Maven developers. It depends on all the modules and
while it doesn't produce a distribution, it provides the site that links
in all the other modules and would produce any aggregate reports. The
site plug-in would have to be able to include dependencies in a menu
instead of modules, which might be a hassle as we are now reproducing a
lot of information. This is the one I'm least comfortable about. Note
that some of this content might be included in a user-guide (eg
aggregated javadoc), so it needs to work there too.
Any thoughts? It's obvious at this point the site inheritance needs a
bit of rethought - most likely the site descriptor will need to have its
own <parent> element for finding the parent site descriptor.
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
