The problems were caused only when the parent file declared a <build> element. The items you're proposing to remove from the parent and duplicate in each child project don't break builds and are truly common to all commons projects. For example, do we really need to declare Apache as the <organization> in each project?
More arise as time passes, now we have botht he build tag issue and the extend resolution issu in packaging.
In my opinion is a very small duplication, its an over-optimization to make this extension which adds termendous complexity downstream in the development process in both packaging (release managers need to worry about where the extends is pointing and the packaging goals maven provides have to be customized to facilitate this requirement) and in user compilation (users of the src and build packages need this issue resolved if they wish to use maven as the build environment).
The efforts to produce a common project.xml are wasted if we start duplicating data again.
The commons-build.project.xml (IMHO) is there to provide the site information for the toplevel site.
The commons site characteristics across the subprojects are not provided by project.xml as much as they are provided by the the navigation entity include and the shared commons-site.jsl. I think we should be more interested in standardizing the coding, testing and packaging practices across the projects as being of greater priority than the duplication of what is considerably a small amount of metadata about the overal project.
-Mark
David
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
Because the 'pros' of extending the commons project.xml do not outweigh the 'cons'.=== message truncated ===
Pros: remove some duplication of project.xml content across subprojects
Cons: some conent can be inherited, some cannot. solution does not work across all subprojects which may have unique needs.
Theres too much of a release manager level maven customization required to get the packaging right in src and build distributions. Its better to
just have each project maintain its project.xml content, then just use basic search and replace strategies to update the contents. I'm using them now and its alot easier than forcing each release manager into a specific deployment strategy.
the current issue with the build tag is a strong example of how extending shoots the projects in the foot. I'm not convinced that the Maven folks have fully worked out the extend mechanism anyways, there are limitations in inhertiance of POM configuration, of properties and of maven.xml goals that just make this inhertance flimsy.
My opinion is that we should keep the customization to a minimum and try
to use the Maven defaults wherever possible. This way we can get this over sooner and get back to developing components.
-Mark
David Graham wrote:
Why do you want to duplicate this common info in each project.xmlinstead
of using commons-build/project.xml? Isn't that the purpose ofextending
the parent file?as
David
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
Yes, the following info has been added to each file (this is just CLI
<url>http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/</url>an example):
<pomVersion>3</pomVersion>
<!-- unique project info for each project was retained here -->
<id>commons-cli</id>
<name>CLI</name>
<currentVersion>1.0</currentVersion>
<inceptionYear>2002</inceptionYear>
<shortDescription>Commons CLI</shortDescription>
<description>Commons CLI provides a simple API for working with the command line arguments and options.</description>
<logo>/images/logo.png</logo>
<siteDirectory>/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}/</siteDirectory>
<package>org.apache.commons.${pom.artifactId.substring(8)}</package><logo>http://jakarta.apache.org/images/original-jakarta-logo.gif</logo>
<organization>
<name>The Apache Software Foundation</name>
<url>http://jakarta.apache.org</url>
</organization><issueTrackingUrl>http://issues.apache.org/bugzilla/</issueTrackingUrl>
<licenses> <license> <name>The Apache Software License, Version 2.0</name> <url>/LICENSE.txt</url> <distribution>repo</distribution> </license> </licenses>
<!-- if a project already had a gumpRepository id, it was used over this one -->
<gumpRepositoryId>jakarta</gumpRepositoryId>
<siteAddress>jakarta.apache.org</siteAddress>
<distributionDirectory>/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}/</distributionDirectory>
<connection>scm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}</connection>
<repository>
<url>http://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substring(8)}/</url>
<archive>http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]</archive>
</repository>
<mailingLists>
<mailingList>
<name>Commons Dev List</name>
<subscribe>[EMAIL PROTECTED]</subscribe>
<unsubscribe>[EMAIL PROTECTED]</unsubscribe>
<archive>http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]</archive>
</mailingList>
<mailingList>
<name>Commons User List</name>
<subscribe>[EMAIL PROTECTED]</subscribe>
<unsubscribe>[EMAIL PROTECTED]</unsubscribe>
shared
</mailingList> </mailingLists>
David Graham wrote:
Can you be more specific about what changes you're proposing?project.xml
David
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
This mostly a heads up. I've got a version of each projects
minus the includes and with all the information that was being
knowacross the commons-build.project.xml. I just want to let everyone
and
before I commit. Here is a list of projects that will be effected
not effected
All the previous information in each project.xml is intact, I'm only
adding info that was previously inherited.
Projects this change will update (these were extending the commons-build/project.xml):
beanutils
betwixt
cli
codec
collections
configuration
daemon
dbcp
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
--------------------------------------------------------------------- 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]
