[pool] apparently bad jar released ... ugh. help!

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[pool] apparently bad jar released ... ugh. help!

Phil Steitz
Somehow the 2.4 binary release jar that I just pushed to the mirrors
and maven central appears to be corrupted.  I don't know why / how
this happened but I get the following error when I build dbcp with
the new jar:

net/sourceforge/cobertura/coveragedata/TouchCollector
java.lang.NoClassDefFoundError:
net/sourceforge/cobertura/coveragedata/TouchCollector
    at
org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)

There is also a coberta.properties file in the manifest.  I have no
idea how it happened, but somehow maven seems to have created the
release jar from the coberta-instrumented classes or something.

The hashes and sigs on the jar are all good.

I would appreciate some help figuring out what is going on here and
also pushing out a quick fix release, as I suspect there is no way
we can pull back what I pushed out about 10 hours ago.

Sorry to have not caught this prior to pushing the binaries out and
thanks in advance for any help anyone can provide.

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Phil Steitz
OK, having calmed down a bit, I have a plan.  Feedback, objections,
general grumpiness welcome.

0. Open JIRA against 2.4
1. Revert web site update
2. Drop 2.4 artifacts from release area
3. Copy 2.4 release tag to make 2.4.1 release tag
4. Roll good artifacts from 2.4.1 tag. If these do not test out,
drop the tag; else
5. Push out 2.4.

I don't think we need a new vote for 2.4.1 because (unless there
actually is a problem with it) the source should be the same as 2.4.

I am about to get on a plane, so I won't get to 5 for at least 10
hours.  Please speak up if you have objections.

Phil


On 5/27/15 2:57 PM, Phil Steitz wrote:

> Somehow the 2.4 binary release jar that I just pushed to the mirrors
> and maven central appears to be corrupted.  I don't know why / how
> this happened but I get the following error when I build dbcp with
> the new jar:
>
> net/sourceforge/cobertura/coveragedata/TouchCollector
> java.lang.NoClassDefFoundError:
> net/sourceforge/cobertura/coveragedata/TouchCollector
>     at
> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>
> There is also a coberta.properties file in the manifest.  I have no
> idea how it happened, but somehow maven seems to have created the
> release jar from the coberta-instrumented classes or something.
>
> The hashes and sigs on the jar are all good.
>
> I would appreciate some help figuring out what is going on here and
> also pushing out a quick fix release, as I suspect there is no way
> we can pull back what I pushed out about 10 hours ago.
>
> Sorry to have not caught this prior to pushing the binaries out and
> thanks in advance for any help anyone can provide.
>
> Phil
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Dave Brosius-2
In reply to this post by Phil Steitz
Yeah, can't pull it back. Just need to push a new version.

On 05/27/2015 05:57 PM, Phil Steitz wrote:

> Somehow the 2.4 binary release jar that I just pushed to the mirrors
> and maven central appears to be corrupted.  I don't know why / how
> this happened but I get the following error when I build dbcp with
> the new jar:
>
> net/sourceforge/cobertura/coveragedata/TouchCollector
> java.lang.NoClassDefFoundError:
> net/sourceforge/cobertura/coveragedata/TouchCollector
>      at
> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>
> There is also a coberta.properties file in the manifest.  I have no
> idea how it happened, but somehow maven seems to have created the
> release jar from the coberta-instrumented classes or something.
>
> The hashes and sigs on the jar are all good.
>
> I would appreciate some help figuring out what is going on here and
> also pushing out a quick fix release, as I suspect there is no way
> we can pull back what I pushed out about 10 hours ago.
>
> Sorry to have not caught this prior to pushing the binaries out and
> thanks in advance for any help anyone can provide.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

garydgregory
In reply to this post by Phil Steitz
I think we need a vote no matter what for a new release. What we can do is make the vote 24 hours instead of 72.
Gary 

-------- Original message --------
From: Phil Steitz <[hidden email]>
Date: 05/27/2015  17:54  (GMT-08:00)
To: Commons Developers List <[hidden email]>
Subject: Re: [pool] apparently bad jar released ... ugh. help!

OK, having calmed down a bit, I have a plan.  Feedback, objections,
general grumpiness welcome.

0. Open JIRA against 2.4
1. Revert web site update
2. Drop 2.4 artifacts from release area
3. Copy 2.4 release tag to make 2.4.1 release tag
4. Roll good artifacts from 2.4.1 tag. If these do not test out,
drop the tag; else
5. Push out 2.4.

I don't think we need a new vote for 2.4.1 because (unless there
actually is a problem with it) the source should be the same as 2.4.

I am about to get on a plane, so I won't get to 5 for at least 10
hours.  Please speak up if you have objections.

Phil


On 5/27/15 2:57 PM, Phil Steitz wrote:

