commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [vote] release commons jci RC1 as 1.0
Date Mon, 16 Apr 2007 00:13:07 GMT

On 12.04.2007, at 19:56, Niall Pemberton wrote:

> On 4/12/07, Torsten Curdt <> wrote:
>> Niall, really appreciate our input!
>> On 12.04.2007, at 06:22, Niall Pemberton wrote:
>> > 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 :)


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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message