incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <>
Subject Re: Discuss: Package Naming for Incubator Release of River
Date Wed, 25 Jul 2007 08:34:39 GMT
Hi Niclas,

Niclas Hedhman wrote:
> On Monday 23 July 2007 03:14, Jochen Wiedmann wrote:
>> On 7/22/07, Niclas Hedhman <> wrote:
>>> Last Incubating release - the com.sun.jini classes are the wrappers to
>>> the org.apache.river classes.
>> At that point (I don't see a necessity for the previous steps, btw, it
>> only complicates things, IMO) I'd also recommend to distribute the
>> com.sun.* classes in a separate jar file.
> "previous step" refering to that, or the wrapping the other way around?
> What I wanted to communicate was that "wrap com.sun" with "org.apache" classes 
> sounds like a very simple step, but I also wrote "optionally" since it might 
> be just as easy to do the other way around. The intent is to give the tools 
> vendors a window where both the org.apache and com.sun classes will work 
> interchangably. Suggestions of retroweaving and other techniques is up to the 
> River team to decide.
> Ted, 
> I agree that the PMC is ultimately responsible for choosing what works for 
> them. And right now, that is the Incubator PMC, hence Dan's question here. 
> Now, the people behind River has discussed this issue a lot prior to entering 
> the incubator, and IIRC the conclusion was that most users only references 
> the net.jini classes, and they will therefor be kept. They denote the APIs. 
> Dan's request now is mostly about a handful of tools developers, who has some 
> headaches to deal with if the package names change overnight. And *I* think a 
> staged approach is probably acceptable to all involved parties.
> Dan,
> I realize that my suggestion may cause serialization problems, but i have not 
> enough insight in the internals of Jini 2.0 to be definite on that topic. I 
> am sure you are able to figure these things out. End of the day, there are 
> no "rules", only weak "guidelines" and as Sanjiva and others illustrate there 
> are many opinions on the topic. I think the only reasonable solution for 
> *you* is to make it work technically, with an ambition(!) of having the 
> com.sun classes replaced, which may not be feasible, then act accordingly.

Yep you're right there might be some issues in respect of serialization
etc. I'm confident that we can find a workable starting point given the
flexibility available re: naming as covered by you and others in this
thread.  The staged plan you suggest is exactly the sort of thing I'd
been considering - great minds....

Thanks for the considered response and guidance - much appreciated.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message