> Somehow the 2.4 binary release jar that I just pushed to the mirrors
> and maven central appears to be corrupted.  I don't know why / how
> this happened but I get the following error when I build dbcp with
> the new jar:
>
> net/sourceforge/cobertura/coveragedata/TouchCollector
> java.lang.NoClassDefFoundError:
> net/sourceforge/cobertura/coveragedata/TouchCollector
>     at
> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>
> There is also a coberta.properties file in the manifest.  I have no
> idea how it happened, but somehow maven seems to have created the
> release jar from the coberta-instrumented classes or something.
>
> The hashes and sigs on the jar are all good.
>
> I would appreciate some help figuring out what is going on here and
> also pushing out a quick fix release, as I suspect there is no way
> we can pull back what I pushed out about 10 hours ago.
>
> Sorry to have not caught this prior to pushing the binaries out and
> thanks in advance for any help anyone can provide.
>
> Phil
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

James Carman
Are the files that we voted on originally actually corrupt?
On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]> wrote:

> I think we need a vote no matter what for a new release. What we can do is
> make the vote 24 hours instead of 72.
> Gary
>
> -------- Original message --------
> From: Phil Steitz <[hidden email]>
> Date: 05/27/2015  17:54  (GMT-08:00)
> To: Commons Developers List <[hidden email]>
> Subject: Re: [pool] apparently bad jar released ... ugh. help!
>
> OK, having calmed down a bit, I have a plan.  Feedback, objections,
> general grumpiness welcome.
>
> 0. Open JIRA against 2.4
> 1. Revert web site update
> 2. Drop 2.4 artifacts from release area
> 3. Copy 2.4 release tag to make 2.4.1 release tag
> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
> drop the tag; else
> 5. Push out 2.4.
>
> I don't think we need a new vote for 2.4.1 because (unless there
> actually is a problem with it) the source should be the same as 2.4.
>
> I am about to get on a plane, so I won't get to 5 for at least 10
> hours.  Please speak up if you have objections.
>
> Phil
>
>
> On 5/27/15 2:57 PM, Phil Steitz wrote:
> > Somehow the 2.4 binary release jar that I just pushed to the mirrors
> > and maven central appears to be corrupted.  I don't know why / how
> > this happened but I get the following error when I build dbcp with
> > the new jar:
> >
> > net/sourceforge/cobertura/coveragedata/TouchCollector
> > java.lang.NoClassDefFoundError:
> > net/sourceforge/cobertura/coveragedata/TouchCollector
> >     at
> >
> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
> >
> > There is also a coberta.properties file in the manifest.  I have no
> > idea how it happened, but somehow maven seems to have created the
> > release jar from the coberta-instrumented classes or something.
> >
> > The hashes and sigs on the jar are all good.
> >
> > I would appreciate some help figuring out what is going on here and
> > also pushing out a quick fix release, as I suspect there is no way
> > we can pull back what I pushed out about 10 hours ago.
> >
> > Sorry to have not caught this prior to pushing the binaries out and
> > thanks in advance for any help anyone can provide.
> >
> > Phil
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Phil Steitz




> On May 27, 2015, at 10:03 PM, James Carman <[hidden email]> wrote:
>
> Are the files that we voted on originally actually corrupt?

The binary jar is corrupt.  I don't think there is anything wrong with the source distribution.  Independent confirmation that jars built from the 2.4 release sources are consistently clean would be appreciated.  

In any case, I am fine running another vote once I have 2.4.1 artifacts.

Phil


>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]> wrote:
>>
>> I think we need a vote no matter what for a new release. What we can do is
>> make the vote 24 hours instead of 72.
>> Gary
>>
>> -------- Original message --------
>> From: Phil Steitz <[hidden email]>
>> Date: 05/27/2015  17:54  (GMT-08:00)
>> To: Commons Developers List <[hidden email]>
>> Subject: Re: [pool] apparently bad jar released ... ugh. help!
>>
>> OK, having calmed down a bit, I have a plan.  Feedback, objections,
>> general grumpiness welcome.
>>
>> 0. Open JIRA against 2.4
>> 1. Revert web site update
>> 2. Drop 2.4 artifacts from release area
>> 3. Copy 2.4 release tag to make 2.4.1 release tag
>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
>> drop the tag; else
>> 5. Push out 2.4.
>>
>> I don't think we need a new vote for 2.4.1 because (unless there
>> actually is a problem with it) the source should be the same as 2.4.
>>
>> I am about to get on a plane, so I won't get to 5 for at least 10
>> hours.  Please speak up if you have objections.
>>
>> Phil
>>
>>
>>> On 5/27/15 2:57 PM, Phil Steitz wrote:
>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
>>> and maven central appears to be corrupted.  I don't know why / how
>>> this happened but I get the following error when I build dbcp with
>>> the new jar:
>>>
>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>> java.lang.NoClassDefFoundError:
>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>    at
>> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>>>
>>> There is also a coberta.properties file in the manifest.  I have no
>>> idea how it happened, but somehow maven seems to have created the
>>> release jar from the coberta-instrumented classes or something.
>>>
>>> The hashes and sigs on the jar are all good.
>>>
>>> I would appreciate some help figuring out what is going on here and
>>> also pushing out a quick fix release, as I suspect there is no way
>>> we can pull back what I pushed out about 10 hours ago.
>>>
>>> Sorry to have not caught this prior to pushing the binaries out and
>>> thanks in advance for any help anyone can provide.
>>>
>>> Phil
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Mark Thomas
Technically we do need a new release vote since:

