On Mon, 2008-05-26 at 12:41 +0200, Paul Sandoz wrote:
> Martin Grotzke wrote:
> > On Mon, 2008-05-26 at 11:53 +0200, Paul Sandoz wrote:
> >> Martin Grotzke wrote:
> >>> On Mon, 2008-05-26 at 09:43 +0200, Paul Sandoz wrote:
> >>>> Hi Martin,
> >>>>
> >>>> This looks really good. I agree with merging back to the trunk sooner
> >>>> rather than later.
> >>> What prevents us from doing this right now?
> >>>
> >> Nothing :-) I think it can be done today, but with one request for a
> >> constraint, namely backwards compatibility, see below...
> > Great :)
> >
> > Are you going to do the merge or shall I do it (after open issues are
> > clarified)?
> >
>
> Do you want to?
Ok, I can do that today. So it would be good that there's nothing
committed before the merge.
> >>
> >>>> In the interim period we just need to make sure we
> >>>> can produce the same bits directly using ant [*] (i am currently
> >>>> depending on the NB ant project for development).
> >>> What do you mean with "produce the same bits directly using ant?
> >>>
> >> I mean the zip files (including the existing non-mavenized examples) as
> >> some developers rely on those that are pushed to java.net.
> > What zip-files do you mean? Do you have a link where to find them?
> >
>
> When:
>
> mvn -f maven/pom.xml install
>
> is executed, have a look in the jersey/dist directory, you should see:
>
> jersey-0.8-ea.zip # binary distribution
> jersey-snapshot-0.8-ea.zip # workspace/source distribution
>
> those are pushed to java.net by Hudson.
Ok, I can test then that this still works, right now in the branch it
still works.
One thing that obviously has to be changed in the hudson configuration
then is the directory of jersey (trunk/jersey -> trunk/jersey/jersey) -
just want to mention it :)
>
>
> > Is this a source-distribution of the whole jersey project, including
> > samples, contribs and jersey (modules)?
> >
>
> Yes, and the binary zip too.
Ok, such a distribution build should be achievable via the
maven-assembly-plugin [1].
>
>
> > I don't know what your requirement actually is. Is it, that this
> > artifact / these artifacts can also be created with maven? Or is it,
> > that artifacts that will be created by maven can also be created by ant?
> >
>
> The requirement is: don't break the existing ant behavior while we are
> transitioning.
Got it :)
>
>
> > *somehow confused* :)
> >
> >>
> >>> As I read in Adam Bien's blog [1] integration of maven into NB is really
> >>> smooth. Did you try to open the mavenized jersey project from the branch
> >>> with NB?
> >>>
> >> I agree that Maven support in NB is looking really good, but i am sure
> >> there will be issues with maven and the mysterious versions (see the
> >> unit test issue in NB for running the spring unit tests).
> >>
> >> So i would prefer to be a little conservative, if we can, to retain
> >> backwards compatibility while transitioning so that it does not disrupt
> >> development productivity in the interim (there is lots of development
> >> stuff to do and i don't have time just now to go on a diversion into the
> >> 7th circle of maven hell :-) if i cannot debug or run unit test properly).
> > The jersey stuff (trunk/jersey/jersey) is not changed at all, including
> > trunk/jersey/jersey/examples - this is exactly the same as before.
> >
> > I only added trunk/jersey/samples and made changes to code of examples
> > therein.
> >
>
> OK. I think i am being too paranoid in this respect!
That's totally ok :)
>
>
> >>>> Re: the use of PackagesResourceConfig. I thought this would be the
> >>>> case :-) I wonder if there is anything we could do with respect to
> >>>> maven to simply the configuration, e.g. a Jersey maven plugin that
> >>>> executes using say the Grizzly container?
> >>> Perhaps a grizzly-maven-plugin would be sufficient, if one could specify
> >>> appropriate configuration...?
> >>>
> >> I think one could declare the packages as an argument to the plugin.
> > Yep, exactly. I don't know anything about grizzly, but iIf one could
> > configure servlets with its init-params this would be exactly what we
> > want.
> > So we could ask the grizzly community if there are already plans for
> > stuff like this :)
> >
>
> I was more thinking of using the Jersey Grizzly container directly, then
> it would be up to us to write it. But a general plugin for the Grizzly
> servlet container would work and i think would have wider appeal.
Yes, I think a more generic solution is more useful here. I have no idea
how hard it is to write a maven plugin - never done that - but adding
more genericity should not be the problem. If there were difficulties
with writing a maven plugin I asume they would be there even with
writing a jersey-grizzly plugin ;)
Cheers,
Martin
[1]
http://maven.apache.org/plugins/maven-assembly-plugin/
>
> Paul.