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