a) The released source will not be exactly the same (due to the version
bump).

b) The convenience binaries will be different (due to fixing the
corruption).

We need the vote to make the release an act of the foundation.

We can make the vote as short as we like. That there must be a vote is a
hard rule. Running the vote for at least 72 hours is strongly encouraged
but PMCs are allowed to make exceptions if a shorter vote is in the best
interests of the community e.g. security releases or - as in this case -
fixing a broken binary. I've seen votes last less than an hour for some
security fixes.

Mark




On 28/05/2015 05:13, Phil Steitz wrote:

>
>
>
>
>> On May 27, 2015, at 10:03 PM, James Carman <[hidden email]> wrote:
>>
>> Are the files that we voted on originally actually corrupt?
>
> The binary jar is corrupt.  I don't think there is anything wrong with the source distribution.  Independent confirmation that jars built from the 2.4 release sources are consistently clean would be appreciated.  
>
> In any case, I am fine running another vote once I have 2.4.1 artifacts.
>
> Phil
>
>
>>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]> wrote:
>>>
>>> I think we need a vote no matter what for a new release. What we can do is
>>> make the vote 24 hours instead of 72.
>>> Gary
>>>
>>> -------- Original message --------
>>> From: Phil Steitz <[hidden email]>
>>> Date: 05/27/2015  17:54  (GMT-08:00)
>>> To: Commons Developers List <[hidden email]>
>>> Subject: Re: [pool] apparently bad jar released ... ugh. help!
>>>
>>> OK, having calmed down a bit, I have a plan.  Feedback, objections,
>>> general grumpiness welcome.
>>>
>>> 0. Open JIRA against 2.4
>>> 1. Revert web site update
>>> 2. Drop 2.4 artifacts from release area
>>> 3. Copy 2.4 release tag to make 2.4.1 release tag
>>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
>>> drop the tag; else
>>> 5. Push out 2.4.
>>>
>>> I don't think we need a new vote for 2.4.1 because (unless there
>>> actually is a problem with it) the source should be the same as 2.4.
>>>
>>> I am about to get on a plane, so I won't get to 5 for at least 10
>>> hours.  Please speak up if you have objections.
>>>
>>> Phil
>>>
>>>
>>>> On 5/27/15 2:57 PM, Phil Steitz wrote:
>>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
>>>> and maven central appears to be corrupted.  I don't know why / how
>>>> this happened but I get the following error when I build dbcp with
>>>> the new jar:
>>>>
>>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>> java.lang.NoClassDefFoundError:
>>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>>    at
>>> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>>>>
>>>> There is also a coberta.properties file in the manifest.  I have no
>>>> idea how it happened, but somehow maven seems to have created the
>>>> release jar from the coberta-instrumented classes or something.
>>>>
>>>> The hashes and sigs on the jar are all good.
>>>>
>>>> I would appreciate some help figuring out what is going on here and
>>>> also pushing out a quick fix release, as I suspect there is no way
>>>> we can pull back what I pushed out about 10 hours ago.
>>>>
>>>> Sorry to have not caught this prior to pushing the binaries out and
>>>> thanks in advance for any help anyone can provide.
>>>>
>>>> Phil
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Luc Maisonobe-2
Le 28/05/2015 09:14, Mark Thomas a écrit :

> Technically we do need a new release vote since:
>
> a) The released source will not be exactly the same (due to the version
> bump).
>
> b) The convenience binaries will be different (due to fixing the
> corruption).
>
> We need the vote to make the release an act of the foundation.
>
> We can make the vote as short as we like. That there must be a vote is a
> hard rule. Running the vote for at least 72 hours is strongly encouraged
> but PMCs are allowed to make exceptions if a shorter vote is in the best
> interests of the community e.g. security releases or - as in this case -
> fixing a broken binary. I've seen votes last less than an hour for some
> security fixes.

I understand this, but feel slightly uncomfortable with it. The 72 hours
delay also implied people can have time to raise objections. If 3 votes
are gathered in less than an hour but a fourth reviewer identifies a
critical problem 12 hours later (just because of time zone for example),
then it would be too late. I know enough +1 are enough to get a release
out even if some -1 are also cast, but in a general case we often try to
fix them. Of course, another urgent fix could be made once again, though.

So to be clear, I though 72 hours were required for both gathering
enough +1 but also to see if some -1 are raised, what do other people
think about it?

best regards,
Luc


