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?
>>
>>>> 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.
> Is this a source-distribution of the whole jersey project, including
> samples, contribs and jersey (modules)?
>
Yes, and the binary zip too.
> 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.
> *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!
>>>> 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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109