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 20:28:51 GMT
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.

> 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