>
> Mark
>
>
>
>
> On 28/05/2015 05:13, Phil Steitz wrote:
>>
>>
>>
>>
>>> On May 27, 2015, at 10:03 PM, James Carman <[hidden email]> wrote:
>>>
>>> Are the files that we voted on originally actually corrupt?
>>
>> The binary jar is corrupt.  I don't think there is anything wrong with the source distribution.  Independent confirmation that jars built from the 2.4 release sources are consistently clean would be appreciated.  
>>
>> In any case, I am fine running another vote once I have 2.4.1 artifacts.
>>
>> Phil
>>
>>
>>>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]> wrote:
>>>>
>>>> I think we need a vote no matter what for a new release. What we can do is
>>>> make the vote 24 hours instead of 72.
>>>> Gary
>>>>
>>>> -------- Original message --------
>>>> From: Phil Steitz <[hidden email]>
>>>> Date: 05/27/2015  17:54  (GMT-08:00)
>>>> To: Commons Developers List <[hidden email]>
>>>> Subject: Re: [pool] apparently bad jar released ... ugh. help!
>>>>
>>>> OK, having calmed down a bit, I have a plan.  Feedback, objections,
>>>> general grumpiness welcome.
>>>>
>>>> 0. Open JIRA against 2.4
>>>> 1. Revert web site update
>>>> 2. Drop 2.4 artifacts from release area
>>>> 3. Copy 2.4 release tag to make 2.4.1 release tag
>>>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
>>>> drop the tag; else
>>>> 5. Push out 2.4.
>>>>
>>>> I don't think we need a new vote for 2.4.1 because (unless there
>>>> actually is a problem with it) the source should be the same as 2.4.
>>>>
>>>> I am about to get on a plane, so I won't get to 5 for at least 10
>>>> hours.  Please speak up if you have objections.
>>>>
>>>> Phil
>>>>
>>>>
>>>>> On 5/27/15 2:57 PM, Phil Steitz wrote:
>>>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
>>>>> and maven central appears to be corrupted.  I don't know why / how
>>>>> this happened but I get the following error when I build dbcp with
>>>>> the new jar:
>>>>>
>>>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>>> java.lang.NoClassDefFoundError:
>>>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>>>    at
>>>> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>>>>>
>>>>> There is also a coberta.properties file in the manifest.  I have no
>>>>> idea how it happened, but somehow maven seems to have created the
>>>>> release jar from the coberta-instrumented classes or something.
>>>>>
>>>>> The hashes and sigs on the jar are all good.
>>>>>
>>>>> I would appreciate some help figuring out what is going on here and
>>>>> also pushing out a quick fix release, as I suspect there is no way
>>>>> we can pull back what I pushed out about 10 hours ago.
>>>>>
>>>>> Sorry to have not caught this prior to pushing the binaries out and
>>>>> thanks in advance for any help anyone can provide.
>>>>>
>>>>> Phil
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Mark Thomas
On 28/05/2015 09:02, Luc Maisonobe wrote:

> Le 28/05/2015 09:14, Mark Thomas a écrit :
>> Technically we do need a new release vote since:
>>
>> a) The released source will not be exactly the same (due to the version
>> bump).
>>
>> b) The convenience binaries will be different (due to fixing the
>> corruption).
>>
>> We need the vote to make the release an act of the foundation.
>>
>> We can make the vote as short as we like. That there must be a vote is a
>> hard rule. Running the vote for at least 72 hours is strongly encouraged
>> but PMCs are allowed to make exceptions if a shorter vote is in the best
>> interests of the community e.g. security releases or - as in this case -
>> fixing a broken binary. I've seen votes last less than an hour for some
>> security fixes.
>
> I understand this, but feel slightly uncomfortable with it. The 72 hours
> delay also implied people can have time to raise objections. If 3 votes
> are gathered in less than an hour but a fourth reviewer identifies a
> critical problem 12 hours later (just because of time zone for example),
> then it would be too late. I know enough +1 are enough to get a release
> out even if some -1 are also cast, but in a general case we often try to
> fix them. Of course, another urgent fix could be made once again, though.
>
> So to be clear, I though 72 hours were required for both gathering
> enough +1 but also to see if some -1 are raised, what do other people
> think about it?

In the general case I agree with you completely.

In the less than an hour case I was referring to, folks had actually had
a lot longer to review and test the patch but on the private security@
list. The public vote was simply an exercise in getting the necessary
votes into the public record.

As always these things are a balance and the board generally leaves it
up to the PMC to decide what is best. If a PMC was regularly having
votes of only a few hours I'm sure the board would have concerns. I
don't think the board would have concerns about a short vote in the Pool
2.4.1 case.

In the Pool 2.4.1 case we need to balance giving time for folks to find
issues with 2.4.1 against reducing the time the known faulty 2.4.0
binary is out there. My own view is that the greater risk / harm /
inconvenience to the community is to leave 2.4.0 out for longer than we
absolutely have to.

Given that:
- the only source change since 2.4.0 will be to the version number
- the known issue in 2.4.0 that we are trying to fix is easy to test for
I think the chances of the same issue happening again and not being
detected or a new issue being introduced are slim enough that a short
vote is OK.

