On May 5, 2009, at 7:27 PM, Paul C. Bryan wrote:
> Hi Paul:
>
> Thanks for the feedback. Some follow-up questions/comments:
>
> 1. Is there a script (or Maven plugin) that can keep version numbering
> of modules in sync? If not, how are you keeping them synchronized?
>
There is no script and we just make sure the poms have the same
version manually. When we upgrade the version i do an automatic search
and replace in all the pom files. Some people use a sed script, but
NBs has a handy replace all in project files, which i use.
> 2. I'm currently a bit cautious about extending dependencies for the
> core OAuth signature library into any other part of Jersey, namely
> because right now it's self-contained, with only dependency being on
> Java SE. Thoughts?
>
OK, i have no problem with that.
Paul.
> Paul
>
> On Tue, 2009-05-05 at 11:40 +0200, Paul Sandoz wrote:
>> On May 5, 2009, at 1:57 AM, Paul C. Bryan wrote:
>>
>>> Hi Devs:
>>>
>>> I've created a new branch:
>>>
>>> https://jersey.dev.java.net/svn/jersey/branches/oauth-extensions/
>>>
>>> In this branch, I've checked-in the initial code dump for the OAuth
>>> digital signature library, including an initial unit test:
>>>
>>> jersey/contribs/jersey-oauth/oauth-sig/
>>>
>>> As I'm relatively new to Jersey and Maven, I would appreciate some
>>> feedback on whether I got this right, or if the work is in need of
>>> revision.
>>>
>>
>> Looks OK. The only main thing is when we merge with the trunk the
>> version number of the oauth modules should be the same as that for
>> the
>> modules in the trunk i.e. all modules are in sync.
>>
>>
>> I notice you checked in a class to support base 64 encoding.
>>
>> I recently added one to the jersey-core module, so you could reuse
>> that if you wish (and modify that to suite your requirements):
>>
>> https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/core/util/Base64.html
>>
>>
>> The jersey core also contains utilities to encode/decode components
>> URIs:
>>
>> https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/api/uri/UriComponent.html
>>
>> So rather than:
>>
>>
>> buf
>> .append('&').append(URLCodec.encode(constructRequestURL(request)));
>>
>> you could do:
>>
>>
>> buf
>> .append('&').append(UriComponent.encode(constructRequestURL(request),
>> UriComponent.Type.QUERY));
>>
>> But i understand why you might be cautious as canonicalizing stuff is
>> so very sensitive to errors.
>>
>> Jersey also contains URI building functionality, so one does not need
>> to utilize string buffers, but i am not sure that is suitable in your
>> case, given that URI building utilizes templates (however, we can
>> modify the implementation in Jersey as required).
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>