users@jersey.java.net

Re: [Jersey] Source code for Jersey

From: Craig McClanahan <craigmcc_at_gmail.com>
Date: Thu, 1 Jul 2010 18:45:29 -0700

On Thu, Jul 1, 2010 at 6:47 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> On Jun 30, 2010, at 11:25 PM, Jason Winnebeck wrote:
>
>> The sources appear to be all available via the standard way you can get
>> them via Maven. You can browse directly at
>> http://download.java.net/maven/2/com/sun/jersey/. The individual components
>> are each in their own directory, which includes source and javadoc.
>>
>> For example:
>>
>> http://download.java.net/maven/2//com/sun/jersey/jersey-core/1.3/jersey-core-1.3-sources.jar
>>
>> If you want the JSR311 javadocs, they are elsewhere I think. Those appear
>> to be here:
>> http://download.java.net/maven/2//javax/ws/rs/jsr311-api/1.1.1/
>>
>
> And a good maven aware IDE should notice the source artifacts (in addition
> to the javadoc artifacts).
>
> Note that those sources are not meant to be used to compile/build Jersey
> they are only there for read only and debugging purposes.
>
> To build see:
>
>  https://jersey.dev.java.net/nonav/documentation/latest/user-guide.html#d4e1772
>
> Paul.
>
>> Jason

In addition to these pointers, it is worth mentioning that getting a
java.net account (so you can access the repository directly) is both
easy and free:

  https://www.dev.java.net/servlets/Join

Among other things, this has the advantage that you can follow along
with changes in between releases, in case you need something urgently.
 You can often backport fixes from the trunk to your checkout of the
previously released version if you need it right away. Or, if you
patch a problem yourself, you can use your patched version now (and
submit the patch back to the project of course), without having to
wait for the next release.

I make a point of checking out the source of *every* open source
project my code relies on (and there's quite a few of them) for this
very reason. Even if you don't *think* you will need to patch things,
you want to be ready just in case. (At my day job, we even use
patched versions of Spring and Tomcat that haven't yet released
updates including our patches, or we can't necessarily immediately
upgrade to the new release for other reasons -- and in some cases
those projects might choose not to incorporate our patches because
they are too specific to our particular use case).

Craig