Ultimately it is the RM that decides how long the vote is (which should
be declared when the vote is called). If the the consensus view is that
the vote period called for is too short the RM can always extend it.

Mark

> best regards,
> Luc
>
>
>>
>> Mark
>>
>>
>>
>>
>> On 28/05/2015 05:13, Phil Steitz wrote:
>>>
>>>
>>>
>>>
>>>> On May 27, 2015, at 10:03 PM, James Carman <[hidden email]> wrote:
>>>>
>>>> Are the files that we voted on originally actually corrupt?
>>>
>>> The binary jar is corrupt.  I don't think there is anything wrong with the source distribution.  Independent confirmation that jars built from the 2.4 release sources are consistently clean would be appreciated.  
>>>
>>> In any case, I am fine running another vote once I have 2.4.1 artifacts.
>>>
>>> Phil
>>>
>>>
>>>>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]> wrote:
>>>>>
>>>>> I think we need a vote no matter what for a new release. What we can do is
>>>>> make the vote 24 hours instead of 72.
>>>>> Gary
>>>>>
>>>>> -------- Original message --------
>>>>> From: Phil Steitz <[hidden email]>
>>>>> Date: 05/27/2015  17:54  (GMT-08:00)
>>>>> To: Commons Developers List <[hidden email]>
>>>>> Subject: Re: [pool] apparently bad jar released ... ugh. help!
>>>>>
>>>>> OK, having calmed down a bit, I have a plan.  Feedback, objections,
>>>>> general grumpiness welcome.
>>>>>
>>>>> 0. Open JIRA against 2.4
>>>>> 1. Revert web site update
>>>>> 2. Drop 2.4 artifacts from release area
>>>>> 3. Copy 2.4 release tag to make 2.4.1 release tag
>>>>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
>>>>> drop the tag; else
>>>>> 5. Push out 2.4.
>>>>>
>>>>> I don't think we need a new vote for 2.4.1 because (unless there
>>>>> actually is a problem with it) the source should be the same as 2.4.
>>>>>
>>>>> I am about to get on a plane, so I won't get to 5 for at least 10
>>>>> hours.  Please speak up if you have objections.
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>> On 5/27/15 2:57 PM, Phil Steitz wrote:
>>>>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
>>>>>> and maven central appears to be corrupted.  I don't know why / how
>>>>>> this happened but I get the following error when I build dbcp with
>>>>>> the new jar:
>>>>>>
>>>>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>>>> java.lang.NoClassDefFoundError:
>>>>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>>>>>    at
>>>>> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>>>>>>
>>>>>> There is also a coberta.properties file in the manifest.  I have no
>>>>>> idea how it happened, but somehow maven seems to have created the
>>>>>> release jar from the coberta-instrumented classes or something.
>>>>>>
>>>>>> The hashes and sigs on the jar are all good.
>>>>>>
>>>>>> I would appreciate some help figuring out what is going on here and
>>>>>> also pushing out a quick fix release, as I suspect there is no way
>>>>>> we can pull back what I pushed out about 10 hours ago.
>>>>>>
>>>>>> Sorry to have not caught this prior to pushing the binaries out and
>>>>>> thanks in advance for any help anyone can provide.
>>>>>>
>>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

James Carman
In reply to this post by Mark Thomas
I suppose we can't overwrite what's there?
On Thu, May 28, 2015 at 3:14 AM Mark Thomas <[hidden email]> wrote:

