On 8 March 2013 07:31, Thomas Neidhart <[email protected]> wrote:
> On 03/08/2013 01:25 AM, sebb wrote:
>> On 7 March 2013 18:49, Thomas Neidhart <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]