commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [vote] release commons jci RC1 as 1.0
Date Wed, 18 Apr 2007 03:23:18 GMT
On 4/16/07, Torsten Curdt <tcurdt@apache.org> wrote:
>
> On 12.04.2007, at 19:56, Niall Pemberton wrote:
>
> > On 4/12/07, Torsten Curdt <tcurdt@apache.org> wrote:
> >> Niall, really appreciate our input!
> >>
> >> On 12.04.2007, at 06:22, Niall Pemberton wrote:
> >>
> >> > 1) NOTICE / LICENSE
> >> > The issue raised by Rahul about the missing NOTICE and LICENSE
> >> files
> >> > gets a bit complex.They are not specified as a "resource"
> >> element in
> >> > version 2 of the commons parent pom (which AFAIK would cause
> >> them to
> >> > be included in all modules) because of a bug in the maven source
> >> > plugin (MSOURCES-6) with resource elements in the base directory
> >> - so
> >> > it has an "antrun" workaround which doesn't seem to have worked in
> >> > this multi-module case.
> >>
> >> Grr
> >>
> >> > We're still waiting for a release of that
> >> > plugin so the workaround can be removed. One solution is to move
> >> these
> >> > to jci/src/main/resources (which is the default resources
> >> location for
> >> > maven)
> >>
> >> For every artifact you mean?
> >
> > It looks that way - projects like Shale have done that - but maybe one
> > of the maven gurus can offer a better idea.
>
> Well, would have been nice if that wasn't required - but you already
> worked around it :)
>
> <snip/>
>
> >> > Usually I don't mind
> >> > whether people use the older RC method or create the actual
> >> aritifacts
> >> > to be distributed - but in this case theres too many things to
> >> forget
> >> > in a multi-module release so I won't vote on a RC for JCI - only
> >> the
> >> > actual artifacts.
> >>
> >> So you want really individual votes for each artifact? ...keep in
> >> mind
> >> there is only one site though.
> >
> > Sorry, didn't say that very well. What I meant was rather than
> > producing "release candidate" artifacts (i.e with version 1.0-RC1
> > numbers) - I'd rather vote on the actual artifacts that are going to
> > be deployed if the votes passes - i.e. with the proper 1.0 version
> > number.
>
> Ah! OK
>
> > A number of components have done this recently and it means
> > less chance of something going wrong after the vote passes as it
> > simply becomes a case of copying the jars/distros that have been voted
> > on rather than building a whole new set when "cutting a release".
>
> True and makes total sense. Unfortunately the maven release process
> does not really adhere to that - unless I am missing something.
>
>   mvn release:prepare -Prc
>   mvn release:perform -Prc
>
> Creates the tag and deploy to the snapshot repo.
>
>   mvn release:prepare -Prelease
>   mvn release:perform -Prelease
>
> Would be next ....but that would not match our (or the quite common)
> process of turning a RC into a release.

AIU projects using m2 that vote on actual release artifacts use a
"staging" repository - but I guess that would take a change in the
commons pom first. Anyway ignore my comment - I've not done a release
using m2 and I guess if you resolve the reason why the release plugin
didn't correctly update all the dependency versions for the RC then it
should be OK.

> >> > 3) Source/Binary distros
> >> > Any reason not to produce the usual source/binary distros for JCI -
> >> > rather than just maven artifacts?
> >>
> >> Well, how much different would that be? We could zip up artifacts
> >> but e.g. the site does not work offline (stupid!) unless you do a
> >> site:stage.
> >>
> >> Any suggestions?
> >
> > Site doesn't need to be included IMO - but a binary distro with all
> > the JCI jars and javadocs would be nice and a source distro which is
> > just a zip of the whole src repo. If I get time later I could add an
> > assembly to create these.
>
> Thanks for that!
>
> >> > 5) site.xml
> >> > Seems that all the modules are using the parent site.xml, since
> >> they
> >> > don't have one - which means all the module sites have a "Usage",
> >> > "FAQ" and "Downloads" links which are broken. You probably need to
> >> > include site.xml for each module to avoid this.
> >>
> >> As the site.xml is inherited I would assume the links get adjusted.
> >>
> >> That sucks! How stupid is that?
> >
> > True and probably doesn't matter for the release since you're not
> > shipping that. So perhaps something to ponder after.
>
> Well, would love to have a working site. Release or not ;) Stupid
> maven multiproject stuff.
>
> cheers
> --
> Torsten
>
>
>
> ---------------------------------------------------------------------
> 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