> Technically we do need a new release vote since:
>
> a) The released source will not be exactly the same (due to the version
> bump).
>
> b) The convenience binaries will be different (due to fixing the
> corruption).
>
> We need the vote to make the release an act of the foundation.
>
> We can make the vote as short as we like. That there must be a vote is a
> hard rule. Running the vote for at least 72 hours is strongly encouraged
> but PMCs are allowed to make exceptions if a shorter vote is in the best
> interests of the community e.g. security releases or - as in this case -
> fixing a broken binary. I've seen votes last less than an hour for some
> security fixes.
>
> Mark
>
>
>
>
> On 28/05/2015 05:13, Phil Steitz wrote:
> >
> >
> >
> >
> >> On May 27, 2015, at 10:03 PM, James Carman <[hidden email]>
> wrote:
> >>
> >> Are the files that we voted on originally actually corrupt?
> >
> > The binary jar is corrupt.  I don't think there is anything wrong with
> the source distribution.  Independent confirmation that jars built from the
> 2.4 release sources are consistently clean would be appreciated.
> >
> > In any case, I am fine running another vote once I have 2.4.1 artifacts.
> >
> > Phil
> >
> >
> >>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]>
> wrote:
> >>>
> >>> I think we need a vote no matter what for a new release. What we can
> do is
> >>> make the vote 24 hours instead of 72.
> >>> Gary
> >>>
> >>> -------- Original message --------
> >>> From: Phil Steitz <[hidden email]>
> >>> Date: 05/27/2015  17:54  (GMT-08:00)
> >>> To: Commons Developers List <[hidden email]>
> >>> Subject: Re: [pool] apparently bad jar released ... ugh. help!
> >>>
> >>> OK, having calmed down a bit, I have a plan.  Feedback, objections,
> >>> general grumpiness welcome.
> >>>
> >>> 0. Open JIRA against 2.4
> >>> 1. Revert web site update
> >>> 2. Drop 2.4 artifacts from release area
> >>> 3. Copy 2.4 release tag to make 2.4.1 release tag
> >>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
> >>> drop the tag; else
> >>> 5. Push out 2.4.
> >>>
> >>> I don't think we need a new vote for 2.4.1 because (unless there
> >>> actually is a problem with it) the source should be the same as 2.4.
> >>>
> >>> I am about to get on a plane, so I won't get to 5 for at least 10
> >>> hours.  Please speak up if you have objections.
> >>>
> >>> Phil
> >>>
> >>>
> >>>> On 5/27/15 2:57 PM, Phil Steitz wrote:
> >>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
> >>>> and maven central appears to be corrupted.  I don't know why / how
> >>>> this happened but I get the following error when I build dbcp with
> >>>> the new jar:
> >>>>
> >>>> net/sourceforge/cobertura/coveragedata/TouchCollector
> >>>> java.lang.NoClassDefFoundError:
> >>>> net/sourceforge/cobertura/coveragedata/TouchCollector
> >>>>    at
> >>>
> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
> >>>>
> >>>> There is also a coberta.properties file in the manifest.  I have no
> >>>> idea how it happened, but somehow maven seems to have created the
> >>>> release jar from the coberta-instrumented classes or something.
> >>>>
> >>>> The hashes and sigs on the jar are all good.
> >>>>
> >>>> I would appreciate some help figuring out what is going on here and
> >>>> also pushing out a quick fix release, as I suspect there is no way
> >>>> we can pull back what I pushed out about 10 hours ago.
> >>>>
> >>>> Sorry to have not caught this prior to pushing the binaries out and
> >>>> thanks in advance for any help anyone can provide.
> >>>>
> >>>> Phil
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Grzegorz S?owikowski
In reply to this post by Phil Steitz
Hi

I think, I know the reason, I've had similar problem.

This commit
http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?view=diff&r1=1680128&r2=1680129&pathrev=1680129
upgraded cobertura plugin's version to 2.7.

