On 03/08/2013 11:34 PM, sebb wrote: > On 8 March 2013 20:28, sebb <seb...@gmail.com> wrote: >> 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. > > 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
