On 8 March 2013 07:31, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On 03/08/2013 01:25 AM, sebb wrote: >> On 7 March 2013 18:49, Thomas Neidhart <thomas.neidh...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org