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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
|