Paul Sandoz wrote:
> Dan Diephouse wrote:
>> Paul Sandoz wrote:
>>>
>>> On timely related matters we have just had a request to make the
>>> jsr311-api.jar available on Maven so that developers can start
>>> implementing. I don't know if it is an issue for other developers or
>>> not that jsr311-api.jar will be distributed with jersey.jar to the
>>> maven repository. I tend to look at it as a good thing because the
>>> API and RI are kept in sync, thus a developer could compare their
>>> implementation with the RI to see if it is doing the same thing.
>> Great! This might be redundant information, but: ideally it should
>> have a group id of javax.ws.rs, an artifact id of jsr311 and a
>> version of 1.0-[DRAFT NAME]. Or if the jar is changing between the
>> draft release, it should be called a 1.0-SNAPSHOT per maven
>> conventions. Any jar that does not end with -SNAPSHOT is considered a
>> final release in maven and isn't supposed to change. This way
>> developers are conscious that they are depending on a changing
>> version and they can depend on draft releases for alphas/betas which
>> won't change.
>>
>
> Thanks, very useful advice.
>
> Aaron has appended the version number to the name of the stable jars,
> java-sources and pom, and the version number is in the pom:
>
> <project ...>
> <modelVersion>4.0.0</modelVersion>
> <groupId>javax.ws.rs</groupId>
> <artifactId>jsr311-api</artifactId>
> <packaging>jar</packaging>
> <version>0.2</version>
> <name>JSR 311 API</name>
> <description>JAX-RS (JSR 311) API</description>
>
>
Looks great, thanks guys!
> By definition a stable jersey/jsr311 release is a distribution whose
> jars will not change, and we plan to only push stable releases to
> maven, hence the jars will not change in maven. Every new stable
> release will have an incremented version of the jersey/jsr311 jars,
> java-sources and poms.
>
> So in this respect IIUC there is no need to use the SNAPSHOT naming
> convention.
>
> I am not sure if this unusual practice or not but it allows us to
> easily track and keep a history of versions, let developers stick with
> certain versions for stability, and for them to provide feedback on a
> version or multiple versions.
>
This is standard practice AFAIK.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog