You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2013/03/05 23:08:15 UTC

[VOTE] Release of Commons Logging 1.1.2 based on RC1

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 ...
------------------------------------------------

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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


Re: [VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by sebb <se...@gmail.com>.
Remember there is a -Ptest-deploy profile that can be used to test
what will be deployed.
This puts the output in target/deploy

I've found it's sometimes necessary to use "package" as well as
"deploy" to ensure everything is included in the deploy phase.


On 7 March 2013 11:36, Thomas Neidhart <th...@gmail.com> wrote:
> On Thu, Mar 7, 2013 at 10:53 AM, luc <lu...@spaceroots.org> wrote:
>
>> Le 2013-03-07 10:05, Thomas Neidhart a écrit :
>>
>>  On Tue, Mar 5, 2013 at 11:08 PM, Thomas Neidhart
>>> <th...@gmail.com>**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/<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/<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/<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 ...
>>>> ------------------------------**------------------
>>>>
>>>
>> Hi Thomas,
>>
>> Where is the source distribution? I only find the
>> commons-logging-1.1.2-sources.**jar,
>> which is not a complete source distribution.
>>
>
> It is indeed not there on nexus. I validated it beforehand so that the
> download.cgi is not included, but it may have not been created while
> deploying.
> I will investigate when I am at home, I should still have the deployment
> directory.
>
> Thomas

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


Re: [VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by Thomas Neidhart <th...@gmail.com>.
On Thu, Mar 7, 2013 at 10:53 AM, luc <lu...@spaceroots.org> wrote:

> Le 2013-03-07 10:05, Thomas Neidhart a écrit :
>
>  On Tue, Mar 5, 2013 at 11:08 PM, Thomas Neidhart
>> <th...@gmail.com>**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/<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/<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/<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 ...
>>> ------------------------------**------------------
>>>
>>
> Hi Thomas,
>
> Where is the source distribution? I only find the
> commons-logging-1.1.2-sources.**jar,
> which is not a complete source distribution.
>

It is indeed not there on nexus. I validated it beforehand so that the
download.cgi is not included, but it may have not been created while
deploying.
I will investigate when I am at home, I should still have the deployment
directory.

Thomas

Re: [VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by luc <lu...@spaceroots.org>.
Le 2013-03-07 10:05, Thomas Neidhart a écrit :
> On Tue, Mar 5, 2013 at 11:08 PM, Thomas Neidhart
> <th...@gmail.com>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 ...
>> ------------------------------------------------

Hi Thomas,

Where is the source distribution? I only find the 
commons-logging-1.1.2-sources.jar,
which is not a complete source distribution.

best regards,
Luc

>>
>
> ping plus my own +1
>
> Thomas


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


Re: [VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by Thomas Neidhart <th...@gmail.com>.
On Tue, Mar 5, 2013 at 11:08 PM, Thomas Neidhart
<th...@gmail.com>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 ...
> ------------------------------------------------
>

ping plus my own +1

Thomas

Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by Thomas Neidhart <th...@gmail.com>.
On 03/08/2013 11:34 PM, sebb wrote:
> On 8 March 2013 20:28, sebb <se...@gmail.com> wrote:
>> On 8 March 2013 07:31, Thomas Neidhart <th...@gmail.com> wrote:
>>> On 03/08/2013 01:25 AM, sebb wrote:
>>>> On 7 March 2013 18:49, Thomas Neidhart <th...@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


Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by sebb <se...@gmail.com>.
On 8 March 2013 20:28, sebb <se...@gmail.com> wrote:
> On 8 March 2013 07:31, Thomas Neidhart <th...@gmail.com> wrote:
>> On 03/08/2013 01:25 AM, sebb wrote:
>>> On 7 March 2013 18:49, Thomas Neidhart <th...@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


Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by sebb <se...@gmail.com>.
On 8 March 2013 07:31, Thomas Neidhart <th...@gmail.com> wrote:
> On 03/08/2013 01:25 AM, sebb wrote:
>> On 7 March 2013 18:49, Thomas Neidhart <th...@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


Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by Thomas Neidhart <th...@gmail.com>.
On 03/08/2013 01:25 AM, sebb wrote:
> On 7 March 2013 18:49, Thomas Neidhart <th...@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


Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by sebb <se...@gmail.com>.
On 7 March 2013 18:49, Thomas Neidhart <th...@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

> ad b)
>
> the mentioned test case has the following code at the end:
>
>         // some JVMs seem to take a little time to put references on
>         // the reference queue once the reference has been collected
>         // need to think about whether this is enough to justify
>         // stepping through the collection each time...
>         while(testQueue.poll() == null) {}
>
> with IBM JDK 6 this takes a very long time, even when forcing a GC from
> e.g. jconsole. Also needs further investigation, refactor the test code.
>
> 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


[CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1

Posted by Thomas Neidhart <th...@gmail.com>.
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.

ad b)

the mentioned test case has the following code at the end:

        // some JVMs seem to take a little time to put references on
        // the reference queue once the reference has been collected
        // need to think about whether this is enough to justify
        // stepping through the collection each time...
        while(testQueue.poll() == null) {}

with IBM JDK 6 this takes a very long time, even when forcing a GC from
e.g. jconsole. Also needs further investigation, refactor the test code.

Thomas

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