Re: River 3.0.1 Release candidate

[Bryan Thompson]

+1 I have reviewed this release. Bryan



On Thu, Jul 20, 2017 at 1:11 AM, Peter <j...@zeus.net.au> wrote:
> Don't forget the release artifacts and signatures for the release candidate
> are
> available at:
> https://dist.apache.org/repos/dist/dev/river/
>
> When we have enough people to review we can vote & release.
>
> This is a bugfix release that addresses
> https://issues.apache.org/jira/browse/RIVER-447
>
> Regards,
>
> Peter.

River 3.0.1 Release candidate

[Peter]

Don't forget the release artifacts and signatures for the release 
candidate are

available at:
https://dist.apache.org/repos/dist/dev/river/

When we have enough people to review we can vote & release.

This is a bugfix release that addresses 
https://issues.apache.org/jira/browse/RIVER-447


Regards,

Peter.

Appeal for another volunteer to review next release

[Peter]

River people, we need one more person who's willing to review River's 
latest release.


Any volunteers?

Regards,

Peter.

Re: [RESULT] Re: [VOTE] Release Apache River 3.0.1

[Peter]

Hi Bryan,

Yes, river dev is very quiet, I'm sure there are people here willing to 
review a release, they're probably just tied up elsewhere, haven't 
noticed etc, when we can get the required three people to volunteer to 
review the release, I'll put up another vote.  I'm hoping this result 
will get their attention, so they can make their presence known.


I think it's quiet because experimental development is happening 
elsewhere at present, clearly it needs to come back to the project, 
participation is very beneficial and I don't think anyone enjoys 
developing in isolation.   Getting to that point will take time, there's 
over 3 years of development effort, although nearing completion, it 
needs to be submitted incrementally and reviewed over a number of 
releases, so hopefully that will get some interest.


Regards,

Peter.

On 19/06/2017 11:53 PM, Bryan Thompson wrote:

Peter, i have been on vacation but this seems like a shorter than normal
revirw period.  Was it just a week?

Bryan

On Jun 19, 2017 12:04 AM, "Peter"<j...@zeus.net.au>  wrote:


The release failed to pass during the voting period.

Regards,

Peter.


On 11/06/2017 11:11 AM, Peter wrote:


River 3.0.1 is the latest release of Apache River.

The release artifacts and signatures for the release candidate are
available at:
https://dist.apache.org/repos/dist/dev/river/

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and reasons)

Regards,

Peter.

Re: [RESULT] Re: [VOTE] Release Apache River 3.0.1

[Bryan Thompson]

Peter, i have been on vacation but this seems like a shorter than normal
revirw period.  Was it just a week?

Bryan

On Jun 19, 2017 12:04 AM, "Peter" <j...@zeus.net.au> wrote:

> The release failed to pass during the voting period.
>
> Regards,
>
> Peter.
>
>
> On 11/06/2017 11:11 AM, Peter wrote:
>
>> River 3.0.1 is the latest release of Apache River.
>>
>> The release artifacts and signatures for the release candidate are
>> available at:
>> https://dist.apache.org/repos/dist/dev/river/
>>
>> [  ] +1: I vote in favour of this release.
>> [  ] +0: I am not against this release.
>> [  ] -1: I am against this release (please provide discussion and reasons)
>>
>> Regards,
>>
>> Peter.
>>
>>
>

[RESULT] Re: [VOTE] Release Apache River 3.0.1

[Peter]

The release failed to pass during the voting period.

Regards,

Peter.


On 11/06/2017 11:11 AM, Peter wrote:

River 3.0.1 is the latest release of Apache River.

The release artifacts and signatures for the release candidate are 
available at:

https://dist.apache.org/repos/dist/dev/river/

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and 
reasons)


Regards,

Peter.

Re: [VOTE] Release Apache River 3.0.1

[Bryan Thompson]

Exciting!  I will try and dig out a bit and download the candidate release.
Bryan

On Sat, Jun 10, 2017 at 6:11 PM, Peter <j...@zeus.net.au> wrote:

> River 3.0.1 is the latest release of Apache River.
>
> The release artifacts and signatures for the release candidate are
> available at:
> https://dist.apache.org/repos/dist/dev/river/
>
> [  ] +1: I vote in favour of this release.
> [  ] +0: I am not against this release.
> [  ] -1: I am against this release (please provide discussion and reasons)
>
> Regards,
>
> Peter.
>

[VOTE] Release Apache River 3.0.1

[Peter]

River 3.0.1 is the latest release of Apache River.

The release artifacts and signatures for the release candidate are 
available at:

https://dist.apache.org/repos/dist/dev/river/

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and reasons)

Regards,

Peter.

River 3.0.1 release

[Peter Firmstone]

Anyone got some cycles to help out with the River 3.0.1 release?

There are some existing jira issues with patches or easy fixes we can include 
too.

I've also got a Jini compatibility library to assist people who want to migrate 
from pre 3.x versions that depend on common classes in the comsun. namespace.  
I can donate or make it available on github.

This has the potential to be the best release in the projects history IMHO.

Cheers,

Peter.

Sent from my Samsung device.
 

Re: new release question

[Peter]

On 27/12/2016 12:10 AM, Zsolt Kúti wrote:

Hi Peter,

What is the current status of the 3.0 release?


Released 2 months ago, but not officially announced.


What is its relation to your github river-internet project?


The github code is forked off river trunk, just before the Ivy 
dependency build changes and the 3.0 release was branched.


Additions include:

   * Atomic input validation for java serialization
   * IPv6 Multicast Discovery (registered with Iana).
   * TLSv1.2 cyphers with perfect forward secrecy, changes to security
 constraints, old strong cypers from 2004 vintage now considered
 weak, unsafe cyphers have been removed.
   * New registrar methods that allow authentication prior to proxy
 download and delayed unmarshalling, support added to
 ServiceDiscoveryManager without changing public api.
   * Improved support for Java 9.
   * com.sun.jini compatibility layer (deprecated) api based on Rio's
 usage.
   * Currently working on Maven modular build.

Cheers,

Peter.



We ought add info about it to the new site (hopefully soon to be 
published).

You may answer it on the dev list if you prefer to bring this to there.

Happy holidays!
Zsolt

Re: [VOTE] Release Apache River 3.0.0

[Peter]

To answer my own question, a list of items that require attention:
1. Modular build.
2. Improved IPv6 support
3. Update to TLS v1.2 and update constraints.
4. Investigate Maven codebase provisioning, do we need to use the Maven 
ClassWorlds ClassLoaders, what about proxy identity?
5. Fix security.
6. Update website.
7. Development guide for River devs.
8. Redundancy?
9. Update user docs, perhaps update Jan Newmarch's book?

Cheers,

Peter.




Sent from my Samsung device.
 
  Include original message
 Original message 
From: Peter <j...@zeus.net.au>
Sent: 07/10/2016 12:25:01 pm
To: dev@river.apache.org
Subject: Re: [VOTE] Release Apache River 3.0.0

The question is of course where to next? 

As people are aware I've been working on addressing security issues and  
how to make River better and more secure.  I've been working on this  
outside the project because my attempts to discuss it caused heated  
arguments.  I figured that if I could demonstrate a working example that  
people could try out, it could allevieate any misunderstandings that may  
have developed due to language or culture differences. 

River's approach to security (a result of the Jini Davis project) is  
quite complex and contains a flaw borne out of two limitations around  
the time it was developed: 

   1. The assumption that the Java sandbox and java serialization was 
  secure (we know today this isn't the case). 
   2. Interfaces cannot be changed (no longer true with java 8), in this 
  case ServiceRegistrar was designed prior to the later added on 
  security features. 

What's wrong with River's approach? 

Answer:  It validates and authenticates after downloading code and  
deserializing untrusted data, using the proxy trust framework, by asking  
an already downloaded and deserialized service proxy for a bootstrap  
proxy, the client code then uses the boostrap proxy to determine if the  
service proxy can be trusted.  Too little too late.  Why not instead  
recieve a bootstrap proxy, deserialized using input validation, without  
code download, authenticate the remote endpoint, then ask the bootstrap  
proxy for the service proxy? 

The trouble with the existing approach today is an attacker has  
opportunity to take control of a computer using deserialization alone.   
For those who think a network firewall is sufficient protection and the  
flawed security design isn't an issue on local networks, even in air  
gapped networks, an attacker can leave a USB key in a car park  
containing malware that looks for network transmissions that contain  
java serialized data, hoping that someone will pick it up and plug it  
into their pc, the malware will send serial data containing a gadget  
attack to a listening network port that accepts java serial data and  
take over the infected computer. 

All network communications using standard java serialization must be  
both authenticated and encrypted, prior to reading in any data to ensure  
that the data is trusted. 

I think we can all accept that these vulnerabilities exist and googling  
java serialization gadget attacks should convince even the most doubtful  
sceptic. 

Relevant links: 
https://www.apache.org/dev/committers.html#apache-way 
http://www.apache.org/security/committers.html 

I would like the opportunity to explain more, and go through working  
examples of solutions before we start arguing about whether we should  
solve these problems.  Anyone reading the Apache Way will realise that  
security is a mandatory feature of Apache Software and therefore we  
should consider how we should fix existing security issues in River and  
while doing so, take the opportunity to make security simpler to  
implement.  Arguments should not be about the relevance of security  
issues, but rather the suitablility of solutions. 

Regards, 

Peter. 

On 6/10/2016 2:04 PM, Bryan Thompson wrote: 
> Excellent.  A great step. 
> Bryan 
> 
> On Wednesday, October 5, 2016, Peter Firmstone<peter.firmst...@zeus.net.au> 
> wrote: 
> 
>> Results: 
>> 
>> 3 binding votes 
>> 1 non binding 
>> 
>> None against. 
>> 
>> The artifacts have been published, we need to wait 24 hours before 
>> announcing. 
>> 
>> Regards, 
>> 
>> Peter. 
>> 
>> Sent from my Samsung device. 
>> 
>> 

Re: [VOTE] Release Apache River 3.0.0

[Peter]

The question is of course where to next?

As people are aware I've been working on addressing security issues and 
how to make River better and more secure.  I've been working on this 
outside the project because my attempts to discuss it caused heated 
arguments.  I figured that if I could demonstrate a working example that 
people could try out, it could allevieate any misunderstandings that may 
have developed due to language or culture differences.


River's approach to security (a result of the Jini Davis project) is 
quite complex and contains a flaw borne out of two limitations around 
the time it was developed:


  1. The assumption that the Java sandbox and java serialization was
 secure (we know today this isn't the case).
  2. Interfaces cannot be changed (no longer true with java 8), in this
 case ServiceRegistrar was designed prior to the later added on
 security features.

What's wrong with River's approach?

Answer:  It validates and authenticates after downloading code and 
deserializing untrusted data, using the proxy trust framework, by asking 
an already downloaded and deserialized service proxy for a bootstrap 
proxy, the client code then uses the boostrap proxy to determine if the 
service proxy can be trusted.  Too little too late.  Why not instead 
recieve a bootstrap proxy, deserialized using input validation, without 
code download, authenticate the remote endpoint, then ask the bootstrap 
proxy for the service proxy?


The trouble with the existing approach today is an attacker has 
opportunity to take control of a computer using deserialization alone.  
For those who think a network firewall is sufficient protection and the 
flawed security design isn't an issue on local networks, even in air 
gapped networks, an attacker can leave a USB key in a car park 
containing malware that looks for network transmissions that contain 
java serialized data, hoping that someone will pick it up and plug it 
into their pc, the malware will send serial data containing a gadget 
attack to a listening network port that accepts java serial data and 
take over the infected computer.


All network communications using standard java serialization must be 
both authenticated and encrypted, prior to reading in any data to ensure 
that the data is trusted.


I think we can all accept that these vulnerabilities exist and googling 
java serialization gadget attacks should convince even the most doubtful 
sceptic.


Relevant links:
https://www.apache.org/dev/committers.html#apache-way
http://www.apache.org/security/committers.html

I would like the opportunity to explain more, and go through working 
examples of solutions before we start arguing about whether we should 
solve these problems.  Anyone reading the Apache Way will realise that 
security is a mandatory feature of Apache Software and therefore we 
should consider how we should fix existing security issues in River and 
while doing so, take the opportunity to make security simpler to 
implement.  Arguments should not be about the relevance of security 
issues, but rather the suitablility of solutions.


Regards,

Peter.

On 6/10/2016 2:04 PM, Bryan Thompson wrote:

Excellent.  A great step.
Bryan

On Wednesday, October 5, 2016, Peter Firmstone
wrote:


Results:

3 binding votes
1 non binding

None against.

The artifacts have been published, we need to wait 24 hours before
announcing.

Regards,

Peter.

Sent from my Samsung device.

Re: [VOTE] Release Apache River 3.0.0

[Bryan Thompson]

Excellent.  A great step.
Bryan

On Wednesday, October 5, 2016, Peter Firmstone 
wrote:

> Results:
>
> 3 binding votes
> 1 non binding
>
> None against.
>
> The artifacts have been published, we need to wait 24 hours before
> announcing.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>
>

Re: [VOTE] Release Apache River 3.0.0

[Peter]

Thanks Patricia.

+1 Peter.

That's 3 binding pmc votes!

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 21/09/2016 10:34:46 am
To: dev@river.apache.org
Subject: Re: [VOTE] Release Apache River 3.0.0

+1 Binding. 

On 9/2/2016 6:18 PM, Peter wrote: 
> River 3.0.0 is the latest release of Apache River. 
> 
> The release artifacts and signatures for the release candidate are 
> available at: 
> https://dist.apache.org/repos/dist/dev/river/ 
> 
> [  ] +1: I vote in favour of this release. 
> [  ] +0: I am not against this release. 
> [  ] -1: I am against this release (please provide discussion and reasons) 
> 
> The vote will remain open for 28 days, expiring on the 1st of October 2016. 
> 
> Regards, 
> 
> Peter. 
> 

Re: [VOTE] Release Apache River 3.0.0

[Patricia Shanahan]

+1 Binding.

On 9/2/2016 6:18 PM, Peter wrote:

River 3.0.0 is the latest release of Apache River.

The release artifacts and signatures for the release candidate are
available at:
https://dist.apache.org/repos/dist/dev/river/

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and reasons)

The vote will remain open for 28 days, expiring on the 1st of October 2016.

Regards,

Peter.

Re: [VOTE] Release Apache River 3.0.0

[Bryan Thompson]

+1: I vote in favor of this release.

(binding)

Great job!
Bryan


On Fri, Sep 2, 2016 at 6:18 PM, Peter <j...@zeus.net.au> wrote:

> River 3.0.0 is the latest release of Apache River.
>
> The release artifacts and signatures for the release candidate are
> available at:
> https://dist.apache.org/repos/dist/dev/river/
>
> [  ] +1: I vote in favour of this release.
> [  ] +0: I am not against this release.
> [  ] -1: I am against this release (please provide discussion and reasons)
>
> The vote will remain open for 28 days, expiring on the 1st of October 2016.
>
> Regards,
>
> Peter.
>
>

Re: release artifacts

[Patricia Shanahan]

Thanks. I'll go ahead with my own build and test.

On 9/4/2016 6:27 AM, Bryan Thompson wrote:

I can do this.

Bryan

On Thu, Sep 1, 2016 at 8:52 AM, Patricia Shanahan <p...@acm.org> wrote:


My reason for asking this is to make sure there are at least three of us.
If Peter and I both build and test the release, it won't be enough to make
it an official Apache release. We will need a third PMC member who is
active enough to do it.

On 9/1/2016 6:31 AM, Patricia Shanahan wrote:


How many PMC members are ready and willing to build and test, so that
they can upvote the release?

Peter: Why jar files in the release? Isn't it supposed to be source code?

On 9/1/2016 4:57 AM, Peter Firmstone wrote:


Getting another set of release artifacts 4 River3 ready and have run
all tests again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to
prevent holding up progress, since I haven't worked out how others can
verify release artifacts as the pgp signatures will be different when
comparing artifacts containing signed jars with those that don't, then
there's the issue of how to integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.

RE: [VOTE] Release Apache River 3.0.0

[Bishnu Gautam]

+1 and great news for River communities.RegardsBishnu


Bishnu Prasad Gautam


> Date: Sat, 3 Sep 2016 11:18:21 +1000
> From: j...@zeus.net.au
> To: dev@river.apache.org
> Subject: [VOTE] Release Apache River 3.0.0
> 
> River 3.0.0 is the latest release of Apache River.
> 
> The release artifacts and signatures for the release candidate are available 
> at:
> https://dist.apache.org/repos/dist/dev/river/
> 
> [  ] +1: I vote in favour of this release.
> [  ] +0: I am not against this release.
> [  ] -1: I am against this release (please provide discussion and reasons)
> 
> The vote will remain open for 28 days, expiring on the 1st of October 2016.
> 
> Regards,
> 
> Peter.
> 
  

[VOTE] Release Apache River 3.0.0

[Peter]

River 3.0.0 is the latest release of Apache River.

The release artifacts and signatures for the release candidate are available at:
https://dist.apache.org/repos/dist/dev/river/

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and reasons)

The vote will remain open for 28 days, expiring on the 1st of October 2016.

Regards,

Peter.

Re: release artifacts

[Peter]

 
Ah, yes, the binary release was disabled with the ivy work, due to external 
dependencies. In any case the additional work would only delay release.

And here I was testing everything to make sure the classdep build bug hadn't 
dropped any classes from jar files.

So this release will only contain source and documentation artifacts.

Still it's a step in the right direction.

Come on pmc members, River needs you.

River is more relevant today than it was in 2007.  IPv6 is making it more 
relevant, by lifting capability restrictions and simplifying network 
configuration.

It is possible to address all of the following in a backward compatible way in 
future releases:
1. IPv6 Multicast Discovery (external reference implementation)
2. Unicast https discovery (ext ref impl)
3. Tool to generate security policy files (ext ref impl) to simplify user 
config.
4. ServiceRegistrar default methods to authenticate services prior to download. 
Offloads smart proxy and Entry downloads from Reggie to services, also delays 
unmarshalling improving client performance (ext ref impl).
5. Input validation of untrusted serial data for java deserialization. (ext ref 
impl).
6 Upgrade to TLSv1.2, support for elliptic curve crypto and perfect forward 
secrecy. (ext ref impl).
7. Deprecation of complex inadequate proxy trust.

The above not only allows new capabilities such as p2p over the IPv6 net, but 
hardens and simplifies security.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Peter <j...@zeus.net.au>
Sent: 02/09/2016 07:14:47 am
To: dev@river.apache.org <dev@river.apache.org>
Subject: Re: release artifacts

The release artifacts contain source code, the binaries are there for user 
convenience.   I could use the new X500 Certificate to sign the jars, this was 
purchased by the Apache Foundation for this purpose.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 01/09/2016 11:31:01 pm
To: dev@river.apache.org
Subject: Re: release artifacts

How many PMC members are ready and willing to build and test, so that  
they can upvote the release? 

Peter: Why jar files in the release? Isn't it supposed to be source code? 

On 9/1/2016 4:57 AM, Peter Firmstone wrote: 
> Getting another set of release artifacts 4 River3 ready and have run all 
>tests again, need to generate pgp signatures on weekend. 
> 
> Decided not to use X500 release cert to sign jar files this release to 
>prevent holding up progress, since I haven't worked out how others can verify 
>release artifacts as the pgp signatures will be different when comparing 
>artifacts containing signed jars with those that don't, then there's the issue 
>of how to integrate it into the build process. 
> 
> Regards, 
> 
> Peter. 
> 
> Sent from my Samsung device. 
> 
> 

Re: release artifacts

[Peter]

The release artifacts contain source code, the binaries are there for user 
convenience.   I could use the new X500 Certificate to sign the jars, this was 
purchased by the Apache Foundation for this purpose.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 01/09/2016 11:31:01 pm
To: dev@river.apache.org
Subject: Re: release artifacts

How many PMC members are ready and willing to build and test, so that  
they can upvote the release? 

Peter: Why jar files in the release? Isn't it supposed to be source code? 

On 9/1/2016 4:57 AM, Peter Firmstone wrote: 
> Getting another set of release artifacts 4 River3 ready and have run all 
>tests again, need to generate pgp signatures on weekend. 
> 
> Decided not to use X500 release cert to sign jar files this release to 
>prevent holding up progress, since I haven't worked out how others can verify 
>release artifacts as the pgp signatures will be different when comparing 
>artifacts containing signed jars with those that don't, then there's the issue 
>of how to integrate it into the build process. 
> 
> Regards, 
> 
> Peter. 
> 
> Sent from my Samsung device. 
> 
> 

Re: release artifacts

[Patricia Shanahan]

My reason for asking this is to make sure there are at least three of 
us. If Peter and I both build and test the release, it won't be enough 
to make it an official Apache release. We will need a third PMC member 
who is active enough to do it.


On 9/1/2016 6:31 AM, Patricia Shanahan wrote:

How many PMC members are ready and willing to build and test, so that
they can upvote the release?

Peter: Why jar files in the release? Isn't it supposed to be source code?

On 9/1/2016 4:57 AM, Peter Firmstone wrote:

Getting another set of release artifacts 4 River3 ready and have run
all tests again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to
prevent holding up progress, since I haven't worked out how others can
verify release artifacts as the pgp signatures will be different when
comparing artifacts containing signed jars with those that don't, then
there's the issue of how to integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.

Re: release artifacts

[Patricia Shanahan]

How many PMC members are ready and willing to build and test, so that 
they can upvote the release?


Peter: Why jar files in the release? Isn't it supposed to be source code?

On 9/1/2016 4:57 AM, Peter Firmstone wrote:

Getting another set of release artifacts 4 River3 ready and have run all tests 
again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to prevent 
holding up progress, since I haven't worked out how others can verify release 
artifacts as the pgp signatures will be different when comparing artifacts 
containing signed jars with those that don't, then there's the issue of how to 
integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.

release artifacts

[Peter Firmstone]

Getting another set of release artifacts 4 River3 ready and have run all tests 
again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to prevent 
holding up progress, since I haven't worked out how others can verify release 
artifacts as the pgp signatures will be different when comparing artifacts 
containing signed jars with those that don't, then there's the issue of how to 
integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.
 

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Peter]

Ok, build issue fix committed, someone wants to spin another release.

I had hoped to have a pre release period to deal with any new bugs, 
unfortunately that wasn't a good fit with Apache policy, if we can make 
a beta release, then I'm happy with that.


imunit, allows you to control when the interrupt occurs.  But I get your 
point, remaining users probably aren't greatly affected by the bugs.


Regards,

Peter.

/* Copyright (c) 2010-2012 Zeus Project Services Pty Ltd.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.river.concurrent;

import edu.illinois.imunit.Schedules;
import edu.illinois.imunit.Schedule;
import org.junit.Test;
import java.util.concurrent.ConcurrentHashMap;
import org.junit.Before;
import java.util.concurrent.ConcurrentMap;
import edu.illinois.imunit.IMUnitRunner;
import org.junit.runner.RunWith;
import static edu.illinois.imunit.IMUnit.fireEvent;
import static edu.illinois.imunit.IMUnit.schAssertEquals;
import static edu.illinois.imunit.IMUnit.schAssertNull;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;

/**
 *
 * @author Peter Firmstone.
 */
