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
+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:
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
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
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
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:
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
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
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
> 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
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
11 matches
Mail list logo