commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Date Wed, 13 Mar 2013 21:10:50 GMT
On 03/08/2013 11:34 PM, sebb wrote:
> On 8 March 2013 20:28, sebb <sebbaz@gmail.com> wrote:
>> On 8 March 2013 07:31, Thomas Neidhart <thomas.neidhart@gmail.com> wrote:
>>> 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.
>>
>> That's not the only override it uses; there are quite a few other bits
>> that could / should probably be dropped.
>>
>>> This solved the problem that even with -Ptest-deploy the artifacts were
>>> uploaded to nexus. The assemblies are still not there.
>>
>> The assemblies are not there because of the last line below:
>>
>>         <artifactId>maven-assembly-plugin</artifactId>
>>         <configuration>
>>           <!-- Do not deploy the assemblies to the repository. -->
>>           <attach>false</attach>
>>
>> I've been playing with dropping various bits of the pom overrides, but
>> so far have not got a fully working one.
>>
>> I would expect to be able to drop the assembly plugin from logging pom
>> (as the parent one is similar), but then I get
>>
>> "Error reading assemblies: No assembly descriptors found."
>>
>> even if I move the assemblies to the standard location - i.e. src/main/assembly
>>
>> Not sure what's happening yet.
> 
> Looks like one still has to provide the descriptor - other components do.
> 
> Should probably consider adding it to the parent POM; that would
> simplify the component POMs

I checked in a cleaned up version that works for me locally.
The deploy directory afterwards contains all artifacts.

Could you cross-check please?

Thanks,

Thomas

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


Mime
View raw message