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] Shared build causes issues in releases
Date Wed, 07 Apr 2004 22:38:49 GMT
Clever ;-) One slight flaw. Maven still won't run on a standlone release as
the maven.xml now requires commons-build ;-)

We could copy the maven.xml bit to each project's mavenxml (it should be a
standalone goal, not a post goal, so it isn't run when users call dist)


However, I've tried a simpler solution in [collections]. commons.xml is
checked into the CVS, as a copy of the shared version.

Project.xml:
<extend>${common.project.xml.file}</extend>

Project.properties:
# For active development
common.project.xml.file=../commons-build/project.xml
# For released code
#common.project.xml.file=commons.xml

At least a user can probably work that one out even if the release manager
forgets to make the switch.

(Not sure how clever you could get. It would be better if it could test
whether the shared file exists and drop back, but I doubt that can be done
in one ${...} )

Stephen

----- Original Message -----
From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
> I've added a simple postGoal that can be included into the projects
> maven.xml that accomplishes the following:
>
> 1.) copies the commons-build/project.xml to commons.xml in the source
> dist build directory prior to tar/zip.
> 2.) transforms the subproject project.xml to change the location of the
> extends.
>
> you can add it to your projects maven.xml using the following entity
>
> <!DOCTYPE project [
>  <!ENTITY commonGoals     SYSTEM "../commons-build/maven/commonGoals.ent">
> ]>
> <project xmlns:deploy="deploy">
>
>   &commonGoals;
>
> </project>
>
> The postGoal very simple and looks like this.
>
>   <!-- copy commons-build/project.xml local and change extends -->
> <postGoal name="dist:prepare-src-filesystem">
>
${systemScope.setProperty('javax.xml.transform.TransformerFactory','org.apac
he.xalan.processor.TransformerFactoryImpl')}
>
>       <copy file="../commons-build/project.xml"
> tofile="${maven.dist.src.assembly.dir}/commons.xml"/>
>       <xslt in="${maven.dist.src.assembly.dir}/project.xml"
> out="${maven.dist.src.assembly.dir}/project.xml.tmp"
> style="../commons-build/maven/prep.xsl">
>               <outputproperty name="method" value="xml"/>
>               <outputproperty name="standalone" value="yes"/>
>               <outputproperty name="encoding" value="iso8859_1"/>
>               <outputproperty name="indent" value="yes"/>
>       </xslt>
>       <move file="${maven.dist.src.assembly.dir}/project.xml.tmp"
> tofile="${maven.dist.src.assembly.dir}/project.xml"/>
> </postGoal>
>
> the goal "dist:prepare-src-filesystem" is run by the goal
> "dist:build-src" goal before the tar/zip goal is executed, so it
> provides an excelent point to modify the contents of your projects
> distributions. There is also one available for "dist:build-bin" called
> dist:prepare-bin-filesystem"
>
>
> -Mark
>
> Mark R. Diggory wrote:
>
> > I guess the key term here is "burden". Release managers may wish to
> > use Maven to cut the release and distribute source distros that
> > build/resolve dependencies using Maven. In such a case the issue of
> > shared project.xml/project.properties/maven.xml becomes more prevalent.
> >
> > Its clear we have two approaches to the subject of source distros.
> >
> > 1.) KISS: Have build.xml that users apply to build the source tarball
> > they download. Its important to note here that the ant build.xml file
> > generated by maven here does download the dependency jars and compile
> > against them.
> >
> > 2.) Maven Integration: Have Maven manage the dependencies and provide
> > the build features.
> >
> > It is plausible to have both. But to have (2) you need to have each
> > maven.xml (or a common xml include) override the "dist:*" goals that
> > generate the content of the source/binary distribution and have it
> > adjust or merge the extended commons-build.xml.
> >
> > -Mark
> >
> > Shapira, Yoav wrote:
> >
> >> Hi,
> >> I've been lurking on these discussions ;)  IIRC, the point of this
whole
> >> effort was to make commons builds and look and feel be common and
> >> consistent, without imposing additional burdens on the release
managers,
> >> right?
> >>
> >> Yoav Shapira
> >> Millennium Research Informatics
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> >>> Sent: Tuesday, April 06, 2004 5:46 PM
> >>> To: Jakarta Commons Developers List
> >>> Subject: Re: [all] Shared build causes issues in releases
> >>>
> >>> Thanks for sorting the problem with current builds.
> >>>
> >>> My point is more long term. I am proposing that a release of a single
> >>> commons component should be complete (and tagged) internally, without
> >>> reference to an external commons-build folder.
> >>>
> >>> To achieve this, a release must
> >>> a) copy and rename commons-build/project.xml to
> >>
> >>
> >> project/project-common.xml
> >>
> >>> b) edit project/project.xml to change the reference from the central
> >>
> >>
> >> source
> >>
> >>> to the local one
> >>>
> >>> ATM release managers will have to remember to do this manually.
> >>>
> >>> (BTW, I needed the maven to work not to create a jar, but to fetch the
> >>> dependencies of validator. Running 'maven clean' seemed like the
> >>
> >>
> >> quickest
> >>
> >>> solution.)
> >>>
> >>> Stephen
> >>>
> >>> From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
> >>>
> >>>> I've now added build and report sections that were missing to the
> >>>> subproject project.xml files, please verify they contain what you
> >>>
> >>
> >> want
> >>
> >>>> for your project and adjust them to your liking if they do not.
> >>>>
> >>>> Maybe someone can review and do the same for the sandbox?
> >>>>
> >>>> On Tue, 2004-04-06 at 13:24, David Graham wrote:
> >>>>
> >>>>> Well both the old and new versions cause problems for some set of
> >>>>
> >>>
> >>> projects
> >>>
> >>>>> so going back isn't really going to help.  The common project.xml
> >>>>
> >>>
> >>> should
> >>>
> >>>>> not define a <build> section because each component is different.
> >>>>
> >>
> >> For
> >>
> >>>>> example, Validator has src/share instead of src/java.  It should
be
> >>>>
> >>
> >> up
> >>
> >>> to
> >>>
> >>>>> each project to define how they build and what reports they want
> >>>>> generated.
> >>>>>
> >>>>> Note that the sandbox-build's project.xml suffers from the same
> >>>>
> >>>
> >>> definition
> >>>
> >>>>> as commons-build used to and also needs to be changed.
> >>>>>
> >>>>> David
> >>>>>
> >>>>> --- Gary Gregory <ggregory@seagullsw.com> wrote:
> >>>>>
> >>>>>> Why can't we go /back/ to the version of commons-build that
did
> >>>>>
> >>
> >> not
> >>
> >>> blow
> >>>
> >>>>>> up and /discuss/ it from there. Then we can change all projects
> >>>>>
> >>
> >> in
> >>
> >>> step.
> >>>
> >>>>>> ?
> >>>>>>
> >>>>>> Thank you,
> >>>>>> Gary
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>>>>> To unsubscribe, e-mail:
> >>>>>
> >>
> >> commons-dev-unsubscribe@jakarta.apache.org
> >>
> >>>>>> For additional commands, e-mail:
> >>>>>
> >>
> >> commons-dev-help@jakarta.apache.org
> >>
> >>>>>
> >>>>> __________________________________
> >>>>> 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
> >>
> >>>> --
> >>>> Mark R. Diggory
> >>>> Software Developer - VDC Project
> >>>> Harvard MIT Data Center
> >>>> http://www.hmdc.harvard.edu
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >> This e-mail, including any attachments, is a confidential business
> >> communication, and may contain information that is confidential,
> >> proprietary and/or privileged.  This e-mail is intended only for the
> >> individual(s) to whom it is addressed, and may not be saved, copied,
> >> printed, disclosed or used by anyone else.  If you are not the(an)
> >> intended recipient, please immediately delete this e-mail from your
> >> computer system and notify the sender.  Thank you.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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


---------------------------------------------------------------------
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