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