On 4/16/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
On 12.04.2007, at 19:56, Niall Pemberton wrote: > On 4/12/07, Torsten Curdt <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
