Re: When com.sun.jini -> org.apache.river [Was: Re: [VOTE] Accept the Starter Kit Contribution from Sun Microsystems]

[Craig L Russell]

Please forgive the top post, I just have a couple of observations.









Craig

On Jun 4, 2007, at 2:40 AM, Mark Brouwer wrote:

There seems to be a conflict between the desire to get the community on board at Apache and to create a new community by making a quick release. The first group want to use the com.sun.jini namespace to get their stuff working in the new environment; the second group need to use the org.apache.river namespace. It might be that you just have to decide on a time frame during which you continue to use the com.sun namespace, have a project that builds, tests, and basically works. During this time, anyone who wants to get their stuff working can do so with minimum disruption. But you don't make a release of these bits. Everyone is a source developer. Later, when stuff actually works, you can as a community decide on the disruptive change of namespace and then consider how to make the code available to a wider audience. I agree with Mark that picking the time frame is probably the hardest thing to do. Just as a thought-provoker, how about October 2007 for the namespace change?

Gianugo Rabellino wrote:

I see your point, and I understand how backward compatibility matters.

On the other hand, my main issue is about branding, which has to deal
with diversity as well. More specifically:
a) from a branding perspective, it should be clear to users that this
is Apache River, not Sun's Jini  (or possibly the Apache
implementation of Sun's Jini specs). This is a clear Incubator
requirement.

to find people willing to work on com.sun.* (think competitors), as
they'd feel they'll be working on Sun stuff, not ASF's.
c) while I can see your point in changing packages as jumping the
cliff, sometimes you just have to burn your boats. Yes, River might

commitment to the community.

b) I believe that diversity builds mainly upon neutrality: it's harder fail incubation, which would mean a mess to the Jini community. On the other hand, playing safe with package names might be a sign of missing

be something that is well thought over and be tested in the field by
some early adopters. To me this seems hard to unite with a quick first
release as has been expressed by some people.

FWIW ome background information for those with a short history with

lot of then future specs in the com.sun.jini namespace because it was
not a standard at that time (i.e. they couldn't use the net.jini

discussions in the Technical Oversight Committee about using the
net.jini namespace at an earlier stage to prevent from this happening.

While I think jumping cliff is necessary at some point, when near a
shore I don't want to have a burnt boat with me. I care a lot of the
current installed base and those who invested in the Jini technology

able to start using and getting confidence in the work of the Apache
River project and I think a good way to achieve that is when they are
able to replace their current binaries and see their systems are still
running fine.

If we can achieve that confidence we will get to the point of doing

an installed base, but at least they might justify that by seeing or
even participating in a project that has at least has shown it can act
as a coherent bunch of individuals.

I agree and understand your points. But besides that I would like to be able to transfer bells and whistles while it is easy to do so, I'm also of the opinion that any disruptive change for the Jini community should Jini. From the Davis project (2002) I can remember that Sun developed a namespace) and from what I can remember the namespace refactoring was a significant one with a lot of impact for early adopters. IIRC there were since a long time, which includes the selfish me :-). I want them to be disruptive changes (such as the namespace changes, maybe going the a new minimal version of Java, etc.). That move will bring costs to those with

I see your point, and I fundamentally agree. All I'm asking is that
package renaming sits somewhere high in the priority list.

as a logical consequence of coming to the ASF.


we should conduct such an effort (hopefully at that time I can take a

parallelism, but no doubt one of the Sun people can tell from previous

our whitespace issues (this one is for you Gregg :-P ), etc.
--
Mark

I think based on discussions in the past we all see changing name spaces Probably the only disagreement will be with regard to the time at which long holiday and we can find one person we supply plenty of beer who is going to do the job (I think it ain't something that allows for a lot of experience what it involves). It will also be a good moment to sort out

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature