You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dan Creswell <da...@dcrdev.demon.co.uk> on 2007/07/22 11:52:30 UTC
Discuss: Package Naming for Incubator Release of River
Hello all,
After much grinding of gears, the Apache River project has now received
from Sun all the relevant source code pertaining to the Jini technology.
The process of source code handover has taken a substantial amount of
time and thus we (the Apache River project) propose to issue a release
as soon as possible. We believe this will achieve at least two things:
(1) Demonstrate to the community of existing users that we are serious
about providing continuity for Jini.
(2) Familiarise ourselves with the Apache release process.
A key impediment to such a release revolves around package naming.
There are a number of packages currently under the com.sun.jini
namespace which our user community (including tools vendors) routinely
relies on. We believe that under current Apache rules making a release
without removing and/or renaming com.sun.jini.* to for example
org.apache.river.jini.* is not possible. Obviously we are concerened
that removing and/or renaming these packages could have significant and
undesirable impact on the user community.
We would appreciate some clarification in respect of the above and some
guidance on what the minimum requirements might be. For example would
it be acceptable to create a compatibility layer and thus, for at least
this first release, have both com.sun and org.apache namespaces present
in our codebase and release? This would allow our users some time to
transition smoothly to the new package namespace.
Many thanks,
Dan Creswell
Apache River Committer
Re: Discuss: Package Naming for Incubator Release of River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Hi Niclas,
Niclas Hedhman wrote:
> On Monday 23 July 2007 03:14, Jochen Wiedmann wrote:
>> On 7/22/07, Niclas Hedhman <ni...@hedhman.org> 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.
Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 23 July 2007 03:14, Jochen Wiedmann wrote:
> On 7/22/07, Niclas Hedhman <ni...@hedhman.org> 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.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 7/22/07, Niclas Hedhman <ni...@hedhman.org> 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.
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Davanum Srinivas <da...@gmail.com>.
How about some tools to make the migration easier? I remember some like this
when the com.sun.swing got changed
(http://www.ternent.com/tech/regexp.html). Maybe we should whip up a
retroweaver like tool for migration efforts
(http://retroweaver.sourceforge.net/) - to support existing codebases.
I do think there should be a clear plan posted on the migration path
for my vote :)
-- dims
On 7/22/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> > We would appreciate some clarification in respect of the above and some
> > guidance on what the minimum requirements might be. For example would
> > it be acceptable to create a compatibility layer and thus, for at least
> > this first release, have both com.sun and org.apache namespaces present
> > in our codebase and release? This would allow our users some time to
> > transition smoothly to the new package namespace.
>
> IMHO, yes transitional solutions are acceptable, and possibly even preferable.
>
> *I* would like to see;
>
> First Incubating Release - current package names.
>
> Then (optionally) - compatibility layer where org.apache.river wraps the
> com.sun.jini classes.
>
> Last Incubating release - the com.sun.jini classes are the wrappers to the
> org.apache.river classes.
>
> First Full Apache release - only org.apache.river classes.
>
> And I also think there is no contention about keeping the net.jini API classes
> as-is, without package name changes, which is what the majority of the Jini
> users actually refers to.
>
> Would that work?
>
>
> Cheers
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: Discuss: Package Naming for Incubator Release of River
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/22/07, Ted Husted <hu...@apache.org> wrote:
> IMHO, unless there are trademark or licensing issues involved,
do we have the required trademark license from sun?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 24 July 2007 00:30, Robert Burrell Donkin wrote:
> On 7/23/07, Jim Hurley <Ji...@sun.com> wrote:
> > On Jul 22, 2007, at 2:15 PM, Ted Husted wrote:
> > > IMHO, unless there are trademark or licensing issues involved,
> >
> > I don't believe there are issues involved - Sun filed a Software Grant
> > to contribute the code to the Foundation.
>
> does the grant cover trademarks?
Is com.sun package name a trademark?? Can I donate a codebase without giving
you the right not to use it as-is??
This thread doesn't cover the Jini explicit trademarks.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Jim Hurley wrote:
> On Jul 23, 2007, at 12:30 PM, Robert Burrell Donkin wrote:
>> On 7/23/07, Jim Hurley <Ji...@sun.com> wrote:
>>> On Jul 22, 2007, at 2:15 PM, Ted Husted wrote:
>>> > IMHO, unless there are trademark or licensing issues involved,
>>> :
>>>
>>> I don't believe there are issues involved - Sun filed a Software Grant
>>> to contribute the code to the Foundation.
>>
>> does the grant cover trademarks?
>>
>> - robert
>
> IANAL, so I can't definitively say if things are covered. My assumption
> is that the Software Grant (for the Foundation accepting code
> contributions)
> would be sufficient legally to allow Apache projects to use and advance
> the code contributed. If it's not, someone will need to explicitly
> articulate
> the issue.
>
> Thanks to all that responded to this thread. Otherwise, I think we
> (River project)
> have the guidance we need to define our roadmap forward.
>
+1
And once again, thanks to all for the rapid responses.
Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 23, 2007, at 12:30 PM, Robert Burrell Donkin wrote:
> On 7/23/07, Jim Hurley <Ji...@sun.com> wrote:
>> On Jul 22, 2007, at 2:15 PM, Ted Husted wrote:
>> > IMHO, unless there are trademark or licensing issues involved,
>> :
>>
>> I don't believe there are issues involved - Sun filed a Software
>> Grant
>> to contribute the code to the Foundation.
>
> does the grant cover trademarks?
>
> - robert
IANAL, so I can't definitively say if things are covered. My assumption
is that the Software Grant (for the Foundation accepting code
contributions)
would be sufficient legally to allow Apache projects to use and advance
the code contributed. If it's not, someone will need to explicitly
articulate
the issue.
Thanks to all that responded to this thread. Otherwise, I think we
(River project)
have the guidance we need to define our roadmap forward.
-Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/23/07, Jim Hurley <Ji...@sun.com> wrote:
> On Jul 22, 2007, at 2:15 PM, Ted Husted wrote:
> > IMHO, unless there are trademark or licensing issues involved,
> :
>
> I don't believe there are issues involved - Sun filed a Software Grant
> to contribute the code to the Foundation.
does the grant cover trademarks?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 22, 2007, at 2:15 PM, Ted Husted wrote:
> IMHO, unless there are trademark or licensing issues involved,
:
I don't believe there are issues involved - Sun filed a Software Grant
to contribute the code to the Foundation.
-Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I disagree .. and we've had this conversation here before; with ActiveMQ
IIRC. Org.apache.* is a way to let the programmer know that they're using
an Apache product and IMO its important to make that transition as part of
incubation.
I'm +1 to the staged model Niclas proposed.
Sanjiva.
William A. Rowe, Jr. wrote:
> Ted Husted wrote:
>> IMHO, unless there are trademark or licensing issues involved, there
>> should be no "Apache rules" about Java package naming schemes. Package
>> names are an arbitrary implementation detail, and the one and only
>> concern should be what makes the most sense to the individual
>> community. When it comes to implementation details, the controlling
>> "Apache rule" should be that "The PMC as a whole is the entity that
>> controls the project, nobody else."
>
> There are rules, and then again there are guidelines. I don't think that
> a generic statement about packaging conventions is a bad thing to help
> projects new to the incubator.
>
> Adding a statement something along the lines of what you wrote above would
> be a good thing, so that PMC's know they have flexibility beyond the guidelines.
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ted Husted wrote:
> IMHO, unless there are trademark or licensing issues involved, there
> should be no "Apache rules" about Java package naming schemes. Package
> names are an arbitrary implementation detail, and the one and only
> concern should be what makes the most sense to the individual
> community. When it comes to implementation details, the controlling
> "Apache rule" should be that "The PMC as a whole is the entity that
> controls the project, nobody else."
There are rules, and then again there are guidelines. I don't think that
a generic statement about packaging conventions is a bad thing to help
projects new to the incubator.
Adding a statement something along the lines of what you wrote above would
be a good thing, so that PMC's know they have flexibility beyond the guidelines.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Ted Husted <hu...@apache.org>.
IMHO, unless there are trademark or licensing issues involved, there
should be no "Apache rules" about Java package naming schemes. Package
names are an arbitrary implementation detail, and the one and only
concern should be what makes the most sense to the individual
community. When it comes to implementation details, the controlling
"Apache rule" should be that "The PMC as a whole is the entity that
controls the project, nobody else."
-Ted.
On 7/22/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> > We would appreciate some clarification in respect of the above and some
> > guidance on what the minimum requirements might be. For example would
> > it be acceptable to create a compatibility layer and thus, for at least
> > this first release, have both com.sun and org.apache namespaces present
> > in our codebase and release? This would allow our users some time to
> > transition smoothly to the new package namespace.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> For some APIs in com.sun.jini there might be value in a compatibility
> layer such as the starter framework among other things people often
> refer to in configuration files. For most of the classes though in
> com.sun.* I don't think there is much reliance on (these are merely the
> implementation details for the net.jini API or represent the
> contributed services).
Here's a quick take at where various com.sun.jini classes might likely
be referenced:
.admin.DestroyAdmin - admin proxy classes, admin proxy users
.config.<multiple> - config files
.discovery.<multiple> - constraints in config files
.landlord.<multiple> - lease implementations
.lease.<multiple> - lease implementations
.logging.Levels - logging property files
.lookup.entry.BasicServiceType - service impls
.mahalo.<multiple>Impl - config files
.mahalo.MahaloPermission - security policy files
.mercurity.<multiple>Impl - config files
.mercury.MercuryPermission - security policy files
.norm.<multiple>Impl - config files
.norm.NormPermission - security policy files
.outrigger.<multiple>Impl - config files
.outrigger.JavaSpaceAdmin/AdminIterator - admin proxy users (deprecated)
.outrigger.OutriggerPermission - security policy files
.phoenix.<multiple> - config files
.reggie.<multiple>Impl - config files
.reggie.RegistrarPermission - security policy files
.start.LifeCycle/ServiceProxyAccessor - service impl classes
.start.<multiple> - config files
.thread.TaskManager - config files
.tool.<multiple> - ant tasks, config files
- Bob
Re: Discuss: Package Naming for Incubator Release of River
Posted by Mark Brouwer <ma...@cheiron.org>.
Sean Landis wrote:
> I *am* sensitive to the notion of compatibility but I would argue that
> no effort should be spent creating a compatibility layer for the
> com.sun.jini classes. It has historically been made perfectly clear
> that the developer depends on these classes at his/her peril. There is
> plenty of work to do and I do not think time should be spent on this.
For some APIs in com.sun.jini there might be value in a compatibility
layer such as the starter framework among other things people often
refer to in configuration files. For most of the classes though in
com.sun.* I don't think there is much reliance on (these are merely the
implementation details for the net.jini API or represent the
contributed services).
I also don't know whether a compatibility layer can be a 100% solution
without getting into a complete code duplication effort and to what
extent it introduces its own set of problems. Personally I don't have
much interest in such a layer, but maybe others have and did an
assessment what is required and can provide a more informed opinion on
this matter and whether they would also help to implement and maintain it.
--
Mark
Re: Discuss: Package Naming for Incubator Release of River
Posted by Sean Landis <se...@gmail.com>.
I *am* sensitive to the notion of compatibility but I would argue that
no effort should be spent creating a compatibility layer for the
com.sun.jini classes. It has historically been made perfectly clear
that the developer depends on these classes at his/her peril. There is
plenty of work to do and I do not think time should be spent on this.
On 7/22/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> > We would appreciate some clarification in respect of the above and some
> > guidance on what the minimum requirements might be. For example would
> > it be acceptable to create a compatibility layer and thus, for at least
> > this first release, have both com.sun and org.apache namespaces present
> > in our codebase and release? This would allow our users some time to
> > transition smoothly to the new package namespace.
>
> IMHO, yes transitional solutions are acceptable, and possibly even preferable.
>
> *I* would like to see;
>
> First Incubating Release - current package names.
>
> Then (optionally) - compatibility layer where org.apache.river wraps the
> com.sun.jini classes.
>
> Last Incubating release - the com.sun.jini classes are the wrappers to the
> org.apache.river classes.
>
> First Full Apache release - only org.apache.river classes.
>
> And I also think there is no contention about keeping the net.jini API classes
> as-is, without package name changes, which is what the majority of the Jini
> users actually refers to.
>
> Would that work?
>
>
> Cheers
> Niclas
>
Re: Discuss: Package Naming for Incubator Release of River
Posted by Davanum Srinivas <da...@gmail.com>.
How about some tools to make the migration easier? I remember some like this
when the com.sun.swing got changed
(http://www.ternent.com/tech/regexp.html). Maybe we should whip up a
retroweaver like tool for migration efforts
(http://retroweaver.sourceforge.net/) - to support existing codebases.
I do think there should be a clear plan posted on the migration path
for my vote :)
-- dims
On 7/22/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> > We would appreciate some clarification in respect of the above and some
> > guidance on what the minimum requirements might be. For example would
> > it be acceptable to create a compatibility layer and thus, for at least
> > this first release, have both com.sun and org.apache namespaces present
> > in our codebase and release? This would allow our users some time to
> > transition smoothly to the new package namespace.
>
> IMHO, yes transitional solutions are acceptable, and possibly even preferable.
>
> *I* would like to see;
>
> First Incubating Release - current package names.
>
> Then (optionally) - compatibility layer where org.apache.river wraps the
> com.sun.jini classes.
>
> Last Incubating release - the com.sun.jini classes are the wrappers to the
> org.apache.river classes.
>
> First Full Apache release - only org.apache.river classes.
>
> And I also think there is no contention about keeping the net.jini API classes
> as-is, without package name changes, which is what the majority of the Jini
> users actually refers to.
>
> Would that work?
>
>
> Cheers
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> We would appreciate some clarification in respect of the above and some
> guidance on what the minimum requirements might be. For example would
> it be acceptable to create a compatibility layer and thus, for at least
> this first release, have both com.sun and org.apache namespaces present
> in our codebase and release? This would allow our users some time to
> transition smoothly to the new package namespace.
IMHO, yes transitional solutions are acceptable, and possibly even preferable.
*I* would like to see;
First Incubating Release - current package names.
Then (optionally) - compatibility layer where org.apache.river wraps the
com.sun.jini classes.
Last Incubating release - the com.sun.jini classes are the wrappers to the
org.apache.river classes.
First Full Apache release - only org.apache.river classes.
And I also think there is no contention about keeping the net.jini API classes
as-is, without package name changes, which is what the majority of the Jini
users actually refers to.
Would that work?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discuss: Package Naming for Incubator Release of River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> We would appreciate some clarification in respect of the above and some
> guidance on what the minimum requirements might be. For example would
> it be acceptable to create a compatibility layer and thus, for at least
> this first release, have both com.sun and org.apache namespaces present
> in our codebase and release? This would allow our users some time to
> transition smoothly to the new package namespace.
IMHO, yes transitional solutions are acceptable, and possibly even preferable.
*I* would like to see;
First Incubating Release - current package names.
Then (optionally) - compatibility layer where org.apache.river wraps the
com.sun.jini classes.
Last Incubating release - the com.sun.jini classes are the wrappers to the
org.apache.river classes.
First Full Apache release - only org.apache.river classes.
And I also think there is no contention about keeping the net.jini API classes
as-is, without package name changes, which is what the majority of the Jini
users actually refers to.
Would that work?
Cheers
Niclas