There is new, VERY "DANGEROUS" reporting mojo in 2.7 -
"cobertura-integration-test"
(http://mojo.codehaus.org/cobertura-maven-plugin/cobertura-integration-test-mojo.html)
During processing in foked lifecycle it overrides the project artifact
jar file with the instrumented version.

This mojo should be avoided if possible IMO, but Maven site plugin runs
all reporting mojos when generating site. You have to configure
reportsets adding only "cobertura" reportset.
See "Using different reports" section in
http://mojo.codehaus.org/cobertura-maven-plugin/usage.html

I see there is issue already reported -
http://jira.codehaus.org/browse/MCOBERTURA-203

Regards
Grzegorz Slowikowski

On 2015-05-27 23:57, Phil Steitz wrote:

> Somehow the 2.4 binary release jar that I just pushed to the mirrors
> and maven central appears to be corrupted.  I don't know why / how
> this happened but I get the following error when I build dbcp with
> the new jar:
>
> net/sourceforge/cobertura/coveragedata/TouchCollector
> java.lang.NoClassDefFoundError:
> net/sourceforge/cobertura/coveragedata/TouchCollector
>     at
> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>
> There is also a coberta.properties file in the manifest.  I have no
> idea how it happened, but somehow maven seems to have created the
> release jar from the coberta-instrumented classes or something.
>
> The hashes and sigs on the jar are all good.
>
> I would appreciate some help figuring out what is going on here and
> also pushing out a quick fix release, as I suspect there is no way
> we can pull back what I pushed out about 10 hours ago.
>
> Sorry to have not caught this prior to pushing the binaries out and
> thanks in advance for any help anyone can provide.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> .
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Phil Steitz
On 5/28/15 6:47 AM, Grzegorz Słowikowski wrote:

> Hi
>
> I think, I know the reason, I've had similar problem.
>
> This commit
> http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?view=diff&r1=1680128&r2=1680129&pathrev=1680129
> upgraded cobertura plugin's version to 2.7.
>
> There is new, VERY "DANGEROUS" reporting mojo in 2.7 -
> "cobertura-integration-test"
> (http://mojo.codehaus.org/cobertura-maven-plugin/cobertura-integration-test-mojo.html)
> During processing in foked lifecycle it overrides the project artifact
> jar file with the instrumented version.
>
> This mojo should be avoided if possible IMO, but Maven site plugin runs
> all reporting mojos when generating site. You have to configure
> reportsets adding only "cobertura" reportset.
> See "Using different reports" section in
> http://mojo.codehaus.org/cobertura-maven-plugin/usage.html
>
> I see there is issue already reported -
> http://jira.codehaus.org/browse/MCOBERTURA-203
>
> Regards
> Grzegorz Slowikowski

Thanks, Grzegorz!

I really, really appreciate this.

Phil

>
> On 2015-05-27 23:57, Phil Steitz wrote:
>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
>> and maven central appears to be corrupted.  I don't know why / how
>> this happened but I get the following error when I build dbcp with
>> the new jar:
>>
>> net/sourceforge/cobertura/coveragedata/TouchCollector
>> java.lang.NoClassDefFoundError:
>> net/sourceforge/cobertura/coveragedata/TouchCollector
>>     at
>> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>>
>> There is also a coberta.properties file in the manifest.  I have no
>> idea how it happened, but somehow maven seems to have created the
>> release jar from the coberta-instrumented classes or something.
>>
>> The hashes and sigs on the jar are all good.
>>
>> I would appreciate some help figuring out what is going on here and
>> also pushing out a quick fix release, as I suspect there is no way
>> we can pull back what I pushed out about 10 hours ago.
>>
>> Sorry to have not caught this prior to pushing the binaries out and
>> thanks in advance for any help anyone can provide.
>>
>> Phil
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> .
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

sebb-2-2
In reply to this post by James Carman
On 28 May 2015 at 11:46, James Carman <[hidden email]> wrote:
> I suppose we can't overwrite what's there?

AFAIK, one can just re-release 2.4.

Still needs a vote IMO.

> On Thu, May 28, 2015 at 3:14 AM Mark Thomas <[hidden email]> wrote:
>
>> Technically we do need a new release vote since:
>>
>> a) The released source will not be exactly the same (due to the version
>> bump).
>>
>> b) The convenience binaries will be different (due to fixing the
>> corruption).
>>
>> We need the vote to make the release an act of the foundation.
>>
>> We can make the vote as short as we like. That there must be a vote is a
>> hard rule. Running the vote for at least 72 hours is strongly encouraged
>> but PMCs are allowed to make exceptions if a shorter vote is in the best
>> interests of the community e.g. security releases or - as in this case -
>> fixing a broken binary. I've seen votes last less than an hour for some
>> security fixes.
>>
>> Mark
>>
>>
>>
>>
>> On 28/05/2015 05:13, Phil Steitz wrote:
>> >
>> >
>> >
>> >
>> >> On May 27, 2015, at 10:03 PM, James Carman <[hidden email]>
>> wrote:
>> >>
>> >> Are the files that we voted on originally actually corrupt?
>> >
>> > The binary jar is corrupt.  I don't think there is anything wrong with
>> the source distribution.  Independent confirmation that jars built from the
>> 2.4 release sources are consistently clean would be appreciated.
>> >
>> > In any case, I am fine running another vote once I have 2.4.1 artifacts.
>> >
>> > Phil
>> >
>> >
>> >>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <[hidden email]>
>> wrote:
>> >>>
>> >>> I think we need a vote no matter what for a new release. What we can
>> do is
>> >>> make the vote 24 hours instead of 72.
>> >>> Gary
>> >>>
>> >>> -------- Original message --------
>> >>> From: Phil Steitz <[hidden email]>
>> >>> Date: 05/27/2015  17:54  (GMT-08:00)
>> >>> To: Commons Developers List <[hidden email]>
>> >>> Subject: Re: [pool] apparently bad jar released ... ugh. help!
>> >>>
>> >>> OK, having calmed down a bit, I have a plan.  Feedback, objections,
>> >>> general grumpiness welcome.
>> >>>
>> >>> 0. Open JIRA against 2.4
>> >>> 1. Revert web site update
>> >>> 2. Drop 2.4 artifacts from release area
>> >>> 3. Copy 2.4 release tag to make 2.4.1 release tag
>> >>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out,
>> >>> drop the tag; else
>> >>> 5. Push out 2.4.
>> >>>
>> >>> I don't think we need a new vote for 2.4.1 because (unless there
>> >>> actually is a problem with it) the source should be the same as 2.4.
>> >>>
>> >>> I am about to get on a plane, so I won't get to 5 for at least 10
>> >>> hours.  Please speak up if you have objections.
>> >>>
>> >>> Phil
>> >>>
>> >>>
>> >>>> On 5/27/15 2:57 PM, Phil Steitz wrote:
>> >>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors
>> >>>> and maven central appears to be corrupted.  I don't know why / how
>> >>>> this happened but I get the following error when I build dbcp with
>> >>>> the new jar:
>> >>>>
>> >>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>> >>>> java.lang.NoClassDefFoundError:
>> >>>> net/sourceforge/cobertura/coveragedata/TouchCollector
>> >>>>    at
>> >>>
>> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)
>> >>>>
>> >>>> There is also a coberta.properties file in the manifest.  I have no
>> >>>> idea how it happened, but somehow maven seems to have created the
>> >>>> release jar from the coberta-instrumented classes or something.
>> >>>>
>> >>>> The hashes and sigs on the jar are all good.
>> >>>>
>> >>>> I would appreciate some help figuring out what is going on here and
>> >>>> also pushing out a quick fix release, as I suspect there is no way
>> >>>> we can pull back what I pushed out about 10 hours ago.
>> >>>>
>> >>>> Sorry to have not caught this prior to pushing the binaries out and
>> >>>> thanks in advance for any help anyone can provide.
>> >>>>
>> >>>> Phil
>> >>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

