Brett, I agree with most of what you said in this mail and in your POM-Problems email. I just have this comment: >From the POM-problems email: "3) Separating inheritance of versioned and transient info
A: Deprecate dependency inheritance (bare with me :) The problem of separation only seems to appear in generic pom inheritance, and then it is only the dependencies used that are of issue. For starters, in that case, we can just say its is best practice not to inherit the dependency, then the parent becomes completely project/build info which we are happy to have the auto versioning for. But that raises the question - is dependency inheritance worthwhile at all any more?" I think the dependency or dependencyManagement inheritance is all about not having to duplicate versions etc all over the place. I have it setup so that I can control the versions from as few places as possible and thus most of my parents at least have the management sections. If this is removed, then I think it will be a nightmare for example to update from foo x-x to foo x-z. Now obviously this would happen with the auto version resolution if I set it in the final product (ie war). However, in this case, if I want my standalone builds or unit tests to be accurately using the intended version, then I need to update all my projects to have the correct version. This actually negates many benefits of the transitive dependency resolution you mentioned. I agree that the current method doesn't feel right, but this is currently the only way to control this that I can see. The other important part is the pluginManagement. In a corp environment, it's important to know all developers are using vetted versions of the plugins. Using a highlevel parent with pluginManagement allows me to verify new plugins & make nessessary infrastructure changes before rolling it out. It means that this needs to be versioned because a new plugin rev might imply some other changes in the build or code. It's also nice that devs don't have to remember to use the -U command all the time. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 1:24 AM To: Maven Developers List Subject: Parent vs dependency aggregation, including sites and reports 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#a2 329650 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]
