On Nov 10, 2008, at 7:06 PM, Craig McClanahan wrote:
> Paul Sandoz wrote:
>>
>> On Nov 7, 2008, at 7:34 PM, Craig McClanahan wrote:
>>
>>> Paul Sandoz wrote:
>>>> Hi,
>>>>
>>>> Below are three proposals for package renaming, in order of
>>>> disruption (first least disruptive, last most disruptive):
>>>>
>>>> - Proposal 1: ensure that each module has unique package names.
>>>> Thus packages can be sealed.
>>>> Targeted renaming.
>>>>
>>>> - Proposal 2: rename jersey-core and jersey-server.
>>>>
>>>> - Proposal 3: rename jersey-core, jersey-server, jersey-client,
>>>> spring, jersey-json.
>>>>
>>>> All of the proposals would rename the impl packages to be
>>>> consistent (but these should not be depended upon).
>>>>
>>>> I am leaning towards proposal 1 as i really want to minimize
>>>> breakage. But how about a vote? What do you want?
>>>>
>>> Although it took me a while to get used to the
>>> com.sun.jersey.api.* / com.sun.jersey.impl.* split, I must confess
>>> that I currently like them. It is crystal clear which classes are
>>> intended for use, and which ones should be hidden -- as well as
>>> making it easy to avoid javadocing the impl classes as we
>>> currently do.
>>>
>>
>> I managed to achieve proposal 1, slightly differently with i
>> presume less disruption that i proposed, instead the jersey-
>> core:com.sun.jersey.api package was removed and classes have be
>> moved to other areas. I am expecting that those classes are less
>> commonly used that classes in the previously equivalent package in
>> jersey-server.
>>
> I should have time to look at this early this week.
- The following classes in jersey-core have moved:
- The following classes in package "com.sun.jersey.api" have moved to
the package "com.sun.jersey.core.header": InBoundHeaders,
MediaTypes and
OutBoundHeaders.
- The following classe in package "com.sun.jersey.api" have moved to
the package "com.sun.jersey.core.util": MultivaluedMapImpl.
>
>>
>>> That said, if we want to change I'd prefer proposal 3 -- if you're
>>> using jersey-client, you're also potentially using jersey-core and
>>> jersey-multipart, and it would be nice if the package naming
>>> conventions were consistent.
>>
>> Agreed. I am still concerned about breaking changes, but i presume
>> you don't mind having to update your code in this respect?
>>
> Given that we're about to break backwards compatibility in jersey-
> multipart anyway to implement the parameterized header stuff, I'm
> not in much position to complain :-).
:-)
> But for my own work I'm maintaining an internal branch (compatible
> with 1.0 of Jersey) until we release this stuff in 1.1 or whatever.
>> There has not been enough feedback to make me comfortable making
>> such a change. But can i think we can from now on be consistent.
>> Can we change the jersey-multipart package names as they were only
>> introduced for 1.0.1?
>>
> Sure. You want to go ahead and take an initial swipe at them,
> consistent with your overall patterns?
OK.
Paul.