James Carman
On Thu, May 28, 2015 at 1:56 PM sebb <[hidden email]> wrote:

>
> Still needs a vote IMO.
>
>
Yes, if the binaries we voted on were actually corrupt and it wasn't
something that got corrupt during transfer, then we need to re-build the
binaries and re-vote on them.
Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

garydgregory
Since the bad jars are percolating through mirrors or have already done so,
I do not see another choice but releasing a 2.4.1.

Gary

On Thu, May 28, 2015 at 11:13 AM, James Carman <[hidden email]>
wrote:

> On Thu, May 28, 2015 at 1:56 PM sebb <[hidden email]> wrote:
>
> >
> > Still needs a vote IMO.
> >
> >
> Yes, if the binaries we voted on were actually corrupt and it wasn't
> something that got corrupt during transfer, then we need to re-build the
> binaries and re-vote on them.
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Phil Steitz
I burned the time I had last night trying to figure out what was going on before I saw Grygorz' explanation and I have been out of pocket today.  Will not be able to get to this until toMorrow.  



> On May 28, 2015, at 3:27 PM, Gary Gregory <[hidden email]> wrote:
>
> Since the bad jars are percolating through mirrors or have already done so,
> I do not see another choice but releasing a 2.4.1.
>
> Gary
>
> On Thu, May 28, 2015 at 11:13 AM, James Carman <[hidden email]>
> wrote:
>
>>> On Thu, May 28, 2015 at 1:56 PM sebb <[hidden email]> wrote:
>>>
>>>
>>> Still needs a vote IMO.
>> Yes, if the binaries we voted on were actually corrupt and it wasn't
>> something that got corrupt during transfer, then we need to re-build the
>> binaries and re-vote on them.
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Dan Tran
Just curious, how did this pass the staging test during the vote?

Thanks

-D

On Thu, May 28, 2015 at 4:10 PM, Phil Steitz <[hidden email]> wrote:

> I burned the time I had last night trying to figure out what was going on
> before I saw Grygorz' explanation and I have been out of pocket today.
> Will not be able to get to this until toMorrow.
>
>
>
> > On May 28, 2015, at 3:27 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > Since the bad jars are percolating through mirrors or have already done
> so,
> > I do not see another choice but releasing a 2.4.1.
> >
> > Gary
> >
> > On Thu, May 28, 2015 at 11:13 AM, James Carman <
> [hidden email]>
> > wrote:
> >
> >>> On Thu, May 28, 2015 at 1:56 PM sebb <[hidden email]> wrote:
> >>>
> >>>
> >>> Still needs a vote IMO.
> >> Yes, if the binaries we voted on were actually corrupt and it wasn't
> >> something that got corrupt during transfer, then we need to re-build the
> >> binaries and re-vote on them.
> >
> >
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [pool] apparently bad jar released ... ugh. help!

Phil Steitz
Most reviewers evaluate the release candidate based on the sources.  Other than the bugged plugin reference in the pom, there is nothing wrong with the sources.  What was defective was the compiled jar.  It was correctly hashed and signed, but due to nasty plugin bug it ended up containing instrumented classes.

This is my responsibility as rm. in the future I will separately test compiled jars and I recommend that other reviewers do the same as we apparently cannot count on correct functioning of packaging tools.



> On May 28, 2015, at 6:15 PM, Dan Tran <[hidden email]> wrote:
>
> Just curious, how did this pass the staging test during the vote?
>
> Thanks
>
> -D
>
>> On Thu, May 28, 2015 at 4:10 PM, Phil Steitz <[hidden email]> wrote:
>>
>> I burned the time I had last night trying to figure out what was going on
>> before I saw Grygorz' explanation and I have been out of pocket today.
>> Will not be able to get to this until toMorrow.
>>
>>
>>
>>>> On May 28, 2015, at 3:27 PM, Gary Gregory <[hidden email]>
>>> wrote:
>>>
>>> Since the bad jars are percolating through mirrors or have already done
>> so,
>>> I do not see another choice but releasing a 2.4.1.
>>>
>>> Gary
>>>
>>> On Thu, May 28, 2015 at 11:13 AM, James Carman <
>> [hidden email]>
>>> wrote:
>>>
>>>>> On Thu, May 28, 2015 at 1:56 PM sebb <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Still needs a vote IMO.
>>>> Yes, if the binaries we voted on were actually corrupt and it wasn't
>>>> something that got corrupt during transfer, then we need to re-build the
>>>> binaries and re-vote on them.
>>>
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]