commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [all] Stripping Excludes from project.xml (was Re: [all] Shared build causes issues in releases)
Date Fri, 09 Apr 2004 18:48:20 GMT
If you read back to the start of the thread, you'll find that there are
issues at release time when we need each commons component to be completely
independent. Mark's strategy here is, IMHO, right. We have tried to get a
shared version working, and it sort of does. However it has too many issues.

Personally, I would have kept the extends, but had it as
<extends>project-commons.xml</extends>. That way it would be simple to
update a shared base to each project simply by copying a whole file. But
thats by the by - the main task is to ensure we can all develop and release
as thats what we need to focus on ;-)

BTW, thanks to Mark for following this through.

Stephen

From: "David Graham" <grahamdavid1980@yahoo.com>
> 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?
>
> The efforts to produce a common project.xml are wasted if we start
> duplicating data again.
>
> David
>
>
> --- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> > Because the 'pros' of extending the commons project.xml do not outweigh
> > the 'cons'.
> >
> > 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.xml
> > instead
> > >of using commons-build/project.xml?  Isn't that the purpose of
> > extending
> > >the parent file?
> > >
> > >David
> > >
> > >
> > >--- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> > >
> > >
> > >>Yes, the following info has been added to each file (this is just CLI
> > as
> > >>
> > >>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>
> > >>
> > >>
> > >>
> > >>
> > >>
> >
>
><url>http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/</url
>
> > >
> > >
> > >>  <package>org.apache.commons.${pom.artifactId.substring(8)}</package>
> > >>
> > >>  <organization>
> > >>    <name>The Apache Software Foundation</name>
> > >>    <url>http://jakarta.apache.org</url>
> > >>
> >
> >><logo>http://jakarta.apache.org/images/original-jakarta-logo.gif</logo>
> > >>  </organization>
> > >>
> > >>  <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>
> > >>
> >
> >><issueTrackingUrl>http://issues.apache.org/bugzilla/</issueTrackingUrl>
> > >>  <siteAddress>jakarta.apache.org</siteAddress>
> > >>
> > >>
> > >>
> > >>
> >
>
><siteDirectory>/www/jakarta.apache.org/commons/${pom.artifactId.substring(8
)}/</siteDirectory>
> > >
> > >
> > >>
> > >>
> > >>
> > >>
> >
>
><distributionDirectory>/www/jakarta.apache.org/builds/jakarta-commons/${pom
.artifactId.substring(8)}/</distributionDirectory>
> > >
> > >
> > >>
> > >>  <repository>
> > >>
> > >>
> > >>
> > >>
> >
>
><connection>scm:cvs:pserver:anoncvs@cvs.apache.org:/home/cvspublic:jakarta-
commons/${pom.artifactId.substring(8)}</connection>
> > >
> > >
> > >>
> > >>
> > >>
> > >>
> >
>
><url>http://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substri
ng(8)}/</url>
> > >
> > >
> > >>  </repository>
> > >>
> > >>  <mailingLists>
> > >>    <mailingList>
> > >>      <name>Commons Dev List</name>
> > >>      <subscribe>commons-dev-subscribe@jakarta.apache.org</subscribe>
> > >>
> > >><unsubscribe>commons-dev-unsubscribe@jakarta.apache.org</unsubscribe>
> > >>
> > >>
> > >>
> > >>
> >
>
><archive>http://nagoya.apache.org/eyebrowse/SummarizeList?listName=commons-
dev@jakarta.apache.org</archive>
> > >
> > >
> > >>    </mailingList>
> > >>    <mailingList>
> > >>      <name>Commons User List</name>
> > >>      <subscribe>commons-user-subscribe@jakarta.apache.org</subscribe>
> > >>
> > >><unsubscribe>commons-user-unsubscribe@jakarta.apache.org</unsubscribe>
> > >>
> > >>
> > >>
> > >>
> >
>
><archive>http://nagoya.apache.org/eyebrowse/SummarizeList?listName=commons-
user@jakarta.apache.org</archive>
> > >
> > >
> > >>    </mailingList>
> > >>  </mailingLists>
> > >>
> > >>
> > >>
> > >>
> > >>David Graham wrote:
> > >>
> > >>
> > >>
> > >>>Can you be more specific about what changes you're proposing?
> > >>>
> > >>>David
> > >>>
> > >>>--- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>This mostly a heads up. I've got a version of each projects
> > >>>>
> > >>>>
> > >>project.xml
> > >>
> > >>
> > >>>>minus the includes and with all the information that was being
> > shared
> > >>>>across the commons-build.project.xml. I just want to let everyone
> > know
> > >>>>
> > >>>>
> > >>>>before I commit. Here is a list of projects that will be effected
> > and
> > >>>>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
> >
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message