commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Date Fri, 08 Mar 2013 22:34:15 GMT
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

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

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


Mime
View raw message