@RunWith(IMUnitRunner.class)
public class ReferenceConcurrentMapConcurrencyTest {
private ConcurrentMap<Integer,String> map;
private ConcurrentMap<Referrer,Referrer> internal;
private String t1, t2, t3, t4;
@Before
public void setup() {
internal = new ConcurrentHashMap<Referrer, 
Referrer>();

map = RC.concurrentMap( internal, Ref.STRONG, Ref.STRONG, 0L, 0L);
t1 = null;
t2 = null;
t3 = null;
t4 = null;
}

@Test

@Schedule("startingPutIfAbsent1->finishPutIfAbsent1,finishPutIfAbsent1->startingPutIfAbsent2,finishPutIfAbsent1->startingPutIfAbsent3")

public void testPut() throws InterruptedException {
System.out.println("test putIfAbsent");
performParallelPutIfAbsent();
assertEquals("Forty-two", map.get(42));
}

@Test

@Schedule("startingPut1->finishPut1,finishPut1->startingClear1,startingClear1->finishClear1,finishClear1->startingPut2,finishClear1->startingPut3,finishClear1->startingPut4")

public void testPutClearPut() throws InterruptedException {
String exp = "Forty-seven";
System.out.println("test put Clear put");
putClearMultiPut();
assertEquals(exp, map.get(new Integer(42)));
assertNull(t1);
boolean success = t2 == null? t3.equals(exp) && t4.equals(exp) :
t3 == null ? t2.equals(exp) && t4.equals(exp):
t4 == null ? t2.equals(t3) && t3.equals(exp): false;
assertTrue(success);
}

private void performParallelPutIfAbsent() throws InterruptedException {
Thread putIfAbsentThread1 = new Thread(new Runnable() {
@Override
public void run() {
fireEvent("startingPutIfAbsent1");
map.putIfAbsent(42, "Forty-two");
fireEvent("finishPutIfAbsent1");
}
});
Thread putIfAbsentThread2 = new Thread(new Runnable() {
@Override
public void run() {
fireEvent("startingPutIfAbsent2");
map.putIfAbsent(42, "Forty-seven");
fireEvent("finishPutIfAbsent2");
}
});
Thread putIfAbsentThread3 = new Thread(new Runnable() {
@Override
public void run() {
fireEvent("startingPutIfAbsent3");
map.putIfAbsent(42, "Fifty-one");
fireEvent("finishPutIfAbsent3");
}
});
putIfAbsentThread1.start();
putIfAbsentThread2.start();
putIfAbsentThread3.start();
putIfAbsentThread1.join();
putIfAbsentThread2.join();
putIfAbsentThread3.join();
}

private void putClearMultiPut() throws InterruptedException {
Thread thread1 = new Thread(new Runnable() {
@Override
public void run() {
fireEvent("startingPut1");
t1 = map.putIfAbsent(new Integer(42), "Forty-two");
  

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Peter]

Ok, I hadn't realised it was that critical.

In that case, since I hadn't yet posted a binding vote.

+0 Binding.

Regards,

Peter.

On 5/03/2016 9:15 PM, Patricia Shanahan wrote:

The build bug is absolutely critical for the Apache release policy:

"Before voting +1 PMC members are required to download the signed 
source code package, compile it as provided, and test the resulting 
executable on their own platform, along with also verifying that the 
package meets the requirements of the ASF policy on releases."


http://www.apache.org/dev/release.html#approving-a-release


On 3/4/2016 11:00 PM, Peter wrote:

If you want to call it Beta, go for it, lets just get it released, even
with the build bug, it's not critical.

It won't take long for people to realise this Beta has a few hundred
less bugs than our previous releases, even if some newly introduced bugs
appear, it'll be easy to fix them quickly.

This is actually a bugfix release, it's just so many bugs got fixed that
people are frightened of breakages.

The comments on RIVER-431
<https://issues.apache.org/jira/browse/RIVER-431> are really worth
looking at too, there are 241 more bugs reported by Findbugs in River
2.2.1 than River 3.0.0.  Our old code is riddled with race conditions,
see for yourself in the comments, the line numbers refer to bugs present
in River 2.2.1 code.  I know which codebase I feel safer using.

http://dl.acm.org/citation.cfm?doid=2414729.2414732


Sub-task

* [RIVER-319 <https://issues.apache.org/jira/browse/RIVER-319>] -
  Change River Build Dist structure to support jtreg test automation
* [RIVER-344 <https://issues.apache.org/jira/browse/RIVER-344>] -
  com.sun.jini.thread.TaskManager scalability and concurrency.


Bug

* [RIVER-19 <https://issues.apache.org/jira/browse/RIVER-19>] -
  PreferredClassLoader doesn't implement preferred semantics for
  getResources(String)
* [RIVER-113 <https://issues.apache.org/jira/browse/RIVER-113>] -
  JoinManager synchronization on each proxyReg should be reviewed,
  doc'd and fixed where appropriate
* [RIVER-145 <https://issues.apache.org/jira/browse/RIVER-145>] -
  JoinManager synchronization on serviceItem should be reviewed,
  doc'd and fixed where appropriate
* [RIVER-148 <https://issues.apache.org/jira/browse/RIVER-148>] -
  JoinManager.ProxyReg.fail synchronization may be wrong or may be
  able to simplify it
* [RIVER-265 <https://issues.apache.org/jira/browse/RIVER-265>] -
  PreferredClassProvider performs 'unlucky' caching
* [RIVER-282 <https://issues.apache.org/jira/browse/RIVER-282>] -
  Suspect exception cast
* [RIVER-335 <https://issues.apache.org/jira/browse/RIVER-335>] -
  com.sun.jini.phoenix.ConstrainableAID missing from phoenix.jar
* [RIVER-337 <https://issues.apache.org/jira/browse/RIVER-337>] -
  Attempted discard of unknown registrar kills
  LookupLocatorDiscovery thread
* [RIVER-345 <https://issues.apache.org/jira/browse/RIVER-345>] -
  SDM LookupCache multi-LUS stale proxy/discard problems
* [RIVER-348 <https://issues.apache.org/jira/browse/RIVER-348>] -
  Possible race condition in net.jini.lookup.ServiceDiscoveryManager
  addProxyReg
* [RIVER-367 <https://issues.apache.org/jira/browse/RIVER-367>] -
  com.sun.jini.mahalo.TxnManagerImpl fails to abort a Transaction
  when notified of its lease expiration.
* [RIVER-387 <https://issues.apache.org/jira/browse/RIVER-387>] -
  KerberosServerEndpoint calls com.sun.security methods,
  animal-sniffer warns
* [RIVER-395 <https://issues.apache.org/jira/browse/RIVER-395>] -
  Ill-behaved DiscoveryListener can terminate discovery notifier
threads
* [RIVER-402 <https://issues.apache.org/jira/browse/RIVER-402>] -
  NullPointerException in LookupCacheImpl.notifyServiceMap
* [RIVER-418 <https://issues.apache.org/jira/browse/RIVER-418>] -
  Service server implementations start threads before construction
  is complete allow "this" to escape
* [RIVER-420 <https://issues.apache.org/jira/browse/RIVER-420>] -
  Export during construction.
* [RIVER-422 <https://issues.apache.org/jira/browse/RIVER-422>] -
  Missing reference-collections and high-scale-lib in Manifest for
  jsk-platform
* [RIVER-431 <https://issues.apache.org/jira/browse/RIVER-431>] -
  Java Memory Model Compliance
* [RIVER-433 <https://issues.apache.org/jira/browse/RIVER-433>] -
  Test suite freeze while testing service discovery category


Improvement

* [RIVER-26 <https://issues.apache.org/jira/browse/RIVER-26>] - Make
  UmbrellaGrantPermission work with DynamicPolicy
* [RIVER-107 <https://issues.apache.org/jira/browse/RIVER-107>] -
  DynamicPolicyProvider could use finer

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Peter]

If you want to call it Beta, go for it, lets just get it released, even 
with the build bug, it's not critical.


It won't take long for people to realise this Beta has a few hundred 
less bugs than our previous releases, even if some newly introduced bugs 
appear, it'll be easy to fix them quickly.


This is actually a bugfix release, it's just so many bugs got fixed that 
people are frightened of breakages.


The comments on RIVER-431 
<https://issues.apache.org/jira/browse/RIVER-431> are really worth 
looking at too, there are 241 more bugs reported by Findbugs in River 
2.2.1 than River 3.0.0.  Our old code is riddled with race conditions, 
see for yourself in the comments, the line numbers refer to bugs present 
in River 2.2.1 code.  I know which codebase I feel safer using.


http://dl.acm.org/citation.cfm?doid=2414729.2414732


   Sub-task

   * [RIVER-319 <https://issues.apache.org/jira/browse/RIVER-319>] -
 Change River Build Dist structure to support jtreg test automation
   * [RIVER-344 <https://issues.apache.org/jira/browse/RIVER-344>] -
 com.sun.jini.thread.TaskManager scalability and concurrency.


   Bug

   * [RIVER-19 <https://issues.apache.org/jira/browse/RIVER-19>] -
 PreferredClassLoader doesn't implement preferred semantics for
 getResources(String)
   * [RIVER-113 <https://issues.apache.org/jira/browse/RIVER-113>] -
 JoinManager synchronization on each proxyReg should be reviewed,
 doc'd and fixed where appropriate
   * [RIVER-145 <https://issues.apache.org/jira/browse/RIVER-145>] -
 JoinManager synchronization on serviceItem should be reviewed,
 doc'd and fixed where appropriate
   * [RIVER-148 <https://issues.apache.org/jira/browse/RIVER-148>] -
 JoinManager.ProxyReg.fail synchronization may be wrong or may be
 able to simplify it
   * [RIVER-265 <https://issues.apache.org/jira/browse/RIVER-265>] -
 PreferredClassProvider performs 'unlucky' caching
   * [RIVER-282 <https://issues.apache.org/jira/browse/RIVER-282>] -
 Suspect exception cast
   * [RIVER-335 <https://issues.apache.org/jira/browse/RIVER-335>] -
 com.sun.jini.phoenix.ConstrainableAID missing from phoenix.jar
   * [RIVER-337 <https://issues.apache.org/jira/browse/RIVER-337>] -
 Attempted discard of unknown registrar kills
 LookupLocatorDiscovery thread
   * [RIVER-345 <https://issues.apache.org/jira/browse/RIVER-345>] -
 SDM LookupCache multi-LUS stale proxy/discard problems
   * [RIVER-348 <https://issues.apache.org/jira/browse/RIVER-348>] -
 Possible race condition in net.jini.lookup.ServiceDiscoveryManager
 addProxyReg
   * [RIVER-367 <https://issues.apache.org/jira/browse/RIVER-367>] -
 com.sun.jini.mahalo.TxnManagerImpl fails to abort a Transaction
 when notified of its lease expiration.
   * [RIVER-387 <https://issues.apache.org/jira/browse/RIVER-387>] -
 KerberosServerEndpoint calls com.sun.security methods,
 animal-sniffer warns
   * [RIVER-395 <https://issues.apache.org/jira/browse/RIVER-395>] -
 Ill-behaved DiscoveryListener can terminate discovery notifier threads
   * [RIVER-402 <https://issues.apache.org/jira/browse/RIVER-402>] -
 NullPointerException in LookupCacheImpl.notifyServiceMap
   * [RIVER-418 <https://issues.apache.org/jira/browse/RIVER-418>] -
 Service server implementations start threads before construction
 is complete allow "this" to escape
   * [RIVER-420 <https://issues.apache.org/jira/browse/RIVER-420>] -
 Export during construction.
   * [RIVER-422 <https://issues.apache.org/jira/browse/RIVER-422>] -
 Missing reference-collections and high-scale-lib in Manifest for
 jsk-platform
   * [RIVER-431 <https://issues.apache.org/jira/browse/RIVER-431>] -
 Java Memory Model Compliance
   * [RIVER-433 <https://issues.apache.org/jira/browse/RIVER-433>] -
 Test suite freeze while testing service discovery category


   Improvement

   * [RIVER-26 <https://issues.apache.org/jira/browse/RIVER-26>] - Make
 UmbrellaGrantPermission work with DynamicPolicy
   * [RIVER-107 <https://issues.apache.org/jira/browse/RIVER-107>] -
 DynamicPolicyProvider could use finer grained locking
   * [RIVER-123 <https://issues.apache.org/jira/browse/RIVER-123>] -
 ConfigurationFile should support arithmetic operations
   * [RIVER-140 <https://issues.apache.org/jira/browse/RIVER-140>] -
 JoinManager synchronization strategy should be reviewed,
 documented, and fixed where appropriate
   * [RIVER-193 <https://issues.apache.org/jira/browse/RIVER-193>] -
 support declaring entries in a "common" configuration source for
 use in other configuration sources
   * [RIVER-249 <https://issues.apache.org/jira/browse/RIVER-249>] -
 DynamicPolicy providers do not support UmbrellaGrantPermission
   * [

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Peter]

This bug also exists in previous releases, it was exposed with the inclusion of 
the Groovy  provider.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 05/03/2016 01:57:14 am
To: dev@river.apache.org
Subject: Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

Changing my vote to +0 for the moment. 

OK, so what we have here is a build bug. 

If you do an ‘ant clean’ then ‘ant river-runtime’, all is good. 
Do ‘ant river-runtime’ again, you get the failure that Patricia is seeing. 

If you ‘cd qa’ then do ‘ant run-categories’ the qa suite runs without error.  
That target doesn’t attempt to rebuild the main distribution.  The ‘run’ target 
inside ‘qa’ _does_ rebuild the main distribution (I’m not sure why that was put 
in there, but that’s the way it’s been forever).  Hence it shows the error 
mentioned above. 

When I was doing my testing, I ran ‘ant run-categories’ to run the test suite, 
so I didn’t see this build bug. 

On the one hand, I’m inclined to cancel the vote, figure out the bug, and spin 
a new release.  That could potentially take a while, because the bug smells of 
a nasty circularity in the build (or it could be trivial).   

On the other hand, we did say that this was a “technology preview” release that 
is supposed to get 3.0.0 into the hands of potential users, knowing full well 
that there are a lot of changes from the 2.2 branch, and people might find 
operational bugs.  People have run the qa suite, and it the whole package 
probably works just fine.  And the licensing is fine.  So we could probably 
just go ahead and release it. 

I’m not sure what to do.  Any opinions? 

Cheers, 

Greg Trasuk. 
> On Mar 3, 2016, at 4:57 PM, Patricia Shanahan <p...@acm.org> wrote: 
>  
> The file wk1 in the attached zip is the result of: 
>  
> pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant clean 2>&1 >wk1 
> pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant -v 2>&1 >>wk1 
>  
>  
>  
>  
> On 03/03/2016 09:01 AM, Greg Trasuk wrote: 
>> That’s quite odd.  Can you do an ‘ant clean’, then ‘ant -v’ and post the 
>>complete scrollback, from the ‘ant clean’ command, to the final ‘build 
>>failed’? 
>>  
>> There is a chance, I suppose, that Ubuntu uses a different version of Java 
>>(i.e. OpenJDK rather than Oracle JDK) or has something else pre-installed 
>>that is interfering with the build.  I haven’t tried building on Ubuntu 
>>myself, but I’m pretty sure I’ve used OpenJDK at some point, and it was fine. 
>>  
>> Cheers, 
>>  
>> Greg Trasuk 
>>  
>>> On Mar 3, 2016, at 11:35 AM, Patricia Shanahan <p...@acm.org> wrote: 
>>>  
>>> Tried that. I even went back and re-extracted the .zip file, in case prior 
>>>attempts had left tire marks. After the extract I did 
>>>  
>>> ant 
>>> ant qa.run 
>>>  
>>> and got the same errors. This is on Ubuntu. 
>>>  
>>> Unfortunately, I cannot cast a binding vote for a release I cannot run. 
>>>  
>>> On 3/3/2016 6:20 AM, Greg Trasuk wrote: 
>>>> Try running just ‘ant’ before you do ‘ant qa.run’.  That should run the 
>>>>default build target. 
>>>>  
>>>> It appears that ‘qa.run’ is skipping the step where it downloads the 
>>>>external dependencies.  ‘ant’ on its own should do the build, then ‘ant 
>>>>qa.run’ should work. 
>>>>  
>>>> Cheers, 
>>>>  
>>>> Greg Trasuk 
>>>>  
>>>>> On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org> wrote: 
>>>>>  
>>>>> I seem to be missing some set-up that needs doing before "ant qa.run". 
>>>>>  
>>>>> ng: Class not found: groovy.lang.MetaMethod 
>>>>> [java] Warning: Class not found: 
>>>>>org.codehaus.groovy.reflection.ClassInfo 
>>>>> [java] Warning: Class not found: 
>>>>>org.codehaus.groovy.runtime.wrappers.Wrapper 
>>>>> [java] Warning: Class not found: groovy.langReference 
>>>>> [java] Warning: Class not found: 
>>>>>org.codehaus.groovy.runtime.callsite.CallSiteArray 
>>>>> [java] Warning: Class not found: groovy.lang.GroovyCodeSource 
>>>>> [java] Warning: Class not found: 
>>>>>org.codehaus.groovy.runtime.callsite.CallSite 
>>>>> [java] Warning: Class not found: 
>>>>>org.codehaus.groovy.runtime.GeneratedClosure 
>>>>> [java] Warning: Class not found: 
>>>>>org.codehaus.groovy.runtim

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

My feeling is that there should be some way to document that it is not a 
real release, keep it as a development download for testing only, but 
make more users aware of it on those terms.


Can we e.g. put "beta" in its name?

What do other people think?

On 3/4/2016 7:57 AM, Greg Trasuk wrote:

Changing my vote to +0 for the moment.

OK, so what we have here is a build bug.

If you do an ‘ant clean’ then ‘ant river-runtime’, all is good.
Do ‘ant river-runtime’ again, you get the failure that Patricia is seeing.

If you ‘cd qa’ then do ‘ant run-categories’ the qa suite runs without error.  
That target doesn’t attempt to rebuild the main distribution.  The ‘run’ target 
inside ‘qa’ _does_ rebuild the main distribution (I’m not sure why that was put 
in there, but that’s the way it’s been forever).  Hence it shows the error 
mentioned above.

When I was doing my testing, I ran ‘ant run-categories’ to run the test suite, 
so I didn’t see this build bug.

On the one hand, I’m inclined to cancel the vote, figure out the bug, and spin 
a new release.  That could potentially take a while, because the bug smells of 
a nasty circularity in the build (or it could be trivial).

On the other hand, we did say that this was a “technology preview” release that 
is supposed to get 3.0.0 into the hands of potential users, knowing full well 
that there are a lot of changes from the 2.2 branch, and people might find 
operational bugs.  People have run the qa suite, and it the whole package 
probably works just fine.  And the licensing is fine.  So we could probably 
just go ahead and release it.

I’m not sure what to do.  Any opinions?

Cheers,

Greg Trasuk.

On Mar 3, 2016, at 4:57 PM, Patricia Shanahan <p...@acm.org> wrote:

The file wk1 in the attached zip is the result of:

pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant clean 2>&1 >wk1
pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant -v 2>&1 >>wk1




On 03/03/2016 09:01 AM, Greg Trasuk wrote:

That’s quite odd.  Can you do an ‘ant clean’, then ‘ant -v’ and post the 
complete scrollback, from the ‘ant clean’ command, to the final ‘build failed’?

There is a chance, I suppose, that Ubuntu uses a different version of Java 
(i.e. OpenJDK rather than Oracle JDK) or has something else pre-installed that 
is interfering with the build.  I haven’t tried building on Ubuntu myself, but 
I’m pretty sure I’ve used OpenJDK at some point, and it was fine.

Cheers,

Greg Trasuk


On Mar 3, 2016, at 11:35 AM, Patricia Shanahan <p...@acm.org> wrote:

Tried that. I even went back and re-extracted the .zip file, in case prior 
attempts had left tire marks. After the extract I did

ant
ant qa.run

and got the same errors. This is on Ubuntu.

Unfortunately, I cannot cast a binding vote for a release I cannot run.

On 3/3/2016 6:20 AM, Greg Trasuk wrote:

Try running just ‘ant’ before you do ‘ant qa.run’.  That should run the default 
build target.

It appears that ‘qa.run’ is skipping the step where it downloads the external 
dependencies.  ‘ant’ on its own should do the build, then ‘ant qa.run’ should 
work.

Cheers,

Greg Trasuk


On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org> wrote:

I seem to be missing some set-up that needs doing before "ant qa.run".

ng: Class not found: groovy.lang.MetaMethod
 [java] Warning: Class not found: org.codehaus.groovy.reflection.ClassInfo
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.wrappers.Wrapper
 [java] Warning: Class not found: groovy.lang.Reference
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSiteArray
 [java] Warning: Class not found: groovy.lang.GroovyCodeSource
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSite
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.GeneratedClosure
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter
 [java] Warning: Class not found: groovy.lang.Closure
 [java] Warning: Class not found: groovy.lang.MetaClass
 [java] Warning: Class not found: 
org.cliffc.high_scale_lib.NonBlockingHashMap
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.BytecodeInterface8
 [java] Warning: Class not found: org.codehaus.groovy.runtime.ArrayUtil
 [java] Warning: Class not found: groovy.lang.GroovyObject
 [java] Warning: Class not found: groovy.lang.GroovyClassLoader
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation
 [java] Warning: Class not found: 
org.codehaus.groovy.control.CompilerConfiguration
 [java] Warning: Class not found: org.codehaus.groovy.runtime.GStringImpl
 [java] Warning: Class not found: groovy.lang.MissingPropertyException
  [jar] Building jar: /River_3.0/src/apac

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Greg Trasuk]

Changing my vote to +0 for the moment.

OK, so what we have here is a build bug.

If you do an ‘ant clean’ then ‘ant river-runtime’, all is good.
Do ‘ant river-runtime’ again, you get the failure that Patricia is seeing.

If you ‘cd qa’ then do ‘ant run-categories’ the qa suite runs without error.  
That target doesn’t attempt to rebuild the main distribution.  The ‘run’ target 
inside ‘qa’ _does_ rebuild the main distribution (I’m not sure why that was put 
in there, but that’s the way it’s been forever).  Hence it shows the error 
mentioned above.

When I was doing my testing, I ran ‘ant run-categories’ to run the test suite, 
so I didn’t see this build bug.

On the one hand, I’m inclined to cancel the vote, figure out the bug, and spin 
a new release.  That could potentially take a while, because the bug smells of 
a nasty circularity in the build (or it could be trivial).  

On the other hand, we did say that this was a “technology preview” release that 
is supposed to get 3.0.0 into the hands of potential users, knowing full well 
that there are a lot of changes from the 2.2 branch, and people might find 
operational bugs.  People have run the qa suite, and it the whole package 
probably works just fine.  And the licensing is fine.  So we could probably 
just go ahead and release it.

I’m not sure what to do.  Any opinions?

Cheers,

Greg Trasuk.
> On Mar 3, 2016, at 4:57 PM, Patricia Shanahan <p...@acm.org> wrote:
> 
> The file wk1 in the attached zip is the result of:
> 
> pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant clean 2>&1 >wk1
> pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant -v 2>&1 >>wk1
> 
> 
> 
> 
> On 03/03/2016 09:01 AM, Greg Trasuk wrote:
>> That’s quite odd.  Can you do an ‘ant clean’, then ‘ant -v’ and post the 
>> complete scrollback, from the ‘ant clean’ command, to the final ‘build 
>> failed’?
>> 
>> There is a chance, I suppose, that Ubuntu uses a different version of Java 
>> (i.e. OpenJDK rather than Oracle JDK) or has something else pre-installed 
>> that is interfering with the build.  I haven’t tried building on Ubuntu 
>> myself, but I’m pretty sure I’ve used OpenJDK at some point, and it was fine.
>> 
>> Cheers,
>> 
>> Greg Trasuk
>> 
>>> On Mar 3, 2016, at 11:35 AM, Patricia Shanahan <p...@acm.org> wrote:
>>> 
>>> Tried that. I even went back and re-extracted the .zip file, in case prior 
>>> attempts had left tire marks. After the extract I did
>>> 
>>> ant
>>> ant qa.run
>>> 
>>> and got the same errors. This is on Ubuntu.
>>> 
>>> Unfortunately, I cannot cast a binding vote for a release I cannot run.
>>> 
>>> On 3/3/2016 6:20 AM, Greg Trasuk wrote:
>>>> Try running just ‘ant’ before you do ‘ant qa.run’.  That should run the 
>>>> default build target.
>>>> 
>>>> It appears that ‘qa.run’ is skipping the step where it downloads the 
>>>> external dependencies.  ‘ant’ on its own should do the build, then ‘ant 
>>>> qa.run’ should work.
>>>> 
>>>> Cheers,
>>>> 
>>>> Greg Trasuk
>>>> 
>>>>> On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org> wrote:
>>>>> 
>>>>> I seem to be missing some set-up that needs doing before "ant qa.run".
>>>>> 
>>>>> ng: Class not found: groovy.lang.MetaMethod
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.reflection.ClassInfo
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.runtime.wrappers.Wrapper
>>>>> [java] Warning: Class not found: groovy.lang.Reference
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.runtime.callsite.CallSiteArray
>>>>> [java] Warning: Class not found: groovy.lang.GroovyCodeSource
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.runtime.callsite.CallSite
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.runtime.GeneratedClosure
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
>>>>> [java] Warning: Class not found: 
>>>>> org.codehaus.groovy.runtime.ScriptBytecodeAdapter
>>>>> [java] Warning: Class not found: groovy.lang.Closure
>>>>> [java] Warning: Class not found: groovy.lang.MetaClass
>>>>> [java] Warning: Class not found: 
>>>>

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

Will do, probably this afternoon. I have a tax prep appointment for the 
rest of this morning.


Patricia

On 3/3/2016 9:01 AM, Greg Trasuk wrote:

That’s quite odd.  Can you do an ‘ant clean’, then ‘ant -v’ and post
the complete scrollback, from the ‘ant clean’ command, to the final
‘build failed’?

There is a chance, I suppose, that Ubuntu uses a different version of
Java (i.e. OpenJDK rather than Oracle JDK) or has something else
pre-installed that is interfering with the build.  I haven’t tried
building on Ubuntu myself, but I’m pretty sure I’ve used OpenJDK at
some point, and it was fine.

Cheers,

Greg Trasuk


On Mar 3, 2016, at 11:35 AM, Patricia Shanahan <p...@acm.org>
wrote:

Tried that. I even went back and re-extracted the .zip file, in
case prior attempts had left tire marks. After the extract I did

ant ant qa.run

and got the same errors. This is on Ubuntu.

Unfortunately, I cannot cast a binding vote for a release I cannot
run.

On 3/3/2016 6:20 AM, Greg Trasuk wrote:


Try running just ‘ant’ before you do ‘ant qa.run’.  That should
run the default build target.

It appears that ‘qa.run’ is skipping the step where it downloads
the external dependencies.  ‘ant’ on its own should do the build,
then ‘ant qa.run’ should work.

Cheers,

Greg Trasuk


On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org>
wrote:

I seem to be missing some set-up that needs doing before "ant
qa.run".

ng: Class not found: groovy.lang.MetaMethod [java] Warning:
Class not found: org.codehaus.groovy.reflection.ClassInfo
[java] Warning: Class not found:
org.codehaus.groovy.runtime.wrappers.Wrapper [java] Warning:
Class not found: groovy.lang.Reference [java] Warning: Class
not found: org.codehaus.groovy.runtime.callsite.CallSiteArray
[java] Warning: Class not found: groovy.lang.GroovyCodeSource
[java] Warning: Class not found:
org.codehaus.groovy.runtime.callsite.CallSite [java] Warning:
Class not found: org.codehaus.groovy.runtime.GeneratedClosure
[java] Warning: Class not found:
org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
[java] Warning: Class not found:
org.codehaus.groovy.runtime.ScriptBytecodeAdapter [java]
Warning: Class not found: groovy.lang.Closure [java] Warning:
Class not found: groovy.lang.MetaClass [java] Warning: Class
not found: org.cliffc.high_scale_lib.NonBlockingHashMap [java]
Warning: Class not found:
org.codehaus.groovy.runtime.BytecodeInterface8 [java] Warning:
Class not found: org.codehaus.groovy.runtime.ArrayUtil [java]
Warning: Class not found: groovy.lang.GroovyObject [java]
Warning: Class not found: groovy.lang.GroovyClassLoader [java]
Warning: Class not found:
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation


[java] Warning: Class not found: 
org.codehaus.groovy.control.CompilerConfiguration

[java] Warning: Class not found:
org.codehaus.groovy.runtime.GStringImpl [java] Warning: Class
not found: groovy.lang.MissingPropertyException [jar] Building
jar: /River_3.0/src/apache-river-3.0.0/lib/jsk-platform.jar
[java] no text found: "preflistgen.error" [java]
java.lang.NoClassDefFoundError:
org/codehaus/groovy/runtime/GeneratedClosure [java] at
java.lang.ClassLoader.defineClass1(Native Method) [java] at
java.lang.ClassLoader.defineClass(ClassLoader.java:800) [java]
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)



[java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)

[java] at
java.net.URLClassLoader.access$100(URLClassLoader.java:71)
[java] at
java.net.URLClassLoader$1.run(URLClassLoader.java:361) [java]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[java] at
java.security.AccessController.doPrivileged(Native Method)
[java] at
java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[java] at
java.lang.ClassLoader.loadClass(ClassLoader.java:425) [java]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) [java]
at java.lang.Class.forName0(Native Method) [java] at
java.lang.Class.forName(Class.java:278) [java] at
org.apache.river.tool.PreferredListGen.compute(PreferredListGen.java:1162)


[java] at 
org.apache.river.tool.PreferredListGen.main(PreferredListGen.java:1420)

[java] Caused by: java.lang.ClassNotFoundException:
org.codehaus.groovy.runtime.GeneratedClosure [java] at
java.net.URLClassLoader$1.run(URLClassLoader.java:366) [java]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[java] at
java.security.AccessController.doPrivileged(Native Method)
[java] at
java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[java] at
java.lang.ClassLoader.loadClass(ClassLoader.java:425) [java]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) [java]
... 15 more

BUILD FAILED /River_3.0/src/apache-river-3.0.0/build.xml:2205:
The following error occurred while executing this line:
/River_3.0/src/apache-river-3.0.0/qa/build.xml:144: The
following error occurred while executing this line:
/

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Greg Trasuk]

Try running just ‘ant’ before you do ‘ant qa.run’.  That should run the default 
build target.

It appears that ‘qa.run’ is skipping the step where it downloads the external 
dependencies.  ‘ant’ on its own should do the build, then ‘ant qa.run’ should 
work.

Cheers,

Greg Trasuk

> On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org> wrote:
> 
> I seem to be missing some set-up that needs doing before "ant qa.run".
> 
> ng: Class not found: groovy.lang.MetaMethod
> [java] Warning: Class not found: org.codehaus.groovy.reflection.ClassInfo
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.wrappers.Wrapper
> [java] Warning: Class not found: groovy.lang.Reference
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.callsite.CallSiteArray
> [java] Warning: Class not found: groovy.lang.GroovyCodeSource
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.callsite.CallSite
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.GeneratedClosure
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter
> [java] Warning: Class not found: groovy.lang.Closure
> [java] Warning: Class not found: groovy.lang.MetaClass
> [java] Warning: Class not found: 
> org.cliffc.high_scale_lib.NonBlockingHashMap
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.BytecodeInterface8
> [java] Warning: Class not found: org.codehaus.groovy.runtime.ArrayUtil
> [java] Warning: Class not found: groovy.lang.GroovyObject
> [java] Warning: Class not found: groovy.lang.GroovyClassLoader
> [java] Warning: Class not found: 
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation
> [java] Warning: Class not found: 
> org.codehaus.groovy.control.CompilerConfiguration
> [java] Warning: Class not found: org.codehaus.groovy.runtime.GStringImpl
> [java] Warning: Class not found: groovy.lang.MissingPropertyException
>  [jar] Building jar: 
> /River_3.0/src/apache-river-3.0.0/lib/jsk-platform.jar
> [java] no text found: "preflistgen.error"
> [java] java.lang.NoClassDefFoundError: 
> org/codehaus/groovy/runtime/GeneratedClosure
> [java] at java.lang.ClassLoader.defineClass1(Native Method)
> [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> [java] at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> [java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> [java] at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> [java] at java.security.AccessController.doPrivileged(Native Method)
> [java] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> [java] at java.lang.Class.forName0(Native Method)
> [java] at java.lang.Class.forName(Class.java:278)
> [java] at 
> org.apache.river.tool.PreferredListGen.compute(PreferredListGen.java:1162)
> [java] at 
> org.apache.river.tool.PreferredListGen.main(PreferredListGen.java:1420)
> [java] Caused by: java.lang.ClassNotFoundException: 
> org.codehaus.groovy.runtime.GeneratedClosure
> [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> [java] at java.security.AccessController.doPrivileged(Native Method)
> [java] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> [java] ... 15 more
> 
> BUILD FAILED
> /River_3.0/src/apache-river-3.0.0/build.xml:2205: The following error 
> occurred while executing this line:
> /River_3.0/src/apache-river-3.0.0/qa/build.xml:144: The following error 
> occurred while executing this line:
> /River_3.0/src/apache-river-3.0.0/build.xml:973: The following error occurred 
> while executing this line:
> /River_3.0/src/apache-river-3.0.0/common.xml:253: Java returned: 1
> 
> 
> 
> On 03/02/2016 04:20 PM, Peter wrote:
>> ant qa.run
>> ant test
>> 
>> Regards,
>> 
>> Peter.
>> 
>> Sent from my Samsung device.
>> Include original message

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

I seem to be missing some set-up that needs doing before "ant qa.run".

ng: Class not found: groovy.lang.MetaMethod
 [java] Warning: Class not found: 
org.codehaus.groovy.reflection.ClassInfo
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.wrappers.Wrapper

 [java] Warning: Class not found: groovy.lang.Reference
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSiteArray

 [java] Warning: Class not found: groovy.lang.GroovyCodeSource
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSite
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.GeneratedClosure
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter

 [java] Warning: Class not found: groovy.lang.Closure
 [java] Warning: Class not found: groovy.lang.MetaClass
 [java] Warning: Class not found: 
org.cliffc.high_scale_lib.NonBlockingHashMap
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.BytecodeInterface8

 [java] Warning: Class not found: org.codehaus.groovy.runtime.ArrayUtil
 [java] Warning: Class not found: groovy.lang.GroovyObject
 [java] Warning: Class not found: groovy.lang.GroovyClassLoader
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation
 [java] Warning: Class not found: 
org.codehaus.groovy.control.CompilerConfiguration
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.GStringImpl

 [java] Warning: Class not found: groovy.lang.MissingPropertyException
  [jar] Building jar: 
/River_3.0/src/apache-river-3.0.0/lib/jsk-platform.jar

 [java] no text found: "preflistgen.error"
 [java] java.lang.NoClassDefFoundError: 
org/codehaus/groovy/runtime/GeneratedClosure

 [java] at java.lang.ClassLoader.defineClass1(Native Method)
 [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 [java] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 [java] at 
java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
 [java] at 
java.net.URLClassLoader.access$100(URLClassLoader.java:71)

 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 [java] at java.security.AccessController.doPrivileged(Native 
Method)
 [java] at 
java.net.URLClassLoader.findClass(URLClassLoader.java:354)

 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 [java] at java.lang.Class.forName0(Native Method)
 [java] at java.lang.Class.forName(Class.java:278)
 [java] at 
org.apache.river.tool.PreferredListGen.compute(PreferredListGen.java:1162)
 [java] at 
org.apache.river.tool.PreferredListGen.main(PreferredListGen.java:1420)
 [java] Caused by: java.lang.ClassNotFoundException: 
org.codehaus.groovy.runtime.GeneratedClosure

 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 [java] at java.security.AccessController.doPrivileged(Native 
Method)
 [java] at 
java.net.URLClassLoader.findClass(URLClassLoader.java:354)

 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 [java] ... 15 more

BUILD FAILED
/River_3.0/src/apache-river-3.0.0/build.xml:2205: The following error 
occurred while executing this line:
/River_3.0/src/apache-river-3.0.0/qa/build.xml:144: The following error 
occurred while executing this line:
/River_3.0/src/apache-river-3.0.0/build.xml:973: The following error 
occurred while executing this line:

/River_3.0/src/apache-river-3.0.0/common.xml:253: Java returned: 1



On 03/02/2016 04:20 PM, Peter wrote:

ant qa.run
ant test

Regards,

Peter.

Sent from my Samsung device.
  
   Include original message

 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 03/03/2016 09:44:57 am
To: dev@river.apache.org
Subject: Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

I have built from the release artifacts, on a Ubuntu box. What is the
simplest way of running some tests against my build result?

On 3/2/2016 2:25 PM, Patricia Shanahan wrote:

  I have just got done with another project that was my highest priority
  for a couple of weeks. I'll attempt to build and test so that I can cast
  a binding vote.

  On 3/2/2016 12:12 PM, Greg Trasuk wrote:

  Hi folks - we’re still short one binding vote for this release.  So,
  if you can, please have a look at the artifacts and have your say..

  Cheers,

  Greg Trasuk

  On Feb 23, 2016, at 

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Peter]

ant qa.run
ant test

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 03/03/2016 09:44:57 am
To: dev@river.apache.org
Subject: Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

I have built from the release artifacts, on a Ubuntu box. What is the  
simplest way of running some tests against my build result? 

On 3/2/2016 2:25 PM, Patricia Shanahan wrote: 
> I have just got done with another project that was my highest priority 
> for a couple of weeks. I'll attempt to build and test so that I can cast 
> a binding vote. 
> 
> On 3/2/2016 12:12 PM, Greg Trasuk wrote: 
>> Hi folks - we’re still short one binding vote for this release.  So, 
>> if you can, please have a look at the artifacts and have your say.. 
>> 
>> Cheers, 
>> 
>> Greg Trasuk 
>>> On Feb 23, 2016, at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote: 
>>> 
>>> Hello all: 
>>> 
>>> Release candidate artifacts can be found at 
>>> https://dist.apache.org/repos/dist/dev/river/ 
>>> 
>>> Binary release artifacts are staged in 
>>> https://repository.apache.org/content/repositories/orgapacheriver-1003/ 
>>> 
>>> The vote will remain open for at least 72 hours (Ending no sooner 
>>> than 2100UTC 20160226. 
>>> 
>>> [  ] +1 : I am in favour of this release 
>>> [  ] +0 : I am not opposed to this release. 
>>> [  ] -1: I am against this release (please provide your reasons). 
>>> 
>>> Cheers, 
>>> 
>>> Greg Trasuk 
>>> 
>> 

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Greg Trasuk]

‘ant qa.run’ will run the complete integration test suite.  Be warned, though, 
it takes about 22 hours.

Probably more salient, since this is a “technology preview” release, is to run 
‘rat’ against it, and check the licensing.  You could also verify the md5, sha 
and pgp signatures that are on the artifacts.

Cheers,

Greg Trasuk.

> On Mar 2, 2016, at 6:44 PM, Patricia Shanahan <p...@acm.org> wrote:
> 
> I have built from the release artifacts, on a Ubuntu box. What is the 
> simplest way of running some tests against my build result?
> 
> On 3/2/2016 2:25 PM, Patricia Shanahan wrote:
>> I have just got done with another project that was my highest priority
>> for a couple of weeks. I'll attempt to build and test so that I can cast
>> a binding vote.
>> 
>> On 3/2/2016 12:12 PM, Greg Trasuk wrote:
>>> Hi folks - we’re still short one binding vote for this release.  So,
>>> if you can, please have a look at the artifacts and have your say..
>>> 
>>> Cheers,
>>> 
>>> Greg Trasuk
>>>> On Feb 23, 2016, at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
>>>> 
>>>> Hello all:
>>>> 
>>>> Release candidate artifacts can be found at
>>>> https://dist.apache.org/repos/dist/dev/river/
>>>> 
>>>> Binary release artifacts are staged in
>>>> https://repository.apache.org/content/repositories/orgapacheriver-1003/
>>>> 
>>>> The vote will remain open for at least 72 hours (Ending no sooner
>>>> than 2100UTC 20160226.
>>>> 
>>>> [  ] +1 : I am in favour of this release
>>>> [  ] +0 : I am not opposed to this release.
>>>> [  ] -1: I am against this release (please provide your reasons).
>>>> 
>>>> Cheers,
>>>> 
>>>> Greg Trasuk
>>>> 
>>> 

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

I have built from the release artifacts, on a Ubuntu box. What is the 
simplest way of running some tests against my build result?


On 3/2/2016 2:25 PM, Patricia Shanahan wrote:

I have just got done with another project that was my highest priority
for a couple of weeks. I'll attempt to build and test so that I can cast
a binding vote.

On 3/2/2016 12:12 PM, Greg Trasuk wrote:

Hi folks - we’re still short one binding vote for this release.  So,
if you can, please have a look at the artifacts and have your say..

Cheers,

Greg Trasuk

On Feb 23, 2016, at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote:

Hello all:

Release candidate artifacts can be found at
https://dist.apache.org/repos/dist/dev/river/

Binary release artifacts are staged in
https://repository.apache.org/content/repositories/orgapacheriver-1003/

The vote will remain open for at least 72 hours (Ending no sooner
than 2100UTC 20160226.

[  ] +1 : I am in favour of this release
[  ] +0 : I am not opposed to this release.
[  ] -1: I am against this release (please provide your reasons).

Cheers,

Greg Trasuk

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Tom Hobbs]

I'll try and take a look at them over the weekend, I can make no promises
though.

On Wed, Mar 2, 2016 at 8:12 PM, Greg Trasuk <tras...@stratuscom.com> wrote:

> Hi folks - we’re still short one binding vote for this release.  So, if
> you can, please have a look at the artifacts and have your say..
>
> Cheers,
>
> Greg Trasuk
> > On Feb 23, 2016, at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> >
> > Hello all:
> >
> > Release candidate artifacts can be found at
> https://dist.apache.org/repos/dist/dev/river/
> >
> > Binary release artifacts are staged in
> https://repository.apache.org/content/repositories/orgapacheriver-1003/
> >
> > The vote will remain open for at least 72 hours (Ending no sooner than
> 2100UTC 20160226.
> >
> > [  ] +1 : I am in favour of this release
> > [  ] +0 : I am not opposed to this release.
> > [  ] -1: I am against this release (please provide your reasons).
> >
> > Cheers,
> >
> > Greg Trasuk
> >
>
>

Reminder: [Vote] Release Apache River JTSK 3.0.0

[Greg Trasuk]

Hi folks - we’re still short one binding vote for this release.  So, if you 
can, please have a look at the artifacts and have your say..

Cheers,

Greg Trasuk
> On Feb 23, 2016, at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> 
> Hello all:
> 
> Release candidate artifacts can be found at 
> https://dist.apache.org/repos/dist/dev/river/
> 
> Binary release artifacts are staged in 
> https://repository.apache.org/content/repositories/orgapacheriver-1003/
> 
> The vote will remain open for at least 72 hours (Ending no sooner than 
> 2100UTC 20160226.
> 
> [  ] +1 : I am in favour of this release
> [  ] +0 : I am not opposed to this release.
> [  ] -1: I am against this release (please provide your reasons).
> 
> Cheers,
> 
> Greg Trasuk
> 

Re: [Vote] Release Apache River JTSK 3.0.0

[Bryan Thompson]

+1 : I am in favor of this release.


Bryan Thompson
Chief Scientist & Founder
Blazegraph
e: br...@blazegraph.com
w: http://blazegraph.com

Blazegraph products help to solve the Graph Cache Thrash to achieve large
scale processing for graph and predictive analytics.  Blazegraph is the
creator of the industry’s first GPU-accelerated high-performance database
for large graphs, has been named as one of the “10 Companies and
Technologies to Watch in 2016” <http://insideanalysis.com/2016/01/20535/>.

Blazegraph Database <https://www.blazegraph.com/> is our ultra-high
performance graph database that supports both RDF/SPARQL and
Tinkerpop/Blueprints APIs.   Blazegraph GPU
<https://www.blazegraph.com/product/gpu-accelerated/> andBlazegraph DAS
<https://www.blazegraph.com/product/gpu-accelerated/>L are disruptive new
technologies that use GPUs to enable extreme scaling that is thousands of
times faster and 40 times more affordable than CPU-based solutions.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP, LLC DBA Blazegraph.  Any unauthorized review, use,
disclosure, dissemination or copying of this email or its contents or
attachments is prohibited. If you have received this communication in
error, please notify the sender by reply email and permanently delete all
copies of the email and its contents and attachments.

On Tue, Feb 23, 2016 at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote:

> Hello all:
>
> Release candidate artifacts can be found at
> https://dist.apache.org/repos/dist/dev/river/
>
> Binary release artifacts are staged in
> https://repository.apache.org/content/repositories/orgapacheriver-1003/
>
> The vote will remain open for at least 72 hours (Ending no sooner than
> 2100UTC 20160226.
>
> [  ] +1 : I am in favour of this release
> [  ] +0 : I am not opposed to this release.
> [  ] -1: I am against this release (please provide your reasons).
>
> Cheers,
>
> Greg Trasuk
>
>

Re: [Vote] Release Apache River JTSK 3.0.0

[Peter]

+1 non binding

Thanks for getting this done Greg,

I'm not going to have time to review properly until sunday, so will place my 
binding vote then.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 24/02/2016 06:43:47 am
To: dev@river.apache.org
Cc: u...@river.apache.org
Subject: [Vote] Release Apache River JTSK 3.0.0

Hello all: 

Release candidate artifacts can be found at 
https://dist.apache.org/repos/dist/dev/river/ 

Binary release artifacts are staged in 
https://repository.apache.org/content/repositories/orgapacheriver-1003/ 

The vote will remain open for at least 72 hours (Ending no sooner than 2100UTC 
20160226. 

[  ] +1 : I am in favour of this release 
[  ] +0 : I am not opposed to this release. 
[  ] -1: I am against this release (please provide your reasons). 

Cheers, 

Greg Trasuk 

[Vote] Release Apache River JTSK 3.0.0

[Greg Trasuk]

Hello all:

Release candidate artifacts can be found at 
https://dist.apache.org/repos/dist/dev/river/

Binary release artifacts are staged in 
https://repository.apache.org/content/repositories/orgapacheriver-1003/

The vote will remain open for at least 72 hours (Ending no sooner than 2100UTC 
20160226.

[  ] +1 : I am in favour of this release
[  ] +0 : I am not opposed to this release.
[  ] -1: I am against this release (please provide your reasons).

Cheers,

Greg Trasuk

Re: Reminder - [Vote] Release Apache River 2.2.3

[Peter]

Thanks Greg,

Trunk is ready to go if you want to spin a release.

Cheers,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 22/02/2016 02:16:28 am
To: dev@river.apache.org
Subject: Re: Reminder - [Vote] Release Apache River 2.2.3


Hi Peter: 

If the trunk is ready to go, I can spin the release - I’m already familiar with 
the process.  Just let me know. 

Greg. 

> On Feb 20, 2016, at 4:05 AM, Peter <j...@zeus.net.au> wrote: 
>  
> +1 Peter. 
>  
> Will see if I can create some release artifacts for 3 tomorrow. 
>  
>  
> Sent from my Samsung device. 
>   
>   Include original message 
>  Original message  
> From: Greg Trasuk <tras...@stratuscom.com> 
> Sent: 18/02/2016 01:57:32 pm 
> To: dev@river.apache.org 
> Subject: Re: Reminder - [Vote] Release Apache River 2.23 
>  
>  
> I appreciate the effort.  I have to confess I’m getting nervous about River’s 
>ability to make a release.  Ideally we’d have a few more PMC members show up 
>to vote.  In theory there are 14 of us.  
>  
> Cheers,  
>  
> Greg Trasuk  
>  
>>  On Feb 17, 2016, at 6:03 PM, Peter <j...@zeus.net.au> wrote:  
>>    
>>  +1 non binding.  
>>    
>>  I should be able to devote a day this weekend to have a closer look for a 
>>binding vote.  
>>    
>>  Peter.  
>>    
>>  Sent from my Samsung device.  
>> 
>>   Original message   
>>  From: Greg Trasuk <tras...@stratuscom.com>  
>>  Sent: 18/02/2016 06:54:45 am  
>>  To: Greg Trasuk <tras...@stratuscom.com>  
>>  Cc: dev@river.apache.org  
>>  Subject: Re: Reminder - [Vote] Release Apache River 2.2.3  
>>    
>>  Hi all:   
>>    
>>  This vote has been open for over a week at this point, and so far we have 
>>only two binding votes (Patricia asked me to treat her vote as non-binding as 
>>she hasn’t reviewed the release in detail).   
>>    
>>  Could those PMC members on the list please have a look and vote, if you 
>>haven’t yet?   
>>    
>>  Thanks,   
>>    
>>  Greg Trasuk   
>>    
>>  > On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote:  
>> 
>>  >    
>>  >    
>>  >> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:  
>> 
>>  >>    
>>  >> Hello all:   
>>  >>    
>>  >> River 22.3 is the latest release of the Apache River Jini Technology 
>>Starter Kit.  It is a maintenance release that removes the Activation 
>>subsystem and JRMP support.   
>>  >>    
>>  >> The release artifacts and signatures for the release candidate are 
>>available at:   
>>  >> https://dist.apacheorg/repos/dist/dev/river/   
>>  >>    
>>  >> Although not officially part of the release, convenience binaries for 
>>this release are available in the Apache Maven Repository at 
>>https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>>‘org.apache.river’.  When the release is approved, these convenience binaries 
>>will be released to Maven Central.   
>>  >>    
>>  >> [  ] +1: I vote in favour of this release.   
>>  >> [  ] +0: I am not against this release.   
>>  >> [  ] -1: I am against this release (please provide discussion and 
>>reasons)   
>>  >>    
>>  >> The vote will remain open for at least 72 hours, ending not sooner than 
>>UTC Feb 12, 2016.   
>>  >>    
>>  >    
>>    
>>    
>  
>  

Re: Reminder - [Vote] Release Apache River 2.2.3

[Greg Trasuk]

Hi Peter:

If the trunk is ready to go, I can spin the release - I’m already familiar with 
the process.  Just let me know.

Greg.

> On Feb 20, 2016, at 4:05 AM, Peter <j...@zeus.net.au> wrote:
> 
> +1 Peter.
> 
> Will see if I can create some release artifacts for 3 tomorrow.
> 
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message 
> From: Greg Trasuk <tras...@stratuscom.com>
> Sent: 18/02/2016 01:57:32 pm
> To: dev@river.apache.org
> Subject: Re: Reminder - [Vote] Release Apache River 2.2.3
> 
> 
> I appreciate the effort.  I have to confess I’m getting nervous about River’s 
> ability to make a release.  Ideally we’d have a few more PMC members show up 
> to vote.  In theory there are 14 of us. 
> 
> Cheers, 
> 
> Greg Trasuk 
> 
>>  On Feb 17, 2016, at 6:03 PM, Peter <j...@zeus.net.au> wrote: 
>>   
>>  +1 non binding. 
>>   
>>  I should be able to devote a day this weekend to have a closer look for a 
>> binding vote. 
>>   
>>  Peter. 
>>   
>>  Sent from my Samsung device. 
>>
>>   Original message  
>>  From: Greg Trasuk <tras...@stratuscom.com> 
>>  Sent: 18/02/2016 06:54:45 am 
>>  To: Greg Trasuk <tras...@stratuscom.com> 
>>  Cc: dev@river.apache.org 
>>  Subject: Re: Reminder - [Vote] Release Apache River 2.2.3 
>>   
>>  Hi all:  
>>   
>>  This vote has been open for over a week at this point, and so far we have 
>> only two binding votes (Patricia asked me to treat her vote as non-binding 
>> as she hasn’t reviewed the release in detail).  
>>   
>>  Could those PMC members on the list please have a look and vote, if you 
>> haven’t yet?  
>>   
>>  Thanks,  
>>   
>>  Greg Trasuk  
>>   
>>  > On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote:  
>>  >   
>>  >   
>>  >> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:  
>>  >>   
>>  >> Hello all:  
>>  >>   
>>  >> River 2.2.3 is the latest release of the Apache River Jini Technology 
>> Starter Kit.  It is a maintenance release that removes the Activation 
>> subsystem and JRMP support.  
>>  >>   
>>  >> The release artifacts and signatures for the release candidate are 
>> available at:  
>>  >> https://dist.apacheorg/repos/dist/dev/river/  
>>  >>   
>>  >> Although not officially part of the release, convenience binaries for 
>> this release are available in the Apache Maven Repository at 
>> https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>> ‘org.apache.river’.  When the release is approved, these convenience 
>> binaries will be released to Maven Central.  
>>  >>   
>>  >> [  ] +1: I vote in favour of this release.  
>>  >> [  ] +0: I am not against this release.  
>>  >> [  ] -1: I am against this release (please provide discussion and 
>> reasons)  
>>  >>   
>>  >> The vote will remain open for at least 72 hours, ending not sooner than 
>> UTC Feb 12, 2016.  
>>  >>   
>>  >   
>>   
>>   
> 
> 

[Result] Release Apache River 2.2.3

[Greg Trasuk]

Final Results are:

3 Binding ‘+1’s:  Greg Trasuk, Bryan Thompson, Peter Firmstone
3 Non-Binding '+1’s: Patricia Shanahan, Zsolt Kuti, Tom Hobbs

So, the vote carries.  I’ll move the artifacts into the release area and update 
the web pages.

Cheers,

Greg Trasuk

Re: Reminder - [Vote] Release Apache River 2.2.3

[Tom Hobbs]

+1 (non-binding)

Sorry, I just don't have the time to download and verify any of the
artefacts.

On Sat, Feb 20, 2016 at 9:05 AM, Peter <j...@zeus.net.au> wrote:

> +1 Peter.
>
> Will see if I can create some release artifacts for 3 tomorrow.
>
>
> Sent from my Samsung device.
>
>   Include original message
>  Original message 
> From: Greg Trasuk <tras...@stratuscom.com>
> Sent: 18/02/2016 01:57:32 pm
> To: dev@river.apache.org
> Subject: Re: Reminder - [Vote] Release Apache River 2.2.3
>
>
>
> I appreciate the effort.  I have to confess I’m getting nervous about River’s 
> ability to make a release.  Ideally we’d have a few more PMC members show up 
> to vote.  In theory there are 14 of us.
>
> Cheers,
>
> Greg Trasuk
>
> > On Feb 17, 2016, at 6:03 PM, Peter <j...@zeus.net.au> wrote:
> >
> > +1 non binding.
> >
>
> > I should be able to devote a day this weekend to have a closer look for a 
> > binding vote.
> >
> > Peter.
> >
> > Sent from my Samsung device.
> >
> >  Original message 
> > From: Greg Trasuk <tras...@stratuscom.com>
> > Sent: 18/02/2016 06:54:45 am
> > To: Greg Trasuk <tras...@stratuscom.com>
> > Cc: dev@river.apache.org
> > Subject: Re: Reminder - [Vote] Release Apache River 2.2.3
> >
> > Hi all:
> >
>
> > This vote has been open for over a week at this point, and so far we have 
> > only two binding votes (Patricia asked me to treat her vote as non-binding 
> > as she hasn’t reviewed the release in detail).
> >
>
> > Could those PMC members on the list please have a look and vote, if you 
> > haven’t yet?
> >
> > Thanks,
> >
> > Greg Trasuk
> >
> > > On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com
> > wrote:
> > >
> > >
> > >> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com
> > wrote:
> > >>
> > >> Hello all:
> > >>
>
> > >> River 2.2.3 is the latest release of the Apache River Jini Technology 
> > >> Starter Kit.  It is a maintenance release that removes the Activation 
> > >> subsystem and JRMP support.
> > >>
>
> > >> The release artifacts and signatures for the release candidate are 
> > >> available at:
> > >> https://dist.apacheorg/repos/dist/dev/river/
> > >>
>
> > >> Although not officially part of the release, convenience binaries for 
> > >> this release are available in the Apache Maven Repository at
> https://repository.apache.org/content/groups/staging/
>  under ‘net.jini’ and ‘org.apache.river’.  When the release is approved, 
> these convenience binaries will be released to Maven Central.
> > >>
> > >> [  ] +1: I vote in favour of this release.
> > >> [  ] +0: I am not against this release.
>
> > >> [  ] -1: I am against this release (please provide discussion and 
> > >> reasons)
> > >>
>
> > >> The vote will remain open for at least 72 hours, ending not sooner than 
> > >> UTC Feb 12, 2016.
> > >>
> > >
> >
> >
>
>
>

Re: Reminder - [Vote] Release Apache River 2.2.3

[Peter]

+1 Peter.

Will see if I can create some release artifacts for 3 tomorrow.


Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 18/02/2016 01:57:32 pm
To: dev@river.apache.org
Subject: Re: Reminder - [Vote] Release Apache River 2.2.3


I appreciate the effort.  I have to confess I’m getting nervous about River’s 
ability to make a release.  Ideally we’d have a few more PMC members show up to 
vote.  In theory there are 14 of us. 

Cheers, 

Greg Trasuk 

> On Feb 17, 2016, at 6:03 PM, Peter <j...@zeus.net.au> wrote: 
>  
> +1 non binding. 
>  
> I should be able to devote a day this weekend to have a closer look for a 
>binding vote. 
>  
> Peter. 
>  
> Sent from my Samsung device. 
>   
>  Original message  
> From: Greg Trasuk <tras...@stratuscom.com> 
> Sent: 18/02/2016 06:54:45 am 
> To: Greg Trasuk <tras...@stratuscom.com> 
> Cc: dev@river.apache.org 
> Subject: Re: Reminder - [Vote] Release Apache River 2.2.3 
>  
> Hi all:  
>  
> This vote has been open for over a week at this point, and so far we have 
>only two binding votes (Patricia asked me to treat her vote as non-binding as 
>she hasn’t reviewed the release in detail).  
>  
> Could those PMC members on the list please have a look and vote, if you 
>haven’t yet?  
>  
> Thanks,  
>  
> Greg Trasuk  
>  
> > On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote:  
> >   
> >   
> >> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:  
> >>   
> >> Hello all:  
> >>   
> >> River 2.2.3 is the latest release of the Apache River Jini Technology 
>Starter Kit.  It is a maintenance release that removes the Activation 
>subsystem and JRMP support.  
> >>   
> >> The release artifacts and signatures for the release candidate are 
>available at:  
> >> https://dist.apacheorg/repos/dist/dev/river/  
> >>   
> >> Although not officially part of the release, convenience binaries for this 
>release are available in the Apache Maven Repository at 
>https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>‘org.apache.river’.  When the release is approved, these convenience binaries 
>will be released to Maven Central.  
> >>   
> >> [  ] +1: I vote in favour of this release.  
> >> [  ] +0: I am not against this release.  
> >> [  ] -1: I am against this release (please provide discussion and reasons) 
> 
> >>   
> >> The vote will remain open for at least 72 hours, ending not sooner than 
>UTC Feb 12, 2016.  
> >>   
> >   
>  
>  

Re: Reminder - [Vote] Release Apache River 2.2.3

[Greg Trasuk]

I appreciate the effort.  I have to confess I’m getting nervous about River’s 
ability to make a release.  Ideally we’d have a few more PMC members show up to 
vote.  In theory there are 14 of us.

Cheers,

Greg Trasuk

> On Feb 17, 2016, at 6:03 PM, Peter <j...@zeus.net.au> wrote:
> 
> +1 non binding.
> 
> I should be able to devote a day this weekend to have a closer look for a 
> binding vote.
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>  Original message 
> From: Greg Trasuk <tras...@stratuscom.com>
> Sent: 18/02/2016 06:54:45 am
> To: Greg Trasuk <tras...@stratuscom.com>
> Cc: dev@river.apache.org
> Subject: Re: Reminder - [Vote] Release Apache River 2.2.3
> 
> Hi all: 
> 
> This vote has been open for over a week at this point, and so far we have 
> only two binding votes (Patricia asked me to treat her vote as non-binding as 
> she hasn’t reviewed the release in detail). 
> 
> Could those PMC members on the list please have a look and vote, if you 
> haven’t yet? 
> 
> Thanks, 
> 
> Greg Trasuk 
> 
> > On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote: 
> >  
> >  
> >> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote: 
> >>  
> >> Hello all: 
> >>  
> >> River 2.2.3 is the latest release of the Apache River Jini Technology 
> >> Starter Kit.  It is a maintenance release that removes the Activation 
> >> subsystem and JRMP support. 
> >>  
> >> The release artifacts and signatures for the release candidate are 
> >> available at: 
> >> https://dist.apacheorg/repos/dist/dev/river/ 
> >>  
> >> Although not officially part of the release, convenience binaries for this 
> >> release are available in the Apache Maven Repository at 
> >> https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
> >> ‘org.apache.river’.  When the release is approved, these convenience 
> >> binaries will be released to Maven Central. 
> >>  
> >> [  ] +1: I vote in favour of this release. 
> >> [  ] +0: I am not against this release. 
> >> [  ] -1: I am against this release (please provide discussion and reasons) 
> >>  
> >> The vote will remain open for at least 72 hours, ending not sooner than 
> >> UTC Feb 12, 2016. 
> >>  
> >  
> 
> 

Re: Reminder - [Vote] Release Apache River 2.2.3

[Peter]

+1 non binding.

I should be able to devote a day this weekend to have a closer look for a 
binding vote.

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 18/02/2016 06:54:45 am
To: Greg Trasuk <tras...@stratuscom.com>
Cc: dev@river.apache.org
Subject: Re: Reminder - [Vote] Release Apache River 2.2.3

Hi all: 

This vote has been open for over a week at this point, and so far we have only 
two binding votes (Patricia asked me to treat her vote as non-binding as she 
hasn’t reviewed the release in detail). 

Could those PMC members on the list please have a look and vote, if you haven’t 
yet? 

Thanks, 

Greg Trasuk 

> On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote: 
>  
>  
>> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote: 
>>  
>> Hello all: 
>>  
>> River 2.2.3 is the latest release of the Apache River Jini Technology 
>>Starter Kit.  It is a maintenance release that removes the Activation 
>>subsystem and JRMP support. 
>>  
>> The release artifacts and signatures for the release candidate are available 
>>at: 
>> https://dist.apache.org/repos/dist/dev/river/ 
>>  
>> Although not officially part of the release, convenience binaries for this 
>>release are available in the Apache Maven Repository at 
>>https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>>‘org.apache.river’.  When the release is approved, these convenience binaries 
>>will be released to Maven Central 
>>  
>> [  ] +1: I vote in favour of this release. 
>> [  ] +0: I am not against this release. 
>> [  ] -1: I am against this release (please provide discussion and reasons) 
>>  
>> The vote will remain open for at least 72 hours, ending not sooner than 
>>UTC Feb 12, 2016. 
>>  
>  

Re: Reminder - [Vote] Release Apache River 2.2.3

[Greg Trasuk]

Hi all:

This vote has been open for over a week at this point, and so far we have only 
two binding votes (Patricia asked me to treat her vote as non-binding as she 
hasn’t reviewed the release in detail).

Could those PMC members on the list please have a look and vote, if you haven’t 
yet?

Thanks,

Greg Trasuk

> On Feb 10, 2016, at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote:
> 
> 
>> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
>> 
>> Hello all:
>> 
>> River 2.2.3 is the latest release of the Apache River Jini Technology 
>> Starter Kit.  It is a maintenance release that removes the Activation 
>> subsystem and JRMP support.
>> 
>> The release artifacts and signatures for the release candidate are available 
>> at:
>> https://dist.apache.org/repos/dist/dev/river/
>> 
>> Although not officially part of the release, convenience binaries for this 
>> release are available in the Apache Maven Repository at 
>> https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>> ‘org.apache.river’.  When the release is approved, these convenience 
>> binaries will be released to Maven Central.
>> 
>> [  ] +1: I vote in favour of this release.
>> [  ] +0: I am not against this release.
>> [  ] -1: I am against this release (please provide discussion and reasons)
>> 
>> The vote will remain open for at least 72 hours, ending not sooner than 
>> UTC Feb 12, 2016.
>> 
> 

Reminder - [Vote] Release Apache River 2.2.3

[Greg Trasuk]

> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> 
> Hello all:
> 
> River 2.2.3 is the latest release of the Apache River Jini Technology Starter 
> Kit.  It is a maintenance release that removes the Activation subsystem and 
> JRMP support.
> 
> The release artifacts and signatures for the release candidate are available 
> at:
> https://dist.apache.org/repos/dist/dev/river/
> 
> Although not officially part of the release, convenience binaries for this 
> release are available in the Apache Maven Repository at 
> https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
> ‘org.apache.river’.  When the release is approved, these convenience binaries 
> will be released to Maven Central.
> 
> [  ] +1: I vote in favour of this release.
> [  ] +0: I am not against this release.
> [  ] -1: I am against this release (please provide discussion and reasons)
> 
> The vote will remain open for at least 72 hours, ending not sooner than 
> UTC Feb 12, 2016.
> 

Re: Reminder - [Vote] Release Apache River 2.2.3

[Bryan Thompson]

+1: I vote in favor of this release.


Bryan Thompson
Chief Scientist & Founder
Blazegraph
4501 Tower Road
Greensboro, NC 27410
br...@blazegraph.com
http://blazegraph.com
http://blog.blazegraph.com

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP, LLC DBA Blazegraph. Any unauthorized review, use,
disclosure, dissemination or copying of this email or its contents or
attachments is prohibited. If you have received this communication in
error, please notify the sender by reply email and permanently delete all
copies of the email and its contents and attachments.

On Wed, Feb 10, 2016 at 9:10 AM, Greg Trasuk <tras...@stratuscom.com> wrote:

>
> > On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> >
> > Hello all:
> >
> > River 2.2.3 is the latest release of the Apache River Jini Technology
> Starter Kit.  It is a maintenance release that removes the Activation
> subsystem and JRMP support.
> >
> > The release artifacts and signatures for the release candidate are
> available at:
> > https://dist.apache.org/repos/dist/dev/river/
> >
> > Although not officially part of the release, convenience binaries for
> this release are available in the Apache Maven Repository at
> https://repository.apache.org/content/groups/staging/ under ‘net.jini’
> and ‘org.apache.river’.  When the release is approved, these convenience
> binaries will be released to Maven Central.
> >
> > [  ] +1: I vote in favour of this release.
> > [  ] +0: I am not against this release.
> > [  ] -1: I am against this release (please provide discussion and
> reasons)
> >
> > The vote will remain open for at least 72 hours, ending not sooner than
> UTC Feb 12, 2016.
> >
>
>

Re: Reminder - [Vote] Release Apache River 2.2.3

[Zsolt Kúti]

+1 for this release

On Wed, Feb 10, 2016 at 3:10 PM, Greg Trasuk <tras...@stratuscom.com> wrote:

>
> > On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> >
> > Hello all:
> >
> > River 2.2.3 is the latest release of the Apache River Jini Technology
> Starter Kit.  It is a maintenance release that removes the Activation
> subsystem and JRMP support.
> >
> > The release artifacts and signatures for the release candidate are
> available at:
> > https://dist.apache.org/repos/dist/dev/river/
> >
> > Although not officially part of the release, convenience binaries for
> this release are available in the Apache Maven Repository at
> https://repository.apache.org/content/groups/staging/ under ‘net.jini’
> and ‘org.apache.river’.  When the release is approved, these convenience
> binaries will be released to Maven Central.
> >
> > [  ] +1: I vote in favour of this release.
> > [  ] +0: I am not against this release.
> > [  ] -1: I am against this release (please provide discussion and
> reasons)
> >
> > The vote will remain open for at least 72 hours, ending not sooner than
> UTC Feb 12, 2016.
> >
>
>

Re: [Vote] Release Apache River 2.2.3

[Greg Trasuk]

As its just a maintenance release, 7 days seems a little long.  Let’s just 
leave it at ‘at least til Thurs’ and we can leave it open as long as it takes 
to get 3 ‘+1’s.  I think it would make sense to finish off this vote before we 
open the voting on ‘3.0’, but that’s up to whoever is acting as ‘3.0' release 
manager.

For what it’s worth, I’ve run the integration tests (not the jtreg tests) on a 
Raspberry pi and they pass.



Cheers,

Greg.
> On Feb 8, 2016, at 11:23 PM, Peter <j...@zeus.net.au> wrote:
> 
> We might need a little more time than 72 hours to build and run tests.  Can 
> you make the vote close Monday? That'll provide some more time for review.
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message 
> From: Greg Trasuk <tras...@stratuscom.com>
> Sent: 09/02/2016 10:49:11 am
> To: dev@river.apache.org
> Cc: u...@river.apache.org
> Subject: Re: [Vote] Release Apache River 2.2.3
> 
> 
> +1 from me. 
> 
> Greg Trasuk 
> 
>>  On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote: 
>>   
>>  Hello all: 
>>   
>>  River 2.2.3 is the latest release of the Apache River Jini Technology 
>> Starter Kit.  It is a maintenance release that removes the Activation 
>> subsystem and JRMP support. 
>>   
>>  The release artifacts and signatures for the release candidate are 
>> available at: 
>>  https://dist.apacheorg/repos/dist/dev/river/ 
>>   
>>  Although not officially part of the release, convenience binaries for this 
>> release are available in the Apache Maven Repository at 
>> https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>> ‘org.apache.river’.  When the release is approved, these convenience 
>> binaries will be released to Maven Central. 
>>   
>>  [X ] +1: I vote in favour of this release. 
>>  [  ] +0: I am not against this release. 
>>  [  ] -1: I am against this release (please provide discussion and reasons) 
>>   
>>  The vote will remain open for at least 72 hours, ending not sooner than 
>> UTC Feb 12, 2016. 
>>   
> 
> 

Re: [Vote] Release Apache River 2.2.3

[Peter]

We might need a little more time than 72 hours to build and run tests.  Can you 
make the vote close Monday? That'll provide some more time for review.

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 09/02/2016 10:49:11 am
To: dev@river.apache.org
Cc: u...@river.apache.org
Subject: Re: [Vote] Release Apache River 2.2.3


+1 from me. 

Greg Trasuk 

> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote: 
>  
> Hello all: 
>  
> River 2.2.3 is the latest release of the Apache River Jini Technology Starter 
>Kit.  It is a maintenance release that removes the Activation subsystem and 
>JRMP support. 
>  
> The release artifacts and signatures for the release candidate are available 
>at: 
> https://dist.apacheorg/repos/dist/dev/river/ 
>  
> Although not officially part of the release, convenience binaries for this 
>release are available in the Apache Maven Repository at 
>https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
>‘org.apache.river’.  When the release is approved, these convenience binaries 
>will be released to Maven Central. 
>  
> [X ] +1: I vote in favour of this release. 
> [  ] +0: I am not against this release. 
> [  ] -1: I am against this release (please provide discussion and reasons) 
>  
> The vote will remain open for at least 72 hours, ending not sooner than 
>UTC Feb 12, 2016. 
>  

[Vote] Release Apache River 2.2.3

[Greg Trasuk]

Hello all:

River 2.2.3 is the latest release of the Apache River Jini Technology Starter 
Kit.  It is a maintenance release that removes the Activation subsystem and 
JRMP support.

The release artifacts and signatures for the release candidate are available at:
https://dist.apache.org/repos/dist/dev/river/

Although not officially part of the release, convenience binaries for this 
release are available in the Apache Maven Repository at 
https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
‘org.apache.river’.  When the release is approved, these convenience binaries 
will be released to Maven Central.

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and reasons)

The vote will remain open for at least 72 hours, ending not sooner than UTC 
Feb 12, 2016.

Re: [Vote] Release Apache River 2.2.3

[Greg Trasuk]

+1 from me.

Greg Trasuk

> On Feb 8, 2016, at 5:02 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> 
> Hello all:
> 
> River 2.2.3 is the latest release of the Apache River Jini Technology Starter 
> Kit.  It is a maintenance release that removes the Activation subsystem and 
> JRMP support.
> 
> The release artifacts and signatures for the release candidate are available 
> at:
> https://dist.apache.org/repos/dist/dev/river/
> 
> Although not officially part of the release, convenience binaries for this 
> release are available in the Apache Maven Repository at 
> https://repository.apache.org/content/groups/staging/ under ‘net.jini’ and 
> ‘org.apache.river’.  When the release is approved, these convenience binaries 
> will be released to Maven Central.
> 
> [X ] +1: I vote in favour of this release.
> [  ] +0: I am not against this release.
> [  ] -1: I am against this release (please provide discussion and reasons)
> 
> The vote will remain open for at least 72 hours, ending not sooner than 
> UTC Feb 12, 2016.
> 

Couple of minor roadblocks to the 3.0 release

[Greg Trasuk]

Hi all:

As Peter asked me to, I’ve modified the trunk version to download the compile 
dependencies at compile time using Apache Ivy, so we won’t be shipping binaries 
in the source distribution.  I’ve hit a couple of minor delays, and I’d like 
input on how to proceed…

1 - API signature verification using animal-sniffer:  The animal-sniffer 
package is available through Maven Central, so there’s no problem downloading 
it at compile time, but I’ve had difficulty getting the actual signatures.  
They’re on Maven Central, but so far I’m having difficulty actually downloading 
them with Ivy.  I think the issue is that the signatures are not actually 
listed as the artifact in the pom file.  From what I can tell, the 
animal-sniffer plugin does some kind of magic to actually retrieve the 
signatures.  I suspect that I need to dig in to Ivy a little deeper to figure 
out how to do the same thing.  Long term, we should not have a problem.

2 - There are tests in the ‘test’ folder that depend on the ‘imunit.jar’ unit 
test library from the University of Illinois.  Unfortunately this library is 
not available on Maven Central.

I’m inclined to simply disable/comment out both the signature verification and 
the affected unit tests for now, so as not to delay the release.  As I said, 
the signature issue is probably an Ivy configuration thing.  The imunit issue 
is more of a problem.  What I propose to do is contact the authors and see if 
they’re able to put it up on Maven Central, so we can download it at compile 
time.  If they’re not able to do that, the license would allow me to put it on 
Central under my own name (much like Stephen Connolly did with the 
high-scale-lib).  Either option will likely take a few weeks.  In the mean 
time, we know that Peter has run both the unit tests and the signature 
verification locally, so I don’t think there’s a real blocker for the release 
if we just forgo these tests for now.  We’ll re-enable them as soon as possible.

Happy to hear any opinions…

Greg Trasuk

Re: Release vote procedure

[Peter]

I'm trying to think of a new technology we've introduced in River 3.0, I'm 
afraid I can only really think of one; Groovy configuration, I like that 
feature, it's probably going to have the greatest impact on users.

Everything else in River 3.0 is bug fixes and scalability improvements, yes 
there could be a problem somewhere, but it's nothing that can't be fixed 
quickly.

I think in 3 to 6 months there will be a majority concensus that 3.0 has been a 
success, by then  I hope we have you convinced that the people who contribute 
to this project are capable of maintaining it.

I'm also hoping it'll open your mind to investigation.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 10/01/2016 06:11:42 am
To: dev@river.apache.org
Subject: Re: Release vote procedure

72 hours is a guideline.  I think it’s reasonable - that’s what most projects 
use.  But if you think it’s not enough in this case, make it 5 days or 7 days.  
Whatever.  Doesn’t take that long to run the rat reports and see if it builds. 

The “tested the release candidate” is probably what you’re worried about.  What 
we’ve discussed and decided on is that the “3.0” release is a “technology 
preview” and shouldn’t be expected to be perfect or fit for any use.  The 
release is simply attesting to the fact that it’s an Apache product, duly 
licensed and vouched for. 

Cheers, 

Greg Trasuk 

> On Jan 9, 2016, at 2:51 PM, Patricia Shanahan <p...@acm.org> wrote: 
>  
> Remember that a PMC member voting +1 is asserting that they have personally 
>downloaded, built, and tested the release candidate, as well as reviewing its 
>licensing. 
>  
> Do we have three PMC members who can do that within 72 hours? Anybody who 
>would vote -1 on that schedule? 
>  
> (I do not expect to be able to vote in favor in 72 hours from now, but will 
>not vote against unless someone reports a real problem. Most likely, I'll not 
>vote at all.) 
>  
> Patricia 
>  
> On 1/9/2016 11:42 AM, Greg Trasuk wrote: 
>>  
>> What I actually meant (sorry for not writing precisely) is why not call the 
>>72-hour vote now and release it? 
>>  
>> Cheers, 
>>  
>> Greg. 
>>> On Jan 9, 2016, at 12:39 PM, Patricia Shanahan <p...@acm.org> wrote: 
>>>  
>>> Now that we have a release candidate (YEAH!), we need to sort out how 
>>> and when to vote on it. We have two proposals, copied from different 
>>> e-mails. 
>>>  
>>> Peter Firmstone: 
>>>> Voting on this release will commence in 4 weeks, to allow time for 
>>>> people to check they can reproduce these artifacts and test their 
>>>> code and report back with any issues. 
>>>  
>>> Greg Trasuk: 
>>>> Why not just go ahead and call the vote now?  Once we have 3 ‘+1’s 
>>>> saying it meets the license requirements, then we can put it up on 
>>>> the main page. 
>>>  
>>> Each of these has possible problems. 
>>>  
>>> Peter's plan takes at least 31 days: 4 weeks followed by a minimum of 72 
>>> hours for the vote. That may be longer than necessary. 
>>>  
>>> On the other hand, people who succeed in building and testing may be 
>>> ready to vote sooner than people who have problems, so we could hit 
>>> three +1 votes early, even if there would also have been three -1 votes. 
>>> A vote needs to have a definite time period. Also, releases are not 
>>> vetoed by -1 votes, but if anyone detects a serious problem we need to 
>>> stop and regroup, even if three PMC members have built and tested 
>>> successfully. 
>>>  
>>> I suggest a two phase process similar to Peter's plan, but without the 
>>> fixed time frame. Instead, anyone who plans to vote should record their 
>>> intent here, proceed with building and testing, and report their 
>>> results. Deal with any issues on a consensus basis - I'm hoping there 
>>> will be none because the issues have already been discussed. 
>>>  
>>> When most PMC members who plan to vote have reported success, we can 
>>> call an immediate 72 hour (or slightly longer) vote. 
>>>  
>>> Patricia 
>>  

Re: Release vote procedure

[Greg Trasuk]

What I actually meant (sorry for not writing precisely) is why not call the 
72-hour vote now and release it? 

Cheers,

Greg.
> On Jan 9, 2016, at 12:39 PM, Patricia Shanahan <p...@acm.org> wrote:
> 
> Now that we have a release candidate (YEAH!), we need to sort out how
> and when to vote on it. We have two proposals, copied from different
> e-mails.
> 
> Peter Firmstone:
>> Voting on this release will commence in 4 weeks, to allow time for
>> people to check they can reproduce these artifacts and test their
>> code and report back with any issues.
> 
> Greg Trasuk:
>> Why not just go ahead and call the vote now?  Once we have 3 ‘+1’s
>> saying it meets the license requirements, then we can put it up on
>> the main page.
> 
> Each of these has possible problems.
> 
> Peter's plan takes at least 31 days: 4 weeks followed by a minimum of 72
> hours for the vote. That may be longer than necessary.
> 
> On the other hand, people who succeed in building and testing may be
> ready to vote sooner than people who have problems, so we could hit
> three +1 votes early, even if there would also have been three -1 votes.
> A vote needs to have a definite time period. Also, releases are not
> vetoed by -1 votes, but if anyone detects a serious problem we need to
> stop and regroup, even if three PMC members have built and tested
> successfully.
> 
> I suggest a two phase process similar to Peter's plan, but without the
> fixed time frame. Instead, anyone who plans to vote should record their
> intent here, proceed with building and testing, and report their
> results. Deal with any issues on a consensus basis - I'm hoping there
> will be none because the issues have already been discussed.
> 
> When most PMC members who plan to vote have reported success, we can
> call an immediate 72 hour (or slightly longer) vote.
> 
> Patricia

Re: Release vote procedure

[Patricia Shanahan]

Remember that a PMC member voting +1 is asserting that they have 
personally downloaded, built, and tested the release candidate, as well 
as reviewing its licensing.


Do we have three PMC members who can do that within 72 hours? Anybody 
who would vote -1 on that schedule?


(I do not expect to be able to vote in favor in 72 hours from now, but 
will not vote against unless someone reports a real problem. Most 
likely, I'll not vote at all.)


Patricia

On 1/9/2016 11:42 AM, Greg Trasuk wrote:


What I actually meant (sorry for not writing precisely) is why not call the 
72-hour vote now and release it?

Cheers,

Greg.

On Jan 9, 2016, at 12:39 PM, Patricia Shanahan <p...@acm.org> wrote:

Now that we have a release candidate (YEAH!), we need to sort out how
and when to vote on it. We have two proposals, copied from different
e-mails.

Peter Firmstone:

Voting on this release will commence in 4 weeks, to allow time for
people to check they can reproduce these artifacts and test their
code and report back with any issues.


Greg Trasuk:

Why not just go ahead and call the vote now?  Once we have 3 ‘+1’s
saying it meets the license requirements, then we can put it up on
the main page.


Each of these has possible problems.

Peter's plan takes at least 31 days: 4 weeks followed by a minimum of 72
hours for the vote. That may be longer than necessary.

On the other hand, people who succeed in building and testing may be
ready to vote sooner than people who have problems, so we could hit
three +1 votes early, even if there would also have been three -1 votes.
A vote needs to have a definite time period. Also, releases are not
vetoed by -1 votes, but if anyone detects a serious problem we need to
stop and regroup, even if three PMC members have built and tested
successfully.

I suggest a two phase process similar to Peter's plan, but without the
fixed time frame. Instead, anyone who plans to vote should record their
intent here, proceed with building and testing, and report their
results. Deal with any issues on a consensus basis - I'm hoping there
will be none because the issues have already been discussed.

When most PMC members who plan to vote have reported success, we can
call an immediate 72 hour (or slightly longer) vote.

Patricia

Re: Release vote procedure

[Greg Trasuk]

72 hours is a guideline.  I think it’s reasonable - that’s what most projects 
use.  But if you think it’s not enough in this case, make it 5 days or 7 days.  
Whatever.  Doesn’t take that long to run the rat reports and see if it builds.

The “tested the release candidate” is probably what you’re worried about.  What 
we’ve discussed and decided on is that the “3.0” release is a “technology 
preview” and shouldn’t be expected to be perfect or fit for any use.  The 
release is simply attesting to the fact that it’s an Apache product, duly 
licensed and vouched for.

Cheers,

Greg Trasuk

> On Jan 9, 2016, at 2:51 PM, Patricia Shanahan <p...@acm.org> wrote:
> 
> Remember that a PMC member voting +1 is asserting that they have personally 
> downloaded, built, and tested the release candidate, as well as reviewing its 
> licensing.
> 
> Do we have three PMC members who can do that within 72 hours? Anybody who 
> would vote -1 on that schedule?
> 
> (I do not expect to be able to vote in favor in 72 hours from now, but will 
> not vote against unless someone reports a real problem. Most likely, I'll not 
> vote at all.)
> 
> Patricia
> 
> On 1/9/2016 11:42 AM, Greg Trasuk wrote:
>> 
>> What I actually meant (sorry for not writing precisely) is why not call the 
>> 72-hour vote now and release it?
>> 
>> Cheers,
>> 
>> Greg.
>>> On Jan 9, 2016, at 12:39 PM, Patricia Shanahan <p...@acm.org> wrote:
>>> 
>>> Now that we have a release candidate (YEAH!), we need to sort out how
>>> and when to vote on it. We have two proposals, copied from different
>>> e-mails.
>>> 
>>> Peter Firmstone:
>>>> Voting on this release will commence in 4 weeks, to allow time for
>>>> people to check they can reproduce these artifacts and test their
>>>> code and report back with any issues.
>>> 
>>> Greg Trasuk:
>>>> Why not just go ahead and call the vote now?  Once we have 3 ‘+1’s
>>>> saying it meets the license requirements, then we can put it up on
>>>> the main page.
>>> 
>>> Each of these has possible problems.
>>> 
>>> Peter's plan takes at least 31 days: 4 weeks followed by a minimum of 72
>>> hours for the vote. That may be longer than necessary.
>>> 
>>> On the other hand, people who succeed in building and testing may be
>>> ready to vote sooner than people who have problems, so we could hit
>>> three +1 votes early, even if there would also have been three -1 votes.
>>> A vote needs to have a definite time period. Also, releases are not
>>> vetoed by -1 votes, but if anyone detects a serious problem we need to
>>> stop and regroup, even if three PMC members have built and tested
>>> successfully.
>>> 
>>> I suggest a two phase process similar to Peter's plan, but without the
>>> fixed time frame. Instead, anyone who plans to vote should record their
>>> intent here, proceed with building and testing, and report their
>>> results. Deal with any issues on a consensus basis - I'm hoping there
>>> will be none because the issues have already been discussed.
>>> 
>>> When most PMC members who plan to vote have reported success, we can
>>> call an immediate 72 hour (or slightly longer) vote.
>>> 
>>> Patricia
>> 

Re: River - 3.0.0 Release candidate

[Patricia Shanahan]

These are the sorts of issues that I think should be sorted out, on a 
consensus basis, during a preliminary review-and-test phase.


On 1/9/2016 12:16 PM, Greg Trasuk wrote:

- I also though we had agreed to take the ‘examples’ folder out of the JTSK.

Cheers,

Greg


On Jan 9, 2016, at 3:05 PM, Greg Trasuk <tras...@stratuscom.com> wrote:


I’ve only looked at the ‘apache-river-3.0.0.tar.gz’ archive.  A few issues…

- we can’t have jar files in the source distribution.  Which means we have a 
problem with ‘dep-libs’.  You could either setup a separate download for 
developers to retrieve, or just give a list of the libraries that are needed.  
What I’d recommend is to modify the build script to use Apache Ivy to go get 
the requisite libraries at build time.  See the 2.2 branch for an example on 
how to do this.
- as above for ‘test/lib’
- The ‘tar_release_test’ folder should be removed
- There is a “LICENSE” and a “LICENSE.txt” file in the root of the 
distribution.  They’re identical - delete LICENSE.txt
- Same with NOTICE and NOTICE.txt.
- Both of the above will need to be reviewed when the jar files have been 
sorted out.  Also, we may need a different LICENSE and NOTICE file for the 
binary convenience artifacts.
- ‘doap-river.rdf’ is not really specific to the 3.0.0 release, so it shouldn’t 
be in the release artifact.
- ‘build.properties’ doesn’t have a license header.
- I’d remove the ‘nbproject’ folder myself - the project shouldn’t be dependent 
on the IDE.  Although we might want to include instructions on how to open it 
in an IDE.
- I could be wrong on this, but I think the current recommendation is to not 
include a “KEYS” file, but for the release manager to register his/her keys on 
‘id.apache.org’.

Cheers,

Greg Trasuk


On Jan 8, 2016, at 6:56 AM, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:

The Apache River 3.0.0 Release candidate is available here:

http://people.apache.org/~peter_firmstone/

Voting on this release will commence in 4 weeks, to allow time for people to 
check they can reproduce these artifacts and test their code and report back 
with any issues.

The code is currently in trunk, this will be branched after the 4 week review 
period and Voting passes.

See also http://www.apache.org/dev/release-publishing.html

Regards,

Peter.

Re: River - 3.0.0 Release candidate

[trasukg]

Happy to help, but I'll be traveling for a few days, so it won't be til the 
15th or so before I can have a look at it. If nobody else gets to it first I'll 
have a go.

Greg Trasuk.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Peter
Sent: Saturday, January 9, 2016 5:43 PM
To: dev@river.apache.org
Reply To: dev@river.apache.org
Subject: Re: River - 3.0.0 Release candidate

Greg,

If you want to remedy these issues for me, I can regenerate the release 
artifacts.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 10/01/2016 06:16:09 am
To: dev@river.apache.org
Subject: Re: River - 3.0.0 Release candidate

- I also though we had agreed to take the ‘examples’ folder out of the JTSK. 

Cheers, 

Greg  

> On Jan 9, 2016, at 3:05 PM, Greg Trasuk <tras...@stratuscom.com> wrote: 
>  
>  
> I’ve only looked at the ‘apache-river-3.0.0.tar.gz’ archive.  A few issues… 
>  
> - we can’t have jar files in the source distribution.  Which means we have a 
>problem with ‘dep-libs’.  You could either setup a separate download for 
>developers to retrieve, or just give a list of the libraries that are needed.  
>What I’d recommend is to modify the build script to use Apache Ivy to go get 
>the requisite libraries at build time.  See the 2.2 branch for an example on 
>how to do this. 
> - as above for ‘test/lib’ 
> - The ‘tar_release_test’ folder should be removed 
> - There is a “LICENSE” and a “LICENSE.txt” file in the root of the 
>distribution.  They’re identical - delete LICENSE.txt 
> - Same with NOTICE and NOTICE.txt. 
> - Both of the above will need to be reviewed when the jar files have been 
>sorted out.  Also, we may need a different LICENSE and NOTICE file for the 
>binary convenience artifacts. 
> - ‘doap-river.rdf’ is not really specific to the 3.0.0 release, so it 
>shouldn’t be in the release artifact 
> - ‘build.properties’ doesn’t have a license header. 
> - I’d remove the ‘nbproject’ folder myself - the project shouldn’t be 
>dependent on the IDE.  Although we might want to include instructions on how 
>to open it in an IDE. 
> - I could be wrong on this, but I think the current recommendation is to not 
>include a “KEYS” file, but for the release manager to register his/her keys on 
>‘id.apache.org’. 
>  
> Cheers, 
>  
> Greg Trasuk 
>  
>> On Jan 8, 2016, at 6:56 AM, Peter Firmstone <peter.firmst...@zeus.net.au> 
>>wrote: 
>>  
>> The Apache River 3.0.0 Release candidate is available here: 
>>  
>> http://people.apache.org/~peter_firmstone/
>>  
>> Voting on this release will commence in 4 weeks, to allow time for people to 
>>check they can reproduce these artifacts and test their code and report back 
>>with any issues. 
>>  
>> The code is currently in trunk, this will be branched after the 4 week 
>>review period and Voting passes. 
>>  
>> See also http://www.apache.org/dev/release-publishing.html 
>>  
>> Regards, 
>>  
>> Peter. 
>  

Re: River - 3.0.0 Release candidate

[Peter]

 
I have found that discussing even the simplest changes have become labourious.  
I understand that people can be very passionate about Jini.  It's refreshing 
posting to other projects, attitudes are much more positive and I think that's 
because those projects have established a clear set of goals.

I'm glad jmm compliance is 98% complete,  there are still likely to be a few 
issues in the qa suite, but now the brittlness has gone, I can make changes 
without something breaking.

With ipv6 the shackles of NAT will be removed.  

Right now we have http and https jeri endpoints, we can already do the client 
server model of the internet, albiet with dodgy security.  But we can't to p2p 
now between different local networks behind nat.

Ipv6 will enable global discovery.  And it will enable peer to peer services.  
File sharing anyone?

IPv6 will redefine the internet, it's a game changer and deployment is going 
exponential.

The only way to stop River on the internet, is to not implement support for 
ipv6 discovery.

If we are to tackle the internet with ipv6 we'll need a much more positive, 
interactive and collaborative development environment.

We may need to create a place where those who are interested can discuss that 
and flesh it out, then we could present it to the wider River community for 
comment.

As a developer I need to be part of a team, as that creates better api and code 
than I can create alone.

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 10/01/2016 06:26:05 am
To: dev@river.apache.org
Subject: Re: River - 3.0.0 Release candidate

I am looking forward to a very open strategy discussion once we get 3.0  
done. I hope everyone will focus during that on ideas and logical  
arguments supported by facts, rather than on personalities. 

On 1/9/2016 12:16 PM, Gregg Wonderly wrote: 
> I sent Greg Trasuk a private note asking him to cease and desist on 
> public badgering and instead to just step back and let the community 
> vote on what happens with River, as that is the process that is 
> supposed to work.  I suggested that if he had a plan and members to 
> vote that plan through, that he could have things however he wanted. 
> I really do not appreciate his attitude and lack of appreciation for 
> the experience and expertise that others have which is different from 
> his own.  I don’t want to badger or belittle him in any way.  But, we 
> need to use this process and work through issues by using our brains 
> and our experiences both.  The “web” as we know it, is “mobile code” 
> just like Jini uses.  Javascript won, because it was controlled by 
> the browser camp, not by Sun  Applets were in the browser first, but 
> the size of PCs memory and computational resources were no where near 
> mature enough for Java to have won.  I know, I tried to deploy lots 
> of Java in Applets and applications in that time, to the desktop, but 
> there was just not enough money spent on desktop machines in the 
> enterprises where my customers were.  I am, hopefully going to get 
> back out of the .Net world and back into Java and Jini again, this 
> coming year.  I am looking forward to that! 
> 
> Gregg 
> 
>> On Jan 8, 2016, at 5:56 AM, Peter Firmstone 
>> <peter.firmst...@zeus.net.au> wrote: 
>> 
>> The Apache River 3.0.0 Release candidate is available here: 
>> 
>> http://people.apache.org/~peter_firmstone/ 
>> 
>> Voting on this release will commence in 4 weeks, to allow time for 
>> people to check they can reproduce these artifacts and test their 
>> code and report back with any issues. 
>> 
>> The code is currently in trunk, this will be branched after the 4 
>> week review period and Voting passes. 
>> 
>> See also http://www.apache.org/dev/release-publishing.html 
>> 
>> Regards, 
>> 
>> Peter. 
> 

Re: River - 3.0.0 Release candidate

[Peter]

Thanks Greg, much appreciated.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: tras...@stratuscom.com
Sent: 10/01/2016 08:57:18 am
To: Peter <dev@river.apache.org>; dev@river.apache.org
Subject: Re: River - 3.0.0 Release candidate

Happy to help, but I'll be traveling for a few days, so it won't be til the 
15th or so before I can have a look at it. If nobody else gets to it first I'll 
have a go. 

Greg Trasuk. 

Sent from my BlackBerry 10 smartphone. 
  Original Message   
From: Peter 
Sent: Saturday, January 9, 2016 5:43 PM 
To: dev@river.apache.org 
Reply To: dev@river.apache.org 
Subject: Re: River - 3.0.0 Release candidate 

Greg, 

If you want to remedy these issues for me, I can regenerate the release 
artifacts. 

Sent from my Samsung device. 
  
  Include original message 
 Original message  
From: Greg Trasuk <tras...@stratuscom.com> 
Sent: 10/01/2016 06:16:09 am 
To: dev@river.apache.org 
Subject: Re: River - 3.0.0 Release candidate 

- I also though we had agreed to take the ‘examples’ folder out of the JTSK.  

Cheers,  

Greg   

> On Jan 9, 2016, at 3:05 PM, Greg Trasuk <tras...@stratuscom.com> wrote:  
>   
>   
> I’ve only looked at the ‘apache-river-3.0.0.tar.gz’ archive.  A few issues…  
>   
> - we can’t have jar files in the source distribution.  Which means we have a 
>problem with ‘dep-libs’.  You could either setup a separate download for 
>developers to retrieve, or just give a list of the libraries that are needed.  
>What I’d recommend is to modify the build script to use Apache Ivy to go get 
>the requisite libraries at build time.  See the 2.2 branch for an example on 
>how to do this.  
> - as above for ‘test/lib’  
> - The ‘tar_release_test’ folder should be removed  
> - There is a “LICENSE” and a “LICENSE.txt” file in the root of the 
>distribution.  They’re identical - delete LICENSE.txt  
> - Same with NOTICE and NOTICE.txt.  
> - Both of the above will need to be reviewed when the jar files have been 
>sorted out.  Also, we may need a different LICENSE and NOTICE file for the 
>binary convenience artifacts.  
> - ‘doap-river.rdf’ is not really specific to the 3.0.0 release, so it 
>shouldn’t be in the release artifact  
> - ‘build.properties’ doesn’t have a license header.  
> - I’d remove the ‘nbproject’ folder myself - the project shouldn’t be 
>dependent on the IDE.  Although we might want to include instructions on how 
>to open it in an IDE.  
> - I could be wrong on this, but I think the current recommendation is to not 
>include a “KEYS” file, but for the release manager to register his/her keys on 
>‘id.apache.org’.  
>   
> Cheers,  
>   
> Greg Trasuk  
>   
>> On Jan 8, 2016, at 6:56 AM, Peter Firmstone <peter.firmst...@zeus.net.au> 
>>wrote:  
>>   
>> The Apache River 3.0.0 Release candidate is available here:  
>>   
>> http://people.apache.org/~peter_firmstone/ 
>>   
>> Voting on this release will commence in 4 weeks, to allow time for people to 
>>check they can reproduce these artifacts and test their code and report back 
>>with any issues.  
>>   
>> The code is currently in trunk, this will be branched after the 4 week 
>>review period and Voting passes.  
>>   
>> See also http://www.apache.org/dev/release-publishing.html  
>>   
>> Regards,  
>>   
>> Peter.  
>   

Re: River - 3.0.0 Release candidate

[Gregg Wonderly]

Sorry for this ending up on the list, it was intended to be private discussion, 
I thought I had edited the To: list appropriately. 

Greg, I am not saying that you should not review the release candidate.  This 
ended up being a reply in this thread when it should not of.  I want and value  
your participation as one of the community.

The review is indeed needed, no question about that!  Jars in the source 
distribution as Apache policy, also has to be dealt with.

Again, please don’t consider this to be related to anything in this thread.  I 
want the community to function using the Apache process. That’s what will 
provide the best means for the community to function.

Gregg

> On Jan 9, 2016, at 2:22 PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> 
> 
> Gregg:
> 
> So, you’re saying I shouldn’t review the release candidate?  Sorry, but the 
> bit about “no jars in the source distribution” is Apache policy.  We can’t 
> release with the candidate we have.  This isn’t a technical quarrel.
> 
> Cheers,
> 
> Greg Trasuk
> 
>> On Jan 9, 2016, at 3:16 PM, Gregg Wonderly <ge...@cox.net> wrote:
>> 
>> I sent Greg Trasuk a private note asking him to cease and desist on public 
>> badgering and instead to just step back and let the community vote on what 
>> happens with River, as that is the process that is supposed to work.  I 
>> suggested that if he had a plan and members to vote that plan through, that 
>> he could have things however he wanted.  I really do not appreciate his 
>> attitude and lack of appreciation for the experience and expertise that 
>> others have which is different from his own.  I don’t want to badger or 
>> belittle him in any way.  But, we need to use this process and work through 
>> issues by using our brains and our experiences both.  The “web” as we know 
>> it, is “mobile code” just like Jini uses.  Javascript won, because it was 
>> controlled by the browser camp, not by Sun.  Applets were in the browser 
>> first, but the size of PCs memory and computational resources were no where 
>> near mature enough for Java to have won.  I know, I tried to deploy lots of 
>> Java in Applets and applications in that time, to the desktop, but there was 
>> just not enough money spent on desktop machines in the enterprises where my 
>> customers were.  I am, hopefully going to get back out of the .Net world and 
>> back into Java and Jini again, this coming year.  I am looking forward to 
>> that!
>> 
>> Gregg
>> 
>>> On Jan 8, 2016, at 5:56 AM, Peter Firmstone <peter.firmst...@zeus.net.au> 
>>> wrote:
>>> 
>>> The Apache River 3.0.0 Release candidate is available here:
>>> 
>>> http://people.apache.org/~peter_firmstone/
>>> 
>>> Voting on this release will commence in 4 weeks, to allow time for people 
>>> to check they can reproduce these artifacts and test their code and report 
>>> back with any issues.
>>> 
>>> The code is currently in trunk, this will be branched after the 4 week 
>>> review period and Voting passes.
>>> 
>>> See also http://www.apache.org/dev/release-publishing.html
>>> 
>>> Regards,
>>> 
>>> Peter.
>> 
> 

Re: River - 3.0.0 Release candidate

[Peter]

I tend to agree, unfortunately we're not allowed to release anything 
externally until after the release artifacts have been voted on.


On 10/01/2016 12:56 PM, Dan Rollo wrote:

Do we have a process for staging the river artifacts in the maven central 
staging repo? And/or where do the related “pom.xml” files live (or get 
generated)?

I tried to do some validation of the 3.0.0 jars using Dennis Reedy’s samples 
project on github, and ran into some dependency issues. Having staged 
artifacts/poms would clarify some dependency questions.

Thanks,
Dan



  On Jan 8, 2016, at 6:56 AM, Peter 
Firmstone<peter.firmst...@zeus.net.au<mailto:peter.firmst...@zeus.net.au>>  
wrote:

  The Apache River 3.0.0 Release candidate is available here:

http://people.apache.org/~peter_firmstone/<http://people.apache.org/~peter_firmstone/>

  Voting on this release will commence in 4 weeks, to allow time for people to 
check they can reproduce these artifacts and test their code and report back 
with any issues.

  The code is currently in trunk, this will be branched after the 4 week review 
period and Voting passes.

  See also 
http://www.apache.org/dev/release-publishing.html<http://www.apache.org/dev/release-publishing.html>

  Regards,

  Peter.

Re: Release 3.0, package rename and ServiceProxyAccessor

[Simon IJskes - QCG]

On 06-01-16 18:49, Simon IJskes - QCG wrote:

On 06-01-16 13:38, Peter wrote:

Your security analysis is too narrow, your thinking like a user, not
an attacker.

An attacker is not going to send you a proxy to load into a standalone
Classloader.  She has the choice of the entire classpath, not you and
not River, that's right it's the senders choice, not the receivers.

She's looking for vulnerable classes on your classpath.
ObjectInputStream will load the attackers instructions. There's no
protection domain on the  stack representing the attacker, the
attacker is looking to deserialize into privileged context, the
attacker wants AllPermission.  This all occurs before your remote
method call even returns.  Once the the attacker has privileges, she
can create her own URLClassLoader grant AllPermission to her
downloaded code, install her own security manager.


https://cwe.mitre.org/data/definitions/502.html


https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=27492407

Has a number of secure coding recomendations.

G.

--
QCG, Software development, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Release 3.0, package rename and ServiceProxyAccessor

[Simon IJskes - QCG]

On 06-01-16 13:38, Peter wrote:

Your security analysis is too narrow, your thinking like a user, not an 
attacker.

An attacker is not going to send you a proxy to load into a standalone 
Classloader.  She has the choice of the entire classpath, not you and not 
River, that's right it's the senders choice, not the receivers.

She's looking for vulnerable classes on your classpath.  ObjectInputStream will 
load the attackers instructions. There's no protection domain on the  stack 
representing the attacker, the attacker is looking to deserialize into 
privileged context, the attacker wants AllPermission.  This all occurs before 
your remote method call even returns.  Once the the attacker has privileges, 
she can create her own URLClassLoader grant AllPermission to her downloaded 
code, install her own security manager.


https://cwe.mitre.org/data/definitions/502.html


--
QCG, Software development, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Release 3.0, package rename and ServiceProxyAccessor

[Greg Trasuk]

-1

A few reasons;

- ProxyAccessor exists primarily to go along with the activation system, which 
is slated to be removed.  
- ServiceProxyAccessor goes with the ‘start’ package, that is an implementation 
detail that not all containers use
- Whether a service is implemented by a reflective proxy or a smart proxy is 
none of the client’s business, and the client code shouldn’t be coupled to the 
implementation of the service.
- Ideas that go “in a future version of River” ought to be fully fleshed out 
and discussed before we start implementing them.  In particular, this 
“bootstrap proxy” idea - I don’t intend to delve into it now, but I can’t help 
but wonder whether it’s better implemented using the existing ProxyPreparer 
mechanism, or some decoupling between the service item and its claimed 
interfaces.  Not to mention, the need for it hasn’t been established.  In any 
case, we shouldn’t implement things until we’ve talked about them.  We’ve 
agreed to be cautious about changing the public API.

Cheers,

Greg Trasuk

> On Jan 5, 2016, at 1:41 AM, Peter Firmstone <peter.firmst...@zeus.net.au> 
> wrote:
> 
> ServiceProxyAccesor is an interface in the start package, a similar interface 
> called ProxyAccessor exists in the net.jini.export package.
> 
> The difference between these two interfaces is the former returns a smart 
> proxy, which may not be a Remote object, while the latter returns the Remote 
> proxy which is a reflective proxy or remote proxy stub.
> 
> Often, the former contains the latter, where the former implements service 
> api, while the latter is used for remote communication with the service's 
> server.
> 
> In a future version of River,  ServiceProxyAccessor could be used by clients 
> to obtain the service proxy, from a bootstrap proxy, allowing authentication 
> to occur prior to codebase download and unmarshalling.  Think security and 
> delayed unmarshalling.
> 
> If this was to occur, we'd need to change the package for the 
> ServiceProxyAccessor interface, to net.jini.export. 
> 
> Seeing as we're about to change the package of ServiceProxyAccessor in the 
> 3.0 release, it would have less impact on downstream code if this change was 
> only made once.
> 
> If the security and performance improvements were not accepted, (I'm quite 
> confident that we will agree on a solution once the benefits can be 
> demonstrated) it still makes sense to move ServiceProxyAccessor to 
> net.jini.exporter due to their related use and functionality.
> 
> Should I proceed with a vote to move ServiceProxyAccessor to net.jiniexporter 
> now, prior to release, or should I leave it until River 3.1?
> 
> This wont cause a delay in the release process, but I'm happy to leave it if 
> anyone is concerned it will.
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>  

Re: Release 3.0, package rename and ServiceProxyAccessor

[Greg Trasuk]

> On Jan 5, 2016, at 10:51 PM, Peter  wrote:
> 
>  
> 
> ProxyPreparer in its current form is broken.  
> 
> Proxy preparation assumed that both the java sandbox and serialization are 
> secure, code is downloaded, static class initialisers and readObject methods 
> are executed on untrusted foreign code, you're POWNED by the attacker, only 
> then are invocation constraints applied, then the proxy provides the 
> bootstrap proxy, the service is authenticated, the bootstrap proxy provides 
> the TrustVerifier via a remote call and the TrustVerifier checks if the proxy 
> can be trusted, and finally method constraints are applied, oops, how can 
> that possibly work?!

Perhaps I’m misunderstanding something - As I understand it, a proxy is 
deserialized into a new, empty classloader - i.e. it begins with no 
permissions.  Permissions are only granted by the ProxyPrepare.prepareProxy(…) 
method after trust verification is performed.  Am I wrong about that?

> 
> 
> 
> The broken concept of TrustVerifier is no longer required, the process is 
> simplified and much more secure.  
> 
> All of the above becomes a ProxyVerifier and configuration concern; client 
> code doesn't need to be involved.
> 

It already is a ProxyPreparer and configuration concern.  The TrustVerifiers 
are automatically configured through manifest entries in the client library 
‘jar’ file.  All the client needs to do is instantiate a ProxyPreparer and call 
it on the proxy before using it.  In most cases, BasicProxyPreparer is fine, 
since it uses the manifest-configured TrustVerifiers (which would also be 
shipped in the client library).  Alternately, the service provider could 
provide an alternate ProxyPreparer implementation.  What’s the problem, 
exactly, that this more complex lookup procedure solves?

> This will require some backward compatible revisions to the lookup service, 
> that we'll need to discuss before implementing.
> 
> All this should be up for constructive discussion, when the time comes, lets 
> discuss each argument concisely, park some for later discussion, so we can 
> resolve any differences we have and make progress.
> 
> We also need to address httpmd insecurity, discuss whether to upgrade it, or 
> deprecate and replace with signed jar codebases.
> 
> The network is changing, we can't cling to ipv4 and NAT firewalls to provide 
> security.

I wish you’d stop making these unsupported straw-man assertions.  When has 
anyone ever said anything about clinging to ipv4?  As far as NAT firewalls, the 
design is clear - Jini doesn’t cross NAT firewalls.

> 
> Activation removal has been voted on for 2.2, not 3.0, this is an 
> understandable decision from a maintence reduction persspective, considering 
> that 2.2 is an LTS and completely separate branch, that duplicates work.
> 

Personally, I voted to remove it entirely - we just decided to remove it in the 
next iteration of the 3.0 branch.

> It makes much less sense in 3.0, I've already performed the maintenance 
> required on Phoenix, I'm reluctant to throw that away just yet, perhaps it 
> still makes sense to remove support for jrmp activation, which will simplify 
> phoenix and make it portable to other jvm's, but why not retain jeri 
> activation, it's portable?  Sun jrmp activation was intended as a compatible 
> uprade away from rmid.
> 
> Users may not have noticed the recent vote to remove activation from 2.2, 
> some felt quite strongly about this in the past:
> 

That was discussed and voted on.  Do you have a problem accepting the 
community’s decision?

I’ll say it again, Peter - River on the Internet is not going to happen.  Stop 
trying to make it happen.  Roy is right about this - HTTP is all the protocol 
you’ll ever need for the Internet.  We’ve talked about this several times, and 
each time, the PMC has said “no”.  Fork the project and find a new community if 
that’s what you’re determined to work on.

Greg Trasuk

Release 3.0, package rename and ServiceProxyAccessor

[Peter Firmstone]

ServiceProxyAccesor is an interface in the start package, a similar interface 
called ProxyAccessor exists in the net.jini.export package.

The difference between these two interfaces is the former returns a smart 
proxy, which may not be a Remote object, while the latter returns the Remote 
proxy which is a reflective proxy or remote proxy stub.

Often, the former contains the latter, where the former implements service api, 
while the latter is used for remote communication with the service's server.

In a future version of River,  ServiceProxyAccessor could be used by clients to 
obtain the service proxy, from a bootstrap proxy, allowing authentication to 
occur prior to codebase download and unmarshalling.  Think security and delayed 
unmarshalling.

If this was to occur, we'd need to change the package for the 
ServiceProxyAccessor interface, to net.jini.export. 

Seeing as we're about to change the package of ServiceProxyAccessor in the 3.0 
release, it would have less impact on downstream code if this change was only 
made once.

If the security and performance improvements were not accepted, (I'm quite 
confident that we will agree on a solution once the benefits can be 
demonstrated) it still makes sense to move ServiceProxyAccessor to 
net.jini.exporter due to their related use and functionality.

Should I proceed with a vote to move ServiceProxyAccessor to net.jiniexporter 
now, prior to release, or should I leave it until River 3.1?

This wont cause a delay in the release process, but I'm happy to leave it if 
anyone is concerned it will.

Regards,

Peter.

Sent from my Samsung device.
 

Re: x509 certificates for jarsigner to sign maven repos release jar file artifacts

[Greg Trasuk]

(Pulling this over to river-dev, since it’s not really a members@ question - 
please reply there)

Peter:

I don’t recall seeing any requests for signed jars - could you refresh my 
memory?

For downloadable jars, that’s what the md5 mechanism is for (although I have to 
admit I’ve never used it).   It’s supposed to make sure that the signature 
matches what the exporting party says it is.

As far as downloading jars from Maven Central, they only go in to Maven Central 
if they’re PGP-signed.  If you have a look in the the svn repo (it’s in the 2.2 
branch and the qa_refactor branch, but the 2.2. branch is probably more 
up-to-date), you’ll see ‘roll-release.sh’ which generates the signatures on the 
release artifacts, and ‘poms/deploy_river.groovy’, which uses Maven to deploy 
signed artifacts to the Apache staging repository, from which we eventually 
release to Maven Central.

Cheers,

Greg Trasuk

> On Dec 30, 2015, at 5:38 AM, Peter Firmstone <peter.firmst...@zeus.net.au> 
> wrote:
> 
> Thanks Nic,
> 
> We've had one user request we sign Maven artifacts.  
> 
> River 3.0 isn't quite internet ready, in that there's no support for ipv6 
> discovery at this stage and java serialization is insecure, and River's 
> security is based on the assumption that java serialization and the sandbox 
> is secure.
> 
> Current message digests for proxy codebases are based on md5 and sha1 based.  
> Signed jar files would provide a more secure alternative, when combined with 
> DownloadPermission, however users could sign our proxy codebases themselves.
> 
> I have a prototype that solves java serialization and lookup service security 
> issues, similar to http input validation and I'm working on ipv6 discovery.
> 
> We could delay signing artifacts until a following release.
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>  Original message 
> From: Niclas Hedhman <hedh...@gmail.com>
> Sent: 30/12/2015 11:42:36 am
> To: Apache Members <memb...@apache.org>
> Cc: Peter Firmstone <peter.firmst...@zeus.net.au>
> Subject: Re: x509 certificates for jarsigner to sign maven repos release jar 
> file artifacts
> 
> I don't think Peter needs this, but perhaps someone else reading;
> 
> When Uwe mentions "don't use it willy-nilly, because it costs ASF money", it 
> is important to also point out "do whatever you can to make your projects 
> more secure, even if it costs ASF a bit of money".
> 
> We spend quite a lot on keeping our systems running to serve the public, but 
> our primary purpose is to produce software, and we should try to minimize the 
> security risks associated with that software to the greatest extent possible. 
> So from my PoV, if it takes 10s of thousands of dollars to do this, it should 
> still be done. And at some point, we could re-negotiate a ceiling price with 
> the supplier.
> 
> Cheers
> Niclas
> 
> On Dec 30, 2015 09:33, "Uwe Schindler" <u...@thetaphi.de> wrote:
> Hi,
> 
> Code signing is supported by Apache infrastructure. But it should only be 
> used where needed, not just for any JAR. Use cases are webstart applications 
> or other stuff using java's security manager that need to validate code 
> authenticity, or signing Windows exe files for starting services. Because it 
> costs money.
> 
> https://blogs.apache.org/infra/entry/code_signing_service_now_available
> 
> Uwe
> 
> Am 30. Dezember 2015 00:34:05 MEZ, schrieb Peter Firmstone 
> <peter.firmst...@zeus.net.au>:
>  The current process for releases is to generate signatures for artifacts 
> using gnupgp and pgp developer certificates.
> 
> For jar files that will be uploaded to Maven, is there an apache process to 
> sign jar file release artifacts using X509 certificates?
> 
> Is there a certificate authority that will sign a certificate for an apache 
> project?  Or is it possible the apache.org website certificate could be used 
> to sign jar files?
> 
> Thanks,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
> 
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
> 

Re: x509 certificates for jarsigner to sign maven repos release jar file artifacts

[Peter]

Thanks Greg,

I'll have a look for you, if you haven't seen the request on river dev, it may 
have come to me directly.

jarsigner doesn't support pgp, I'll have a look at your script.

MD5 and SHA1 are no longer secure, we need to update our security protocols.

Regards,

Peter.



Sent from my Samsung device.
 
  Include original message
 Original message 
From: Greg Trasuk <tras...@trasuk.com>
Sent: 31/12/2015 03:29:38 am
To: dev@river.apache.org; Peter <j...@zeus.net.au>
Cc: Apache Members <memb...@apache.org>
Subject: Re: x509 certificates for jarsigner to sign maven repos release jar 
file artifacts


(Pulling this over to river-dev, since it’s not really a members@ question - 
please reply there) 

Peter: 

I don’t recall seeing any requests for signed jars - could you refresh my 
memory? 

For downloadable jars, that’s what the md5 mechanism is for (although I have to 
admit I’ve never used it).   It’s supposed to make sure that the signature 
matches what the exporting party says it is. 

As far as downloading jars from Maven Central, they only go in to Maven Central 
if they’re PGP-signed.  If you have a look in the the svn repo (it’s in the 2.2 
branch and the qa_refactor branch, but the 2.2. branch is probably more 
up-to-date), you’ll see ‘roll-release.sh’ which generates the signatures on the 
release artifacts, and ‘poms/deploy_river.groovy’, which uses Maven to deploy 
signed artifacts to the Apache staging repository, from which we eventually 
release to Maven Central. 

Cheers, 

Greg Trasuk 

> On Dec 30, 2015, at 5:38 AM, Peter Firmstone <peter.firmst...@zeus.net.au> 
>wrote: 
>  
> Thanks Nic, 
>  
> We've had one user request we sign Maven artifacts.   
>  
> River 3.0 isn't quite internet ready, in that there's no support for ipv6 
>discovery at this stage and java serialization is insecure, and River's 
>security is based on the assumption that java serialization and the sandbox is 
>secure. 
>  
> Current message digests for proxy codebases are based on md5 and sha1 based.  
>Signed jar files would provide a more secure alternative, when combined with 
>DownloadPermission, however users could sign our proxy codebases themselves. 
>  
> I have a prototype that solves java serialization and lookup service security 
>issues, similar to http input validation and I'm working on ipv6 discovery. 
>  
> We could delay signing artifacts until a following release. 
>  
> Regards, 
>  
> Peter. 
>  
> Sent from my Samsung device. 
>   
>  Original message  
> From: Niclas Hedhman <hedh...@gmail.com> 
> Sent: 30/12/2015 11:42:36 am 
> To: Apache Members <memb...@apache.org> 
> Cc: Peter Firmstone <peter.firmst...@zeus.net.au> 
> Subject: Re: x509 certificates for jarsigner to sign maven repos release jar 
>file artifacts 
>  
> I don't think Peter needs this, but perhaps someone else reading; 
>  
> When Uwe mentions "don't use it willy-nilly, because it costs ASF money", it 
>is important to also point out "do whatever you can to make your projects more 
>secure, even if it costs ASF a bit of money". 
>  
> We spend quite a lot on keeping our systems running to serve the public, but 
>our primary purpose is to produce software, and we should try to minimize the 
>security risks associated with that software to the greatest extent possible. 
>So from my PoV, if it takes 10s of thousands of dollars to do this, it should 
>still be done. And at some point, we could re-negotiate a ceiling price with 
>the supplier. 
>  
> Cheers 
> Niclas 
>  
> On Dec 30, 2015 09:33, "Uwe Schindler" <u...@thetaphi.de> wrote: 
> Hi, 
>  
> Code signing is supported by Apache infrastructure. But it should only be 
>used where needed, not just for any JAR. Use cases are webstart applications 
>or other stuff using java's security manager that need to validate code 
>authenticity, or signing Windows exe files for starting services. Because it 
>costs money. 
>  
> https://blogs.apache.org/infra/entry/code_signing_service_now_available 
>  
> Uwe 
>  
> Am 30. Dezember 2015 00:34:05 MEZ, schrieb Peter Firmstone 
><peter.firmst...@zeus.net.au>: 
>  The current process for releases is to generate signatures for artifacts 
>using gnupgp and pgp developer certificates. 
>  
> For jar files that will be uploaded to Maven, is there an apache process to 
>sign jar file release artifacts using X509 certificates? 
>  
> Is there a certificate authority that will sign a certificate for an apache 
>project?  Or is it possible the apache.org website certificate could be used 
>to sign jar files? 
>  
> Thanks, 
>  
> Peter. 
>  
> Sent from my Samsung device. 
>   
>  
> -- 
> Uwe Schindler 
> H.-H.-Meier-Allee 63, 28213 Bremen 
> http://www.thetaphi.de 
>  

Re: committer keys for release

[Peter]

No harm creating keys, I'm not currently in the web of trust either, due to my 
location.

If you do append a key, you're more likely to be able to have your key signed 
by a committer who is in the web of trust than I, due to your location.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 22/12/2015 02:37:31 pm
To: dev@river.apache.org
Subject: Re: committer keys for release

I do not currently have keys, and this is not a good time to try to get  
a key into the web of trust. My understanding is that keys from people  
other than the release manager are optional. 

On 12/21/2015 7:29 PM, Peter Firmstone wrote: 
> Committers who have contributed to River, please append your pgp public key 
>to the KEYS file in the trunk directory in preparation for release. 
> 
> Thank you, 
> 
> Peter. 
> 
> Sent from my Samsung device. 
> 
> 

River 3.0 release

[Peter Firmstone]

There's new api in org.apache.river.api.lookup and org.apache.river.api.util 
I'd like to remove before releasing.

This relates to
StreamServiceRegistrar, it doesn't have any implementation yet, also only 
net.jini.* is agreed upon as api.

I think the additional lookup method would be better if it was included with an 
implementation in River 3.1, perhaps as a java 8 default method in 
ServiceRegistrar for compatibility reasons (doesn't require an additional 
interface).

For now unless there's any disagreement I'll remove them before releasing.

This will be our best release yet, with over 200 less bugs than River 2.2.1, 
over 200 more unit tests and significant performance improvements while 
reducing our maintenance debt.

Although I've been mostly responsible for fixing JMM non compliance, this works 
is a result of the combined efforts of a number of committers and external 
contributors.

In following releases, I look forward to working with you, fixing performance 
issues identified by the original Jini team, documented on Jira, fixing 
security vulnerabilities, the modular build and support for ipv6 discovery.

Regards,

Peter.

eSent from my Samsung device.
 

committer keys for release

[Peter Firmstone]

Committers who have contributed to River, please append your pgp public key to 
the KEYS file in the trunk directory in preparation for release.

Thank you,

Peter.
 
Sent from my Samsung device.
 

Re: committer keys for release

[Patricia Shanahan]

I do not currently have keys, and this is not a good time to try to get 
a key into the web of trust. My understanding is that keys from people 
other than the release manager are optional.


On 12/21/2015 7:29 PM, Peter Firmstone wrote:

Committers who have contributed to River, please append your pgp public key to 
the KEYS file in the trunk directory in preparation for release.

Thank you,

Peter.

Sent from my Samsung device.

Re: Preparation for Release - one more volunteer needed

[Patricia Shanahan]

I have some config files modified. Would you like me to check files in 
batch-by-batch, or wait until I have a lot of them done?


I got a "Jenkins build is still unstable" when I checked in the update 
to the RAT script. When do you expect that to go away?


On 12/9/2015 4:15 PM, Peter wrote:

Yes, check them in, I'll test them, the integration tests are running again 
now, so we'll quickly identify any problems.

Peter.

Sent from my Samsung device.
   Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 10/12/2015 12:00:10 am
To: dev@river.apache.org
Subject: Re: Preparation for Release - one more volunteer needed

Note that this is not quite a release candidate. I'm working on fixing
some missing license statements in scripts and configuration files.

I am also working on getting together a build environment, having not
built River for some time.

Normally, I would wait for the script changes until I can build, so that
I can test what I am doing. In the current situation, would it be better
to do the changes, and check them in, without testing them?

Patricia

On 12/8/2015 4:25 PM, Peter wrote:

  Thanks Brian,

  Brad,

  The code is now in River's trunk branch.

  All com.sun.jini.* packages have changed to org.apache.river.*

  Some configuration options have changed since 2.2, ExecutorService has 
replaced TaskManager, where specified.

  Codebase grant's to URL's in policy files now by default, no longer resolve 
to ip addresses, this was done for two reasons:

  1. To reduce dns calls.
  2. To allow multiple codebase servers with different ip addresses to serve 
one domain name for increased redundancy or fail over.

  There's a system property that you can set if you need to revert to the 
previous behaviour.

  Interested to know how it goes.

  Regards,

  Peter.




  Sent from my Samsung device.
 Include original message
   Original message 
  From: Bryan Thompson <br...@systap.com>
  Sent: 09/12/2015 05:38:52 am
  To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee 
<be...@systap.com>
  Subject: Re: Preparation for Release - one more volunteer needed

  Peter,

  Brad (Cc) is working to put the River 3 candidate release into CI for our
  platform.  This will allow us to test it in the highly available
  replication cluster mode of the database.

  Thanks,
  Bryan

  
  Bryan Thompson
  Chief Scientist & Founder
  SYSTAP, LLC
  4501 Tower Road
  Greensboro, NC 27410
  br...@systap.com
  http://blazegraph.com
  http://blog.blazegraph.com

  Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
  graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
  APIs.  Blazegraph is now available with GPU acceleration using our disruptive
  technology to accelerate data-parallel graph analytics and graph query.

  CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
  for the sole use of the intended recipient(s) and are confidential or
  proprietary to SYSTAP. Any unauthorized review, use, disclosure,
  dissemination or copying of this email or its contents or attachments is
  prohibited. If you have received this communication in error, please notify
  the sender by reply email and permanently delete all copies of the email
  and its contents and attachments.

  On Tue, Dec 8, 2015 at 2:29 PM, Peter <j...@zeusnet.au> wrote:


Thanks Patricia,

We need at least three binding votes for release, at the very least we
need one more committer willing to assist with the release process

Any volunteers?  We cannot do it without you.

Regards,

Peter.

Sent from my Samsung device.
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 08/12/2015 01:54:08 pm
    To: dev@river.apache.org
Subject: Preparation for Release

This is probably unnecessary, but I wanted to make sure everyone
understands the requirements for casting binding votes in favor of a
release. See http://www.apache.org/legal/release-policy

In particular "Before casting +1 binding votes, individuals are REQUIRED
to download all signed source code packages onto their own hardware,
verify that they meet all requirements of ASF policy on releases as
described below, validate all cryptographic signatures, compile as
provided, and test the result on their own platform"

I am preparing for this by working on being able to build and test River
on one of my computers.

Patricia

Re: Preparation for Release - one more volunteer needed

[Peter]

Yes, check them in batch by batch please.

Jenkins appears to have some build env settings problems on some executor 
nodes.  This is unrelated to River, but is causing instability.

There are two known test failures, one junit MuxStartTimeoutTest the other is a 
qa test for reggie, MultihomedClientTest, the latter test seems to be having 
some issues establishing the network config.

So the only test river fails is MuxStartTimeoutTest.

The current default system property setting for 
org.apache.river.jeri.handshakeTimeout is 36.  But the javadoc states 
12 (2 minutes).

The test only waits 35000 milliseconds

We should probably change the mux timeout back to the javadoc default and 
change the test to suit.

The timeout was changed from 15 when contention was occurring on startLock 
during testing.  The contention has been fixed now,  so we can set the timeout 
back to default, the contention was caused by increased concurrency.

As for the test timing, it actually passes on my systems, but I was going to 
leave sorting the test failure for River 3.0.1

Regards,

Peter.

Sent from my Samsung device.
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 11/12/2015 10:06:05 am
To: dev@river.apache.org
Subject: Re: Preparation for Release - one more volunteer needed

I have some config files modified. Would you like me to check files in  
batch-by-batch, or wait until I have a lot of them done? 

I got a "Jenkins build is still unstable" when I checked in the update  
to the RAT script. When do you expect that to go away? 

On 12/9/2015 4:15 PM, Peter wrote: 
> Yes, check them in, I'll test them, the integration tests are running again 
>now, so we'll quickly identify any problems. 
> 
> Peter. 
> 
> Sent from my Samsung device. 
>Include original message 
>  Original message  
> From: Patricia Shanahan <p...@acm.org> 
> Sent: 10/12/2015 12:00:10 am 
> To: dev@river.apache.org 
> Subject: Re: Preparation for Release - one more volunteer needed 
> 
> Note that this is not quite a release candidate. I'm working on fixing 
> some missing license statements in scripts and configuration files. 
> 
> I am also working on getting together a build environment, having not 
> built River for some time. 
> 
> Normally, I would wait for the script changes until I can build, so that 
> I can test what I am doing. In the current situation, would it be better 
> to do the changes, and check them in, without testing them? 
> 
> Patricia 
> 
> On 12/8/2015 4:25 PM, Peter wrote: 
>>   Thanks Brian, 
>> 
>>   Brad, 
>> 
>>   The code is now in River's trunk branch. 
>> 
>>   All com.sun.jini.* packages have changed to org.apache.river.* 
>> 
>>   Some configuration options have changed since 2.2, ExecutorService has 
>>replaced TaskManager, where specified. 
>> 
>>   Codebase grant's to URL's in policy files now by default, no longer 
>>resolve to ip addresses, this was done for two reasons: 
>> 
>>   1. To reduce dns calls. 
>>   2. To allow multiple codebase servers with different ip addresses to serve 
>>one domain name for increased redundancy or fail over. 
>> 
>>   There's a system property that you can set if you need to revert to the 
>>previous behaviour. 
>> 
>>   Interested to know how it goes. 
>> 
>>   Regards, 
>> 
>>   Peter. 
>> 
>> 
>> 
>> 
>>   Sent from my Samsung device. 
>>  Include original message 
>>    Original message  
>>   From: Bryan Thompson <br...@systap.com> 
>>   Sent: 09/12/2015 05:38:52 am 
>>   To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee 
>><be...@systap.com> 
>>   Subject: Re: Preparation for Release - one more volunteer needed 
>> 
>>   Peter, 
>> 
>>   Brad (Cc) is working to put the River 3 candidate release into CI for our 
>>   platform.  This will allow us to test it in the highly available 
>>   replication cluster mode of the database. 
>> 
>>   Thanks, 
>>   Bryan 
>> 
>>    
>>   Bryan Thompson 
>>   Chief Scientist & Founder 
>>   SYSTAP, LLC 
>>   4501 Tower Road 
>>   Greensboro, NC 27410 
>>   br...@systap.com 
>>   http://blazegraph.com 
>>   http://blog.blazegraph.com 
>> 
>>   Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance 
>>   graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints 
>>   APIs.  Blazegraph is now available with GPU acceleration using our 
>>disruptive 
>>   technology to accelerate data-parallel graph analytics 

Re: Preparation for Release - one more volunteer needed

[Peter]

Ok, it would appear that original handshake timeout was 15 seconds, the timeout 
functionality was added at the same time as the test case.

I should probably change the timeout back to 15 seconds.

This still doesn't explain why the test also passes on my systems or jdk 8 on 
jenkins?

Regards,

Peter.

Sent from my Samsung device.
  Include original message
 Original message 
From: Peter <j...@zeus.net.au>
Sent: 11/12/2015 11:04:39 am
To: dev@river.apache.org <dev@river.apache.org>
Subject: Re: Preparation for Release - one more volunteer needed

Yes, check them in batch by batch please.

Jenkins appears to have some build env settings problems on some executor 
nodes.  This is unrelated to River, but is causing instability.

There are two known test failures, one junit MuxStartTimeoutTest the other is a 
qa test for reggie, MultihomedClientTest, the latter test seems to be having 
some issues establishing the network config.

So the only test river fails is MuxStartTimeoutTest.

The current default system property setting for 
org.apache.river.jeri.handshakeTimeout is 36.  But the javadoc states 
12 (2 minutes).

The test only waits 35000 milliseconds

We should probably change the mux timeout back to the javadoc default and 
change the test to suit.

The timeout was changed from 15 when contention was occurring on startLock 
during testing.  The contention has been fixed now,  so we can set the timeout 
back to default, the contention was caused by increased concurrency.

As for the test timing, it actually passes on my systems, but I was going to 
leave sorting the test failure for River 3.0.1

Regards,

Peter.

Sent from my Samsung device.
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 11/12/2015 10:06:05 am
To: dev@river.apache.org
Subject: Re: Preparation for Release - one more volunteer needed

I have some config files modified. Would you like me to check files in  
batch-by-batch, or wait until I have a lot of them done? 

I got a "Jenkins build is still unstable" when I checked in the update  
to the RAT script. When do you expect that to go away? 

On 12/9/2015 4:15 PM, Peter wrote: 
> Yes, check them in, I'll test them, the integration tests are running again 
>now, so we'll quickly identify any problems. 
> 
> Peter. 
> 
> Sent from my Samsung device. 
>Include original message 
>  Original message  
> From: Patricia Shanahan <p...@acm.org> 
> Sent: 10/12/2015 12:00:10 am 
> To: dev@river.apache.org 
> Subject: Re: Preparation for Release - one more volunteer needed 
> 
> Note that this is not quite a release candidate. I'm working on fixing 
> some missing license statements in scripts and configuration files. 
> 
> I am also working on getting together a build environment, having not 
> built River for some time. 
> 
> Normally, I would wait for the script changes until I can build, so that 
> I can test what I am doing. In the current situation, would it be better 
> to do the changes, and check them in, without testing them? 
> 
> Patricia 
> 
> On 12/8/2015 4:25 PM, Peter wrote: 
>>   Thanks Brian, 
>> 
>>   Brad, 
>> 
>>   The code is now in River's trunk branch. 
>> 
>>   All com.sun.jini.* packages have changed to org.apache.river.* 
>> 
>>   Some configuration options have changed since 2.2, ExecutorService has 
>>replaced TaskManager, where specified. 
>> 
>>   Codebase grant's to URL's in policy files now by default, no longer 
>>resolve to ip addresses, this was done for two reasons: 
>> 
>>   1. To reduce dns calls. 
>>   2. To allow multiple codebase servers with different ip addresses to serve 
>>one domain name for increased redundancy or fail over. 
>> 
>>   There's a system property that you can set if you need to revert to the 
>>previous behaviour. 
>> 
>>   Interested to know how it goes. 
>> 
>>   Regards, 
>> 
>>   Peter. 
>> 
>> 
>> 
>> 
>>   Sent from my Samsung device. 
>>  Include original message 
>>    Original message  
>>   From: Bryan Thompson <br...@systap.com> 
>>   Sent: 09/12/2015 05:38:52 am 
>>   To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee 
>><be...@systap.com> 
>>   Subject: Re: Preparation for Release - one more volunteer needed 
>> 
>>   Peter, 
>> 
>>   Brad (Cc) is working to put the River 3 candidate release into CI for our 
>>   platform.  This will allow us to test it in the highly available 
>>   replication cluster mode of the database. 
>> 
>>   Thanks, 
>>   Bryan 
>> 
>>    
>>   Bryan

Re: Preparation for Release - one more volunteer needed

[Brad Bebee]

Peter,

OK -- thanks.  We'll put up a blog post with our experience on it and post
to the list.

Cheers, --Brad

On Tue, Dec 8, 2015 at 7:25 PM, Peter <j...@zeus.net.au> wrote:

> Thanks Brian,
>
> Brad,
>
> The code is now in River's trunk branch.
>
> All com.sun.jini.* packages have changed to org.apache.river.*
>
> Some configuration options have changed since 2.2, ExecutorService has
> replaced TaskManager, where specified.
>
> Codebase grant's to URL's in policy files now by default, no longer
> resolve to ip addresses, this was done for two reasons:
>
> 1. To reduce dns calls.
> 2. To allow multiple codebase servers with different ip addresses to serve
> one domain name for increased redundancy or fail over.
>
> There's a system property that you can set if you need to revert to the
> previous behaviour
>
> Interested to know how it goes.
>
> Regards,
>
> Peter.
>
>
>
>
> Sent from my Samsung device.
>  Original message 
> From: Bryan Thompson <br...@systap.com>
> Sent: 09/12/2015 05:38:52 am
> To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee <
> be...@systap.com>
> Subject: Re: Preparation for Release - one more volunteer needed
>
> Peter,
>
> Brad (Cc) is working to put the River 3 candidate release into CI for our
> platform.  This will allow us to test it in the highly available
> replication cluster mode of the database.
>
> Thanks,
> Bryan
>
> 
> Bryan Thompson
> Chief Scientist & Founder
> SYSTAP, LLC
> 4501 Tower Road
> Greensboro, NC 27410
> br...@systap.com
> http://blazegraph.com
> http://blog.blazegraph.com
>
> Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
> graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
> APIs.  Blazegraph is now available with GPU acceleration using our disruptive
>
> technology to accelerate data-parallel graph analytics and graph query.
>
> CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
> for the sole use of the intended recipient(s) and are confidential or
> proprietary to SYSTAP. Any unauthorized review, use, disclosure,
> dissemination or copying of this email or its contents or attachments is
> prohibited. If you have received this communication in error, please notify
>
> the sender by reply email and permanently delete all copies of the email
> and its contents and attachments.
>
> On Tue, Dec 8, 2015 at 2:29 PM, Peter <j...@zeus.net.au> wrote:
>
> > Thanks Patricia,
> >
> > We need at least three binding votes for release, at the very least we
> > need one more committer willing to assist with the release process..
> >
> > Any volunteers?  We cannot do it without you.
> >
> > Regards,
> >
> > Peter.
> >
> > Sent from my Samsung device.
> >   Include original message
> >  Original message 
> > From: Patricia Shanahan <p...@acm.org>
> > Sent: 08/12/2015 01:54:08 pm
> > To: dev@river.apache.org
> > Subject: Preparation for Release
> >
> > This is probably unnecessary, but I wanted to make sure everyone
> > understands the requirements for casting binding votes in favor of a
> > release. See http://www.apache.org/legal/release-policy
> >
> > In particular "Before casting +1 binding votes, individuals are REQUIRED
> > to download all signed source code packages onto their own hardware,
> > verify that they meet all requirements of ASF policy on releases as
> > described below, validate all cryptographic signatures, compile as
> > provided, and test the result on their own platform."
> >
> > I am preparing for this by working on being able to build and test River
> > on one of my computers.
> >
> > Patricia
> >
> >
>
>


-- 
___
Brad Bebee
CEO, Managing Partner
SYSTAP, LLC
e:  be...@systap.com
m: 202.642.7961
f:  571.367.5000
w:  www.blazegraph.com

Blazegraph™ <http://www.blazegraph.com> is our ultra high-performance graph
database that supports both RDF/SPARQL and Tinkerpop/Blueprints APIs.
Mapgraph™ <http://www.systap.com/mapgraph> is our disruptive new technology
to use GPUs to accelerate data-parallel graph analytics.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP, LLC.  Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

Re: Preparation for Release - one more volunteer needed

[Bryan Thompson]

Peter,

Brad (Cc) is working to put the River 3 candidate release into CI for our
platform.  This will allow us to test it in the highly available
replication cluster mode of the database.

Thanks,
Bryan


Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.blazegraph.com

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Tue, Dec 8, 2015 at 2:29 PM, Peter <j...@zeus.net.au> wrote:

> Thanks Patricia,
>
> We need at least three binding votes for release, at the very least we
> need one more committer willing to assist with the release process.
>
> Any volunteers?  We cannot do it without you.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>   Include original message
>  Original message 
> From: Patricia Shanahan <p...@acm.org>
> Sent: 08/12/2015 01:54:08 pm
> To: dev@river.apache.org
> Subject: Preparation for Release
>
> This is probably unnecessary, but I wanted to make sure everyone
> understands the requirements for casting binding votes in favor of a
> release. See http://www.apache.org/legal/release-policy
>
> In particular "Before casting +1 binding votes, individuals are REQUIRED
> to download all signed source code packages onto their own hardware,
> verify that they meet all requirements of ASF policy on releases as
> described below, validate all cryptographic signatures, compile as
> provided, and test the result on their own platform."
>
> I am preparing for this by working on being able to build and test River
> on one of my computers.
>
> Patricia
>
>

Re: Preparation for Release - one more volunteer needed

[Greg Trasuk]

When there’s a release package generated, I’ll review it and hopefully add my 
‘+1’.

Greg.


> On Dec 8, 2015, at 2:29 PM, Peter <j...@zeus.net.au> wrote:
> 
> Thanks Patricia,
> 
> We need at least three binding votes for release, at the very least we need 
> one more committer willing to assist with the release process.
> 
> Any volunteers?  We cannot do it without you.
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>   Include original message
>  Original message 
> From: Patricia Shanahan <p...@acm.org>
> Sent: 08/12/2015 01:54:08 pm
> To: dev@river.apache.org
> Subject: Preparation for Release
> 
> This is probably unnecessary, but I wanted to make sure everyone  
> understands the requirements for casting binding votes in favor of a  
> release. See http://www.apache.org/legal/release-policy 
> 
> In particular "Before casting +1 binding votes, individuals are REQUIRED  
> to download all signed source code packages onto their own hardware,  
> verify that they meet all requirements of ASF policy on releases as  
> described below, validate all cryptographic signatures, compile as  
> provided, and test the result on their own platform." 
> 
> I am preparing for this by working on being able to build and test River  
> on one of my computers. 
> 
> Patricia 
> 

Re: Preparation for Release - one more volunteer needed

[Bryan Thompson]

Can someone point me to the specific version that we should test?  Is this
just trunk?

Thanks,
Bryan


Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.blazegraph.com

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Tue, Dec 8, 2015 at 2:36 PM, Greg Trasuk <tras...@stratuscom.com> wrote:

>
> When there’s a release package generated, I’ll review it and hopefully add
> my ‘+1’.
>
> Greg.
>
>
> > On Dec 8, 2015, at 2:29 PM, Peter <j...@zeus.net.au> wrote:
> >
> > Thanks Patricia,
> >
> > We need at least three binding votes for release, at the very least we
> need one more committer willing to assist with the release process.
> >
> > Any volunteers?  We cannot do it without you.
> >
> > Regards,
> >
> > Peter.
> >
> > Sent from my Samsung device.
> >   Include original message
> >  Original message ----
> > From: Patricia Shanahan <p...@acm.org>
> > Sent: 08/12/2015 01:54:08 pm
> > To: dev@river.apache.org
> > Subject: Preparation for Release
> >
> > This is probably unnecessary, but I wanted to make sure everyone
> > understands the requirements for casting binding votes in favor of a
> > release. See http://www.apache.org/legal/release-policy
> >
> > In particular "Before casting +1 binding votes, individuals are REQUIRED
> > to download all signed source code packages onto their own hardware,
> > verify that they meet all requirements of ASF policy on releases as
> > described below, validate all cryptographic signatures, compile as
> > provided, and test the result on their own platform."
> >
> > I am preparing for this by working on being able to build and test River
> > on one of my computers.
> >
> > Patricia
> >
>
>

Re: Preparation for Release - one more volunteer needed

[Peter]

Thanks Brian,

Brad,

The code is now in River's trunk branch.

All com.sun.jini.* packages have changed to org.apache.river.*

Some configuration options have changed since 2.2, ExecutorService has replaced 
TaskManager, where specified.

Codebase grant's to URL's in policy files now by default, no longer resolve to 
ip addresses, this was done for two reasons:

1. To reduce dns calls.
2. To allow multiple codebase servers with different ip addresses to serve one 
domain name for increased redundancy or fail over. 

There's a system property that you can set if you need to revert to the 
previous behaviour.

Interested to know how it goes.

Regards,

Peter.




Sent from my Samsung device.
  Include original message
 Original message 
From: Bryan Thompson <br...@systap.com>
Sent: 09/12/2015 05:38:52 am
To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee <be...@systap.com>
Subject: Re: Preparation for Release - one more volunteer needed

Peter, 

Brad (Cc) is working to put the River 3 candidate release into CI for our 
platform.  This will allow us to test it in the highly available 
replication cluster mode of the database. 

Thanks, 
Bryan 

 
Bryan Thompson 
Chief Scientist & Founder 
SYSTAP, LLC 
4501 Tower Road 
Greensboro, NC 27410 
br...@systap.com 
http://blazegraph.com 
http://blog.blazegraph.com 

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance 
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints 
APIs.  Blazegraph is now available with GPU acceleration using our disruptive 
technology to accelerate data-parallel graph analytics and graph query. 

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are 
for the sole use of the intended recipient(s) and are confidential or 
proprietary to SYSTAP. Any unauthorized review, use, disclosure, 
dissemination or copying of this email or its contents or attachments is 
prohibited. If you have received this communication in error, please notify 
the sender by reply email and permanently delete all copies of the email 
and its contents and attachments. 

On Tue, Dec 8, 2015 at 2:29 PM, Peter <j...@zeus.net.au> wrote: 

> Thanks Patricia, 
> 
> We need at least three binding votes for release, at the very least we 
> need one more committer willing to assist with the release process. 
> 
> Any volunteers?  We cannot do it without you. 
> 
> Regards, 
> 
> Peter. 
> 
> Sent from my Samsung device. 
>   Include original message 
>  Original message  
> From: Patricia Shanahan <p...@acm.org> 
> Sent: 08/12/2015 01:54:08 pm 
> To: dev@river.apache.org 
> Subject: Preparation for Release 
> 
> This is probably unnecessary, but I wanted to make sure everyone 
> understands the requirements for casting binding votes in favor of a 
> release. See http://www.apache.org/legal/release-policy 
> 
> In particular "Before casting +1 binding votes, individuals are REQUIRED 
> to download all signed source code packages onto their own hardware, 
> verify that they meet all requirements of ASF policy on releases as 
> described below, validate all cryptographic signatures, compile as 
> provided, and test the result on their own platform." 
> 
> I am preparing for this by working on being able to build and test River 
> on one of my computers. 
> 
> Patricia 
> 
> 

Re: Preparation for Release - one more volunteer needed

[Peter]

Thanks Greg, much appreciated.

Sent from my Samsung device.
  Include original message
 Original message 
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 09/12/2015 05:36:31 am
To: dev@river.apache.org
Subject: Re: Preparation for Release - one more volunteer needed


When there’s a release package generated, I’ll review it and hopefully add my 
‘+1’. 

Greg. 


> On Dec 8, 2015, at 2:29 PM, Peter <j...@zeus.net.au> wrote: 
>  
> Thanks Patricia, 
>  
> We need at least three binding votes for release, at the very least we need 
>one more committer willing to assist with the release process. 
>  
> Any volunteers?  We cannot do it without you. 
>  
> Regards, 
>  
> Peter. 
>  
> Sent from my Samsung device. 
>   Include original message 
>  Original message  
> From: Patricia Shanahan <p...@acm.org> 
> Sent: 08/12/2015 01:54:08 pm 
> To: dev@river.apache.org 
> Subject: Preparation for Release 
>  
> This is probably unnecessary, but I wanted to make sure everyone   
> understands the requirements for casting binding votes in favor of a   
> release. See http://www.apache.org/legal/release-policy  
>  
> In particular "Before casting +1 binding votes, individuals are REQUIRED   
> to download all signed source code packages onto their own hardware,   
> verify that they meet all requirements of ASF policy on releases as   
> described below, validate all cryptographic signatures, compile as   
> provided, and test the result on their own platform."  
>  
> I am preparing for this by working on being able to build and test River   
> on one of my computers.  
>  
> Patricia  
>  

Preparation for Release

[Patricia Shanahan]

This is probably unnecessary, but I wanted to make sure everyone 
understands the requirements for casting binding votes in favor of a 
release. See http://www.apache.org/legal/release-policy


In particular "Before casting +1 binding votes, individuals are REQUIRED 
to download all signed source code packages onto their own hardware, 
verify that they meet all requirements of ASF policy on releases as 
described below, validate all cryptographic signatures, compile as 
provided, and test the result on their own platform."


I am preparing for this by working on being able to build and test River 
on one of my computers.


Patricia

Re: Release 3.0 merge into trunk

[Patricia Shanahan]

For moving to Git, see http://www.apache.org/dev/writable-git

Is the support provided sufficient? How do committers in general feel 
about moving River to Git? If it is a good idea, should we do it before 
Release 3.0? The alternative might be to rename the current SVN branch 
and release from there.


On 9/22/2015 4:31 AM, Bryan Thompson wrote:

SVN gets really messy for this sort of thing.  We wound not bringing a
project with a large delta back to the trunk because of these issues and
just did releases from branches after that.

What kind of support does Apache offer for switching to git?  That might be
easier.

Thanks,
Bryan

On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> wrote:


I think the next thing we need to do to make Release 3.0 a reality is to
merge it into the trunk.

If you agree, I would like opinions on the best way to go about it.
Ideally, we will preserve revision history for modules that have moved from
one directory/package to another.

Re: Release 3.0 merge into trunk

[Dawid Loubser]

I concur, all my work, and clients, have moved to git for the very same
reason.

Dawid


On 22/09/2015 13:31, Bryan Thompson wrote:
> SVN gets really messy for this sort of thing.  We wound not bringing a
> project with a large delta back to the trunk because of these issues and
> just did releases from branches after that.
>
> What kind of support does Apache offer for switching to git?  That might be
> easier.
>
> Thanks,
> Bryan
>
> On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> wrote:
>
>> I think the next thing we need to do to make Release 3.0 a reality is to
>> merge it into the trunk.
>>
>> If you agree, I would like opinions on the best way to go about it.
>> Ideally, we will preserve revision history for modules that have moved from
>> one directory/package to another.
>>

Re: Release 3.0 merge into trunk

[Bryan Thompson]

SVN gets really messy for this sort of thing.  We wound not bringing a
project with a large delta back to the trunk because of these issues and
just did releases from branches after that.

What kind of support does Apache offer for switching to git?  That might be
easier.

Thanks,
Bryan

On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> wrote:

> I think the next thing we need to do to make Release 3.0 a reality is to
> merge it into the trunk.
>
> If you agree, I would like opinions on the best way to go about it.
> Ideally, we will preserve revision history for modules that have moved from
> one directory/package to another.
>

Re: Release 3.0 merge into trunk

[Bryan Thompson]

+1 on moving to git.

+1 on doing this before a 3.0 release if we want to maintain history from
the trunk.


Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Tue, Sep 22, 2015 at 9:40 AM, Patricia Shanahan <p...@acm.org> wrote:

> For moving to Git, see http://www.apache.org/dev/writable-git
>
> Is the support provided sufficient? How do committers in general feel
> about moving River to Git? If it is a good idea, should we do it before
> Release 3.0? The alternative might be to rename the current SVN branch and
> release from there.
>
> On 9/22/2015 4:31 AM, Bryan Thompson wrote:
>
>> SVN gets really messy for this sort of thing.  We wound not bringing a
>> project with a large delta back to the trunk because of these issues and
>> just did releases from branches after that.
>>
>> What kind of support does Apache offer for switching to git?  That might
>> be
>> easier.
>>
>> Thanks,
>> Bryan
>>
>> On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> wrote:
>>
>> I think the next thing we need to do to make Release 3.0 a reality is to
>>> merge it into the trunk.
>>>
>>> If you agree, I would like opinions on the best way to go about it.
>>> Ideally, we will preserve revision history for modules that have moved
>>> from
>>> one directory/package to another.
>>>
>>>
>>

Re: Release 3.0 merge into trunk

[Greg Trasuk]

Apache’s Git support is just fine, and includes the ability to accept pull 
requests from Github, in a way that suits our need to ensure code provenance.  
The River Container work that I did was in the Git repository 
https://git-wip-us.apache.org/repos/asf/river-container.git.

I’m all for switching to git, but we need to actually discuss it and work out 
the desired workflow and project structure.  For instance, git doesn’t really 
encourage long-lived branches in a repository.  So, should we have separate 
repositories for the 2.2 and 3.0 branches?  Should we split out reggie, 
outrigger, JERI, etc into their own repositories/deliverables?  Should we have 
a set of repositories that reflect our release engineering processes?  i.e. a 
development repo, QA repo, release repo, etc?

Simply “switching to git” and then having one big canonical git repository that 
we use exactly the same way as we use svn doesn’t seem to offer many 
advantages, really.  If the argument is “but then we could take Github pull 
requests”, well, we can already do that with the git mirrors that are there 
already.

As far as “svn gets really messy for that kind of merge”, I’m not convinced 
that’s a tool issue - the fundamental problem is that the qa-refactor branch 
has diverged from the main branch for years without a release or much attention 
from anyone but Peter, blowing away the “develop on trunk” philosophy, and 
making “diffs” impossible to evaluate.  No tool is going to help that. We 
simply need to either go through it revision by revision, or just accept it as 
“the way forward”.  We’ve decided to accept it.

For now, the current “jtsk/trunk” is an unknown factor as much as 
“jtsk/skunk/qa-refactor-namespace/trunk”.  I’d suggest renaming “jtsk/trunk” to 
“jtsk/abandoned” or something, then rename 
“jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release from 
there.  That’s the path of least bikeshedding.

Cheers,

Greg Trasuk


> On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <p...@acm.org> wrote:
> 
> For moving to Git, see http://www.apache.org/dev/writable-git
> 
> Is the support provided sufficient? How do committers in general feel about 
> moving River to Git? If it is a good idea, should we do it before Release 
> 3.0? The alternative might be to rename the current SVN branch and release 
> from there.
> 
> On 9/22/2015 4:31 AM, Bryan Thompson wrote:
>> SVN gets really messy for this sort of thing.  We wound not bringing a
>> project with a large delta back to the trunk because of these issues and
>> just did releases from branches after that.
>> 
>> What kind of support does Apache offer for switching to git?  That might be
>> easier.
>> 
>> Thanks,
>> Bryan
>> 
>> On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> wrote:
>> 
>>> I think the next thing we need to do to make Release 3.0 a reality is to
>>> merge it into the trunk.
>>> 
>>> If you agree, I would like opinions on the best way to go about it.
>>> Ideally, we will preserve revision history for modules that have moved from
>>> one directory/package to another.
>>> 
>> 

Re: Release 3.0 merge into trunk

[Patricia Shanahan]

One concern I have with moving to Git before Release 3.0 is the tension 
between really thinking through the Git move and getting 3.0 out quickly.


On 9/22/2015 7:23 AM, Greg Trasuk wrote:

Apache’s Git support is just fine, and includes the ability to accept
pull requests from Github, in a way that suits our need to ensure
code provenance.  The River Container work that I did was in the Git
repository
https://git-wip-us.apache.org/repos/asf/river-container.git.

I’m all for switching to git, but we need to actually discuss it and
work out the desired workflow and project structure.  For instance,
git doesn’t really encourage long-lived branches in a repository.
So, should we have separate repositories for the 2.2 and 3.0
branches?  Should we split out reggie, outrigger, JERI, etc into
their own repositories/deliverables?  Should we have a set of
repositories that reflect our release engineering processes?  i.e. a
development repo, QA repo, release repo, etc?

Simply “switching to git” and then having one big canonical git
repository that we use exactly the same way as we use svn doesn’t
seem to offer many advantages, really.  If the argument is “but then
we could take Github pull requests”, well, we can already do that
with the git mirrors that are there already.

As far as “svn gets really messy for that kind of merge”, I’m not
convinced that’s a tool issue - the fundamental problem is that the
qa-refactor branch has diverged from the main branch for years
without a release or much attention from anyone but Peter, blowing
away the “develop on trunk” philosophy, and making “diffs” impossible
to evaluate.  No tool is going to help that. We simply need to either
go through it revision by revision, or just accept it as “the way
forward”.  We’ve decided to accept it.

For now, the current “jtsk/trunk” is an unknown factor as much as
“jtsk/skunk/qa-refactor-namespace/trunk”.  I’d suggest renaming
“jtsk/trunk” to “jtsk/abandoned” or something, then rename
“jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release
from there.  That’s the path of least bikeshedding.

Cheers,

Greg Trasuk



On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <p...@acm.org>
wrote:

For moving to Git, see http://www.apache.org/dev/writable-git

Is the support provided sufficient? How do committers in general
feel about moving River to Git? If it is a good idea, should we do
it before Release 3.0? The alternative might be to rename the
current SVN branch and release from there.

On 9/22/2015 4:31 AM, Bryan Thompson wrote:

SVN gets really messy for this sort of thing.  We wound not
bringing a project with a large delta back to the trunk because
of these issues and just did releases from branches after that.

What kind of support does Apache offer for switching to git?
That might be easier.

Thanks, Bryan

On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org>
wrote:


I think the next thing we need to do to make Release 3.0 a
reality is to merge it into the trunk.

If you agree, I would like opinions on the best way to go about
it. Ideally, we will preserve revision history for modules that
have moved from one directory/package to another.

Re: Release 3.0 merge into trunk

[Dennis Reedy]

> On Sep 22, 2015, at 1023AM, Greg Trasuk <tras...@stratuscom.com> wrote:
> 
> For now, the current “jtsk/trunk” is an unknown factor as much as 
> “jtsk/skunk/qa-refactor-namespace/trunk”.  I’d suggest renaming “jtsk/trunk” 
> to “jtsk/abandoned” or something, then rename 
> “jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release from 
> there.  That’s the path of least bikeshedding.
> 

In agreement with you Greg. I’m all for moving to Git, and as you point out 
there are questions involved with doing that. Lets not get distracted (love the 
bikeshedding comment!). FWIW, we could also just create river/trunk (as opposed 
to jtsk/trunk) and move jtsk/skunk/qa-refactor-namespace/trunk there.

Regards

Dennis

Re: Release 3.0 merge into trunk

[Greg Trasuk]

Just to be clear, I agree with Pat here - stay with svn for the initial 3.0 
release.  If someone’s up for the challenge, try to merge qa-refactor-namespace 
into trunk.  Alternately, just go ahead and replace trunk with 
qa-refactor-namespace, as I described below.

Greg Trasuk

> On Sep 22, 2015, at 10:52 AM, Patricia Shanahan <p...@acm.org> wrote:
> 
> One concern I have with moving to Git before Release 3.0 is the tension 
> between really thinking through the Git move and getting 3.0 out quickly.
> 
> On 9/22/2015 7:23 AM, Greg Trasuk wrote:
>> Apache’s Git support is just fine, and includes the ability to accept
>> pull requests from Github, in a way that suits our need to ensure
>> code provenance.  The River Container work that I did was in the Git
>> repository
>> https://git-wip-us.apache.org/repos/asf/river-container.git.
>> 
>> I’m all for switching to git, but we need to actually discuss it and
>> work out the desired workflow and project structure.  For instance,
>> git doesn’t really encourage long-lived branches in a repository.
>> So, should we have separate repositories for the 2.2 and 3.0
>> branches?  Should we split out reggie, outrigger, JERI, etc into
>> their own repositories/deliverables?  Should we have a set of
>> repositories that reflect our release engineering processes?  i.e. a
>> development repo, QA repo, release repo, etc?
>> 
>> Simply “switching to git” and then having one big canonical git
>> repository that we use exactly the same way as we use svn doesn’t
>> seem to offer many advantages, really.  If the argument is “but then
>> we could take Github pull requests”, well, we can already do that
>> with the git mirrors that are there already.
>> 
>> As far as “svn gets really messy for that kind of merge”, I’m not
>> convinced that’s a tool issue - the fundamental problem is that the
>> qa-refactor branch has diverged from the main branch for years
>> without a release or much attention from anyone but Peter, blowing
>> away the “develop on trunk” philosophy, and making “diffs” impossible
>> to evaluate.  No tool is going to help that. We simply need to either
>> go through it revision by revision, or just accept it as “the way
>> forward”.  We’ve decided to accept it.
>> 
>> For now, the current “jtsk/trunk” is an unknown factor as much as
>> “jtsk/skunk/qa-refactor-namespace/trunk”.  I’d suggest renaming
>> “jtsk/trunk” to “jtsk/abandoned” or something, then rename
>> “jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release
>> from there.  That’s the path of least bikeshedding.
>> 
>> Cheers,
>> 
>> Greg Trasuk
>> 
>> 
>>> On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <p...@acm.org>
>>> wrote:
>>> 
>>> For moving to Git, see http://www.apache.org/dev/writable-git
>>> 
>>> Is the support provided sufficient? How do committers in general
>>> feel about moving River to Git? If it is a good idea, should we do
>>> it before Release 3.0? The alternative might be to rename the
>>> current SVN branch and release from there.
>>> 
>>> On 9/22/2015 4:31 AM, Bryan Thompson wrote:
>>>> SVN gets really messy for this sort of thing.  We wound not
>>>> bringing a project with a large delta back to the trunk because
>>>> of these issues and just did releases from branches after that.
>>>> 
>>>> What kind of support does Apache offer for switching to git?
>>>> That might be easier.
>>>> 
>>>> Thanks, Bryan
>>>> 
>>>> On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org>
>>>> wrote:
>>>> 
>>>>> I think the next thing we need to do to make Release 3.0 a
>>>>> reality is to merge it into the trunk.
>>>>> 
>>>>> If you agree, I would like opinions on the best way to go about
>>>>> it. Ideally, we will preserve revision history for modules that
>>>>> have moved from one directory/package to another.
>>>>> 
>>>> 
>> 

Release 3.0 - is JIRA being used to plan releases?

[Bryan Thompson]

Hello,

I am trying to understand how the work remaining for releases is being
organized, specifically for the 3.0 release.  I've looked through JIRA [1]
and it does not appear to be very active.  It would be nice to have a clear
view of what needs to happen to get to a 3.0 release, whether in JIRA or a
wiki page. Is there someplace I should look for this?

Thanks,
Bryan

[1] https://issues.apache.org/jira/browse/RIVER/

Re: Release 3.0 - is JIRA being used to plan releases?

[Bryan Thompson]

So the release is currently blocked on the custard-apple dependency?

@peter If so, could we please get this committed into
org.apache.river.concurrent?

   - Deal with custard-apple dependency (either put it into River or
   publish to Maven Central)

Thanks,
Bryan


Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Wed, Sep 9, 2015 at 9:29 AM, Greg Trasuk <tras...@stratuscom.com> wrote:

> Given that it’s a “live” document, a Wiki page seems the most appropriate,
> so I created one…
> https://wiki.apache.org/river/TasksFor_3_0_Release
>
> Cheers,
>
> Greg Trasuk
>
> > On Sep 9, 2015, at 6:48 AM, Bryan Thompson <br...@systap.com> wrote:
> >
> > Hello,
> >
> > I am trying to understand how the work remaining for releases is being
> > organized, specifically for the 3.0 release.  I've looked through JIRA
> [1]
> > and it does not appear to be very active.  It would be nice to have a
> clear
> > view of what needs to happen to get to a 3.0 release, whether in JIRA or
> a
> > wiki page. Is there someplace I should look for this?
> >
> > Thanks,
> > Bryan
> >
> > [1] https://issues.apache.org/jira/browse/RIVER/
>
>

Re: Release 3.0 - is JIRA being used to plan releases?

[Greg Trasuk]

Given that it’s a “live” document, a Wiki page seems the most appropriate, so I 
created one…
https://wiki.apache.org/river/TasksFor_3_0_Release

Cheers,

Greg Trasuk

> On Sep 9, 2015, at 6:48 AM, Bryan Thompson <br...@systap.com> wrote:
> 
> Hello,
> 
> I am trying to understand how the work remaining for releases is being
> organized, specifically for the 3.0 release.  I've looked through JIRA [1]
> and it does not appear to be very active.  It would be nice to have a clear
> view of what needs to happen to get to a 3.0 release, whether in JIRA or a
> wiki page. Is there someplace I should look for this?
> 
> Thanks,
> Bryan
> 
> [1] https://issues.apache.org/jira/browse/RIVER/

Re: Release 3.0

[Dennis Reedy]

Peter,

I added the  tag for building the javadoc with Java 8, adding 
the -Xdoclint:none option to get past the huge amount of errors that Java 8’s 
doclint behavior generates.

Dennis

> On Sep 6, 2015, at 454PM, Peter <j...@zeus.net.au> wrote:
> 
> Not sure what's going on here, but I can't seem to build the documentation:
> 
> ant -f C:\\Users\\peter\\Documents\\NetBeansProjects\\River-3.0\\trunk all.doc
> doc-init:
> Copying 110 files to 
> C:\Users\peter\Documents\NetBeansProjects\River-3.0\trunk\doc
> javadoc-api:
> Created dir: C:\Users\peter\Documents\NetBeansProjects\River-3.0\trunk\doc\api
> C:\Users\peter\Documents\NetBeansProjects\River-3.0\trunk\build.xml:306: 
> javadoc doesn't support the nested "configuration" element.
> BUILD FAILED (total time: 1 second)
> 
> 
> 
> 
> On 6/09/2015 9:42 PM, Peter wrote:
>> On 5/09/2015 1:04 AM, Dennis Reedy wrote:
>>> Peter,
>>> 
>>> Recovered missing org.apache.river.test.support.* what is the status of 
>>> custard-apple artifact? This is a blocker for the release as well.
>>> 
>>> Dennis
>> 
>> Thanks Dennis,  I'm considering uploading it to Maven, otherwise I'll commit 
>> it to River, I wanted to make sure we're stable before modifying.
>> 
>> Turns out there were some unexpected test failures, but the fix was simple, 
>> will commit the fix shortly.
>> 
>> Test results:
>> 
>> -
>> -
>> 
>> 
>> # of tests started   = 1408
>> # of tests started   = 1408
>> # of tests completed = 1408
>> # of tests completed = 1408
>> # of tests skipped   = 50
>> # of tests skipped   = 50
>> # of tests passed= 1400
>> # of tests passed= 1400
>> # of tests failed= 8
>> # of tests failed= 8
>> 
>> 
>> -
>> -
>> 
>> Tests that failed:
>> 
>> org/apache/river/test/spec/discoverymanager/LocsDiscardUnreachable.td,\
>> org/apache/river/test/spec/io/marshalinputstream/LoadClass_VerifyCodebaseIntegrityTest.td,\
>>  
>> org/apache/river/test/spec/io/marshalinputstream/Resolve_VerifyCodebaseIntegrityTest.td,\
>>  
>> org/apache/river/test/spec/io/marshalledinstance/Get_ExceptionTest.td,\
>> org/apache/river/test/spec/io/marshalledinstance/Get_NormalTest.td,\
>> org/apache/river/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTestRenewCancel.td,\
>>  
>> org/apache/river/test/spec/javaspace/conformance/ReadTest.td
>> 
>>>> On Sep 3, 2015, at 1155PM, Peter<j...@zeus.net.au>  wrote:
>>>> 
>>>> Dennis,
>>>> 
>>>> We're still missing the following package from the qa test suite:
>>>> 
>>>> org.apache.river.test.support.*
>>>> 
>>>> I've added it locally and now the qa test suite is running, I'll report 
>>>> back my results.
>>>> 
>>>> Regards,
>>>> 
>>>> Peter.
>>> 
>> 
>> 
>