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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas :: http://davanum.wordpress.com
