On Mon, 2008-05-26 at 16:48 +0200, Paul Sandoz wrote:
> Martin Grotzke wrote:
> > Hi,
> >
> > I just merged the changes into the trunk, so the directory structure
> > changed, jersey is now located at trunk/jersey/jersey.
> >
> > And
> > mvn -f maven/pom.xml install
> > still produces binary and source distributions.
> >
>
> I checked things out and everything worked in and out of NB :-)
Great :)
>
> Unfortunately the internal Hudson server is down, so i will have to fix
> up the automated build tomorrow.
Ok.
Cheers,
Martin
>
> Thanks,
> Paul.
>
> > Cheers,
> > Martin
> >
> >
> > On Mon, 2008-05-26 at 14:50 +0200, Paul Sandoz wrote:
> >> Martin Grotzke wrote:
> >>> 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.
> >>>
> >> Will do.
> >>
> >>
> >>>>>>>> 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 :)
> >>>
> >> Thanks for reminding me, as soon as the changes are in i will
> >> re-configure the Hudson job.
> >>
> >>
> >>>>> 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].
> >>>
> >> Excellent!
> >>
> >>
> >>>>>>>> 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 ;)
> >>>
> >> Indeed!
> >>
> >> Paul.
> >