Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: River 2.2.2
From: Greg Trasuk <trasukg@stratuscom.com>
In-Reply-To: <BCCDAE89-7A91-41BC-B216-83345E095281@googlemail.com>
Date: Sun, 10 Nov 2013 17:38:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <969C410A-330D-4C6C-BB99-37718A77BF6B@stratuscom.com>
References: <1AEA99D9-60FF-4AFD-B924-076DF7C62063@trasuk.com>
 <6A510E07-3D41-44AB-B612-D11571E8A43B@gmail.com>
 <515CF0DE-22F1-4275-B010-7BFA8871334A@stratuscom.com>
 <60DE6348-D66B-4DF3-A84A-8C628075D460@gmail.com>
 <1380943816.26511.11.camel@Nokia-N900>
 <BCCDAE89-7A91-41BC-B216-83345E095281@googlemail.com>
To: dev@river.apache.org


We already have this, which has been there since the last release. =20

https://builds.apache.org/job/river-2.2-qa-jdk7/

It pulls from the 2.2 branch, which the 2.2.2 tag will be copied from.  =
Currently the build passes.

My understanding has always been that release artifacts need to be =
generated and signed on a machine that is under local control of the =
code signer (i.e. release manager, i.e. me for the 2.2.2 release).  As =
such, I don=92t think we should use the artifacts generated under =
Hudson, although the jars are certainly there if anyone wants to grab a =
snapshot.

Cheers,

Greg Trasuk.

https://builds.apache.org/job/river-2.2-qa-jdk7/


On Nov 10, 2013, at 3:16 PM, Jonathan Costers =
<jonathan.costers@gmail.com> wrote:

> Should we setup a Hudson build that pulls the 2.2.2 tag from SVN, =
tests it, generates reports and creates release artifacts?
>=20
> Op 5-okt.-2013, om 05:30 heeft Peter <jini@zeus.net.au> het volgende =
geschreven:
>=20
>> Sim also did some work based on Gregg's contribution, it's included =
in trunk, it was during this time that unrelated synchronization issues =
caused progress on this work to stall.  The design is quite elegant and =
flexible.
>>=20
>> Due to synchronization bugs causing test failures, I branched from an =
earlier trunk version that appeared stable.  I don't have access to =
hardware suitable for generating the failure conditions, so have been =
unable to continue working on these test failures.
>>=20
>> Despite being quite impressed by its elegance, there are some =
fundamental design flaws with Reggie's implementation regarding =
mutation, these only come to light are spending hours working through =
the code.=20
>>=20
>> I have considered rewriting Reggie, after an unsuccessful refactoring =
attempt.
>>=20
>> Regards,
>>=20
>> Peter.
>>=20
>> ----- Original message -----
>>> =
https://issues.apache.org/jira/browse/RIVER-336?page=3Dcom.atlassian.jira
>>>=20
>>> On Oct 3, 2013, at 1039AM, Greg Trasuk wrote:
>>>=20
>>>>=20
>>>> I'm having trouble finding a reference to that.   Do you happen to =
have
>>>> a link to email archives or a Jira issue?
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Greg.
>>>>=20
>>>> On 2013-10-02, at 8:15 PM, Dennis Reedy <dennis.reedy@gmail.com> =
wrote:
>>>>=20
>>>>> Hey Greg,
>>>>>=20
>>>>> The work that Gregg Wonderly championed with the RMIClassLoaderSpi
>>>>> would be one for me.
>>>>>=20
>>>>> Regards
>>>>>=20
>>>>> Dennis
>>>>>=20
>>>>> On Oct 2, 2013, at 546PM, Greg Trasuk wrote:
>>>>>=20
>>>>>> Hi all:
>>>>>>=20
>>>>>> I'm planning to propose a release for River 2.2.2 later this =
week,
>>>>>> based on the current state of the 2.2. branch.   The only change
>>>>>> from 2.2.1 is the addition of the JMX Entry classes, plus =
addition
>>>>>> of one more jar file to be added to Maven Central (jsk-policy.jar
>>>>>> if I remember correctly).
>>>>>>=20
>>>>>> Any objections or anything else that anyone wants to include in
>>>>>> the release?
>>>>>>=20
>>>>>>=20
>>>>>> Cheers,
>>>>>>=20
>>>>>> Greg Trasuk.
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20