Re: River Musings

2015-09-01 Thread Dawid Loubser
Another vote for using org.apache.river everywhere - if it's not called Jini from a branding perspective, it shouldn't be in the code (yet another thing that adds cognitive overhead). 3.0 is not backwards-compatible in anyway, right? So may as well force a package name change. I know I'm going to

Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0

2015-09-01 Thread Patricia Shanahan
+1 On 9/1/2015 7:35 AM, Bryan Thompson wrote: Peter, I hardly think it matters. It just needs to be checked in under org.apache.river as far as I understand it. So my suggestion was: org.apache.river.concurrent Probably do this in Dennis's branch:

Re: River Musings

2015-09-01 Thread Bryan Thompson
Dennis, can you comment on how much pain (and what steps) were involved in the package rename you performed? What difficulty level would be involved in moving the historical com.sun.jini packages into an org.apache.river.impl namespace? Can this be done with a suitable sed/ask script and moving

Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0

2015-09-01 Thread Peter
Bryan, The only CI tests run on a regular basis are for qa-refactor, it is relatively simple to configure these tests to run the new branch, the jtreg tests have to be run manually however, jtreg is installed on Hudson, but incorrectly, it needs to be raised as an issue with the hudson

Re: River Musings

2015-09-01 Thread Palash Ray
May I suggest that we should name com.sun.jini to org.apache.river.internal? I agree that com.sun.* meant to be internal and discouraged for public use. Thanks, Palash. On Tue, Sep 1, 2015 at 6:33 AM, Bryan Thompson wrote: > Dennis, can you comment on how much pain (and what

Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0

2015-09-01 Thread Peter
Where would you like the code committed? The less work for me, the faster it will happen. Regards, Peter. On 1/09/2015 12:36 AM, Greg Trasuk wrote: Yes and no. He put the sources in a jar file inside the deps-lib/rc-libs folder in the qa-refactor branch. Branch is at:

Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0

2015-09-01 Thread Bryan Thompson
Peter, I hardly think it matters. It just needs to be checked in under org.apache.river as far as I understand it. So my suggestion was: org.apache.river.concurrent Probably do this in Dennis's branch: https://svn.apache.org/repos/asf/river/jtsk/skunk/qa-refactor-namespace/trunk/ Once

Re: River Musings

2015-09-01 Thread Greg Trasuk
My opinion…. - There is “Jini API” - This is the interfaces and implementations that are meant to be quite long-lasting and define how to build services and clients that are independent of any particular implementation. e.g. it should be immaterial whether a service or client runs under

Re: River Musings

2015-09-01 Thread Dennis Reedy
The bulk rename of com.sun.jini and com.artima to org.apache.river was meant to move the namespace to the org.apache.river realm. I think it is implicit that the namespace org.apache.river defines project specific implementations of the net.jini namespace semantics. Remember, the net.jini

Re: River Musings

2015-09-01 Thread Greg Trasuk
> On Sep 1, 2015, at 9:55 AM, Dennis Reedy wrote: > > The bulk rename of com.sun.jini and com.artima to org.apache.river was meant > to move the namespace to the org.apache.river realm. I think it is implicit > that the namespace org.apache.river defines project

Re: River Musings

2015-09-01 Thread Bryan Thompson
I am good with that. Keeping net.jini makes perfect sense in terms of the standardization process that went into river. What are the steps to a release then? Are there any reasons not to bring the branch in which Dennis did the renaming to the trunk? We do need to get the custard-apply code