On Mon, 2008-07-28 at 17:15 +0200, Paul Sandoz wrote:
> Martin Grotzke wrote:
> > On Mon, 2008-07-28 at 11:58 +0200, Paul Sandoz wrote:
> >> Hi Martin,
> >>
> >> Interestingly if i touch or modify the pom.xml then it works, sort of.
> >> Also, the sources are not correctly created.
> >>
> >> At first guess i think this is a bug in the "maven-shade-plugin". I
> >> tried playing around with the configuration [1] with no luck.
> >> Unfortunately i do not have much time to look into this and Jakub is on
> >> holiday for the next two weeks :-(
> > Ok. I also played with the pom.xml but with the same result.
> > So should the shade plugin be disabled first? Or is there a concrete
> > scenario that requires the artifact created by the shade plugin?
> >
>
> We want to create a bundle jar that for those not using maven so that
> they don't have to explicitly included 'n' jars of modules. Do you know
> of any other type of plugin that can support this?
Hmm, no, not out of my head. Another solution would be to provide a bin
release for the whole project, but then developers still have to include
jersey-* jars, in detail jersey-core, jersey-server and perhaps also
jersey-atom, jersey-json and jersey-client.
The developer still has to take external deps like jsr311, asm, rome,
jettison etc. into account. Does shade include these deps, too? I'd
think that not, because this would most probably lead to conflicts.
So I wonder if the advantage of a bundle jar is that big if the
developer still has to include say 8 instead of 12 jars - but of course
8 is better than 12 :)
>
> Do you know how to disable the building of this module by default but
> enable it via an mvn parameter? if so i can modify the Hudson task to do
> that.
The simplest solution should be to remove the according module in
trunk/jersey/pom.xml.
Cheers,
Martin
>
> Paul.