Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of thomas.neidhart@gmail.com
 designates 74.125.82.169 as permitted sender)
Message-ID: <513993DD.8060307@gmail.com>
Date: Fri, 08 Mar 2013 08:31:41 +0100
From: Thomas Neidhart <thomas.neidhart@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
References: <51366CCF.9060205@gmail.com> <5138E131.3050704@gmail.com>
 <CAOGo0VYSfy8CQ9=kweLtjgcFnNkA5to1ZzAiWj=qy7_MUnNVfg@mail.gmail.com>
In-Reply-To: 
 <CAOGo0VYSfy8CQ9=kweLtjgcFnNkA5to1ZzAiWj=qy7_MUnNVfg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/08/2013 01:25 AM, sebb wrote:
> On 7 March 2013 18:49, Thomas Neidhart <thomas.neidhart@gmail.com> wrote:
>> On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
>>> Hi,
>>>
>>> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>>>
>>> This release candidate has the following changes compared to 1.1.1
>>> (copied from the release notes):
>>>
>>> Fixed Bugs:
>>> o LOGGING-124:  The jar manifest now contains proper OSGi-related
>>> metadata information.
>>> o LOGGING-144:  LogFactory and LogFactoryImpl will not swallow certain
>>> errors anymore (ThreadDeath and VirtualMachineError).
>>> o LOGGING-132:  Jdk14Logger now correctly uses the specified logger name.
>>> o LOGGING-146:  Properly synchronize access to protected static field
>>> LogFactory.nullClassLoaderFactory.
>>> o LOGGING-119:  Prevent potential deadlock scenario in WeakHashtable.
>>> o LOGGING-130:  Potential missing privileged block for class loader.
>>> o LOGGING-145:  LogFactoryImpl.setAttribute - possible NPE.
>>> o LOGGING-142:  Log4JLogger uses deprecated static members of Priority
>>> such as INFO.
>>> o LOGGING-128:  Static analysis suggests a number of potential improvements.
>>> o LOGGING-147:  SimpleLog.log - unsafe update of shortLogName.
>>> o LOGGING-148:  LogFactory.diagnosticPrefix and diagnosticsStream could
>>> be final.
>>>
>>> Changes:
>>> o LOGGING-135:  Improved thread-safety for several log adapters,
>>> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
>>> o LOGGING-138:  In case of a discovery failure now also the stacktrace
>>> of the cause will be added to the diagnostic message.
>>> o LOGGING-133:  Change scope of Jdk14Logger.log(Level, String,
>>> Throwable) to protected, allowing subclasses to modify the logging output.
>>>
>>> The files:
>>>
>>> The artifacts are deployed to Nexus:
>>> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>>>
>>> The tag:
>>> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>>>
>>> The site:
>>> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>>>
>>> Additional Notes:
>>>
>>> o the download page and api links to older releases only work on
>>>   the published site and will be corrected after release.
>>>
>>> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>>>
>>> ------------------------------------------------
>>> [ ] +1 release it.
>>> [ ] +0 go ahead; I don't care.
>>> [ ] -0 there are a few minor glitches: ...
>>> [ ] -1 no, do not release it because ...
>>> ------------------------------------------------
>>
>> This message cancels the vote, the following problems have been found:
>>
>>  a) source/binary distribution not deployed
>>  b) WeakHashtableTestCase takes a long time with IBM JDK
>>
>> ad a)
>>
>> the binary assembly descriptor contains the following:
>>
>>   <includeSiteDirectory>true</includeSiteDirectory>
>>
>> which requires the site to be built to create the assemblies.
>> Commenting this out, and calling:
>>
>> mvn clean assembly:assembly deploy -Ptest-deploy
>>
>> creates them correctly, but they are not in the target/deploy folder,
>> needs further investigation.
> 
> Might also need -Prelease

argh, the pom.xml for logging re-defines the release profile.

This solved the problem that even with -Ptest-deploy the artifacts were
uploaded to nexus. The assemblies are still not there.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org