users@jersey.java.net

Re: [Jersey] 0.11-ea-SNAPSHOT

From: Imran M Yousuf <imran_at_smartitengineering.com>
Date: Fri, 29 Aug 2008 13:13:28 +0600

On Fri, Aug 29, 2008 at 1:05 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> On Aug 29, 2008, at 8:50 AM, Imran M Yousuf wrote:
>>>
>>> We have our maven release process such that it is nearly automated. I
>>> think
>>> Jakub has things set up so it may almost be possible to tag, convert,
>>> build
>>> and deploy in one or two steps.
>>>
>>> However, there are some additional factors to releasing. Every time we
>>> release we need to test, and this still takes time, so we need to
>>> automate
>>> tests for the examples (adding stuff to the test directory, this can also
>>> serve as examples of how to use the client API). So for the spring
>>> example i
>>> encourage you to use the unit test framework for the client interactions
>>> :-)
>>>
>>
>> I will do that for sure. This weekend is a good time for it :). The
>> splendid automated processes makes it even simpler to test and make
>> frequent (say once a month if there is enough changes) doesn't it?
>>
>
> If we automate everything then theoretically we can release as fast as the
> automation goes :-)
>

I won't disagree :).

>
>>> In addition we need to set up a Hudson matrix job to run the jersey tests
>>> and examples on a number of platforms and JDK versions.
>>>
>>>
>>>> Also in this regard for samples, I would like to add "1.0.x.yy.zz" in
>>>> order to incorporate new and richer samples as they are integrated
>>>> into trunk.
>>>>
>>>
>>> If we release regularly and often i am not sure if this is really
>>> necessary
>>> i.e. for testing/experimental purposes the SNAPSHOT build can be used. My
>>> preference is to keep all Jersey related modules in sync and released at
>>> the
>>> same time rather than spinning some modules faster than others. It is
>>> easier
>>> to manage and there is a clear indication that all modules of the same
>>> version have been tested together. If some modules need to be spun at
>>> different rates then i think it implies that module should be a separate
>>> project.
>>>
>>
>> I agree with both points mentioned, if we release often I would not
>> mind waiting for getting the latest samples neither would I mind if
>> the samples is a separate project as well. Speaking about samples, as
>> I mentioned in another thread, I am working on a sample of NetBeans
>> RCP + Jersey + Spring + Hibernate. So I would be interested to propose
>> that as a 'comprehensive' sample as well. Its current repository is -
>>
>>
>> http://repo.or.cz/w/smart-selection-suite.git?a=shortlog;h=refs/heads/rest-with-jersey
>> (pointing to the branch directly)
>>
>
> OK. I also like the idea of integrating samples when NetBeans when creating
> a new project e.g. provide some as a plugin.
>

Or may be maven archetype? Actually I am trying to save my time as I
will be making a maven archetype for a "sophisticated" NetBeans
Application Sample and integrating Jersey with it can serve both the
purpose :).

> Paul.
>

Best regards,

-- 
Imran M Yousuf
Email: imran_at_smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557