I prefer aggregation vs inheritance. What about deploying the sites to the repo as type "site" and then from the aggregated site depend on them and make the aggregated site?
On 2/6/06, Brett Porter <[EMAIL PROTECTED]> 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]
