Paul Sandoz wrote:
> Farrukh Najmi wrote:
>> Farrukh Najmi wrote:
>>> Paul Sandoz wrote:
>>>> Farrukh Najmi wrote:
>>>>
....
>>>
>>> Perhaps we are all not in sync with maven conventions. An
>>> xx-SNAPSHOT release means that the release is a pre-release and
>>> therefor potentially incomplete
>>> version of the next major release. So 0.4-SNAPSHOT is misleading
>>> since the next major release is 0.4.
>>
>> Oops I meant to say "So 0.4-SNAPSHOT is misleading since the next
>> major release is 0.5."
>>
>
> As you can probably guess by the following i am no maven expert :-)
>
> "incomplete" in what sense, meaning it can change at any time?
XXX-SNAPSHOP means interim bits of release XXX while it is "in
development". Its kind of like nitely builds.
>
> What would be the correct convention for such stable early access
> releases? the version without the suffix "-SNAPSHOT" ?
Its just another release and can have any name you want. However, if you
want to use maven-release-plugin (a huge timesave) then it is common to
name such stable releases
x.y or x.y.z and their snapshots x.y-SNAPSHOT and x.y.z-SNAPSHOT. See
following for the release naming convention that works nicely with
maven-release-plugin:
<
http://apr.apache.org/versioning.html#examples>
>
>
>
>>> It will also cause problem with maven dependency management as maven
>>> will consider 0.4-SNAPSHOT older than 0.4 release if there were one.
>>>
>>>>> So what we have gets maven folks to have a temporary alternative
>>>>> though it is not giving the benefits that I cited to project team
>>>>> until full mavenization of project is done at a convenient time.
>>>>>
>>>>
>>>> Yes, for *stable* releases.
>>>
>>> Perhaps that was the intent but it seems to be working out rather
>>> nicely for thos of us building on latest bits and wanting maven
>>> modules built so we can depend on them.
>>> Any reason there is danger in this unintended use model?
>>>
>>
>
> We are in a slightly unusual position in that we make changes to the
> JAX-RS API as agreed in the EG and the RI catches up by implementing
> these changes. We want to get as much feedback as possible on the API
> by way of people playing with the RI but don't want to confuse people
> with intermediate versions of the API that have been created for the
> purposes of latest implementation.
>
> The 0.5 Jersey version in the trunk does not fully implement the 0.5
> API, it implements an intermediate version.
Then it should be called 0.5-SNAPSHOT until it is released. Currently if
I use the jersey/maven/pom.xml and run "mvn install" in latest bits it
creates version 0.5-ea-SNAPSHOT.
So that seems consistent with what you said.
The problem is more that the version for jsr311-api seems incorrect.
Curtrently it produces "0.4-SNAPSHOT" but I believe that it SHOULD
"0.5-SNAPSHOT" if the current bits reflect SNAPSHOT or dev versions of
version 0.5 of spec.
> Only when 0.5 Jersey goes stable will it be considered to implement
> the 0.5 API. This is because it is really hard to implement all the
> changes of the API from 0.4 to 0.5 in one go. I want to do it in small
> testable and incremental steps, but don't want to push out
> intermediate and incremental versions of the API for general use.
>
>
> Would it help you if a "simple" pom.xml was in the jersey trunk for
> you to directly use that links to the jars in the jersey/lib directory?
I am all set for now thanks to the jersey/maven/pom.xml that some kind
soul already did. I know you said it was to push stable releases out but
it seems to do the right thing for SNAPSHOTs as well. SO I do not think
any work is needed to improve the stop gap maven support. Thanks very much.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com