Re: [logging] Running tests on earlier JVMs
Robert Burrell Donkin wrote: (fetchmail-jsieve-IMAP is now working fine for me in JAMES and i've stopped buggy FETCH response crashing evolution so but i won't have access to my old mail until i've rewritten the backend so that it will perform against big message sets. in short, i think i'm getting commons mail ok but i'm short on archives...) so could people help me get back up to speed on where we are with JCL and were we want to get to...? There is need for a 1.1.1 release of commons-logging. All the pressing bugs have been fixed and tested. The build system has been expanded to include Maven, though Ant and Maven 1 should still work too. My plan is to create a 1.1.1 release with Maven 2. However, Maven 2 runs on a 1.4 JVM so we can't be 100% sure that the tests really pass on a 1.2 JVM. The idea is that the RM will run a separate Ant script that uses the binaries that M2 created (both main and test jars) and run it on an earlier JVM, for verification. It is that Ant script that I'm currently working on, and am having trouble with. See more below... On Thu, 2007-07-19 at 22:19 +0200, Dennis Lundberg wrote: Henri Yandell wrote: snip Finding a (really old) platform to run on = We've said earlier that we should ideally run the tests using a 1.2 jvm. So I installed 1.2.2_17 on my Windows machine and started running tests. That didn't go to well. Here's what I get: Buildfile: build-testing.xml A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.addReference (Ljava/lang/String;Ljava/lang/Object;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.fireMessageLoggedEvent (Lorg/apache/tools/ant/BuildEvent;Ljava/lang/String;I)V': Interpreting method . Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.addCreatedTask (Ljava/lang/String;Lorg/apache/tools/ant/Task;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi init: [echo] Logging Wrapper Library 1.1.1-SNAPSHOT discovery: log4j12-test-warning: test: [echo] Test output can be found in directory G:\apache\jakarta\commons-logging/target/test-reports. [delete] Deleting directory G:\apache\jakarta\commons-logging\target\test-reports [mkdir] Created dir: G:\apache\jakarta\commons-logging\target\test-reports [echo] executing tests [**/*TestCase.java] A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.getDataTypeDefinitions ()Ljava/util/Hashtable;': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/DirectoryScanner.scan ()V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/util/FileUtils.createTempFile (Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;': Interpret ing method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/taskdefs/ProcessDestroyer.add (Ljava/lang/Process;)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) And then it just hangs! This is done using ant 1.6.5. When I tried with ant 1.5.4 it didn't work at all because we use propertyset: BUILD FAILED file:G:/apache/jakarta/commons-logging/build-testing.xml:171: Unexpected element propertyset I don't know the jvm requirements for the different ant versions. I'll be checking in the ant script shortly... Any pointers to what might be going wrong here is greatly appreciated. the good news is that my old machine is now working again :-) here's my bad news: JCL source will not compile for me on a 1.2.2 JVM (IIRC some 1.2 JVM had compilers bugs) Compiler bugs
Re: [logging] Running tests on earlier JVMs
Dennis Lundberg wrote: Robert Burrell Donkin wrote: (fetchmail-jsieve-IMAP is now working fine for me in JAMES and i've stopped buggy FETCH response crashing evolution so but i won't have access to my old mail until i've rewritten the backend so that it will perform against big message sets. in short, i think i'm getting commons mail ok but i'm short on archives...) so could people help me get back up to speed on where we are with JCL and were we want to get to...? There is need for a 1.1.1 release of commons-logging. All the pressing bugs have been fixed and tested. The build system has been expanded to include Maven, though Ant and Maven 1 should still work too. My plan is to create a 1.1.1 release with Maven 2. However, Maven 2 runs on a 1.4 JVM so we can't be 100% sure that the tests really pass on a 1.2 JVM. The idea is that the RM will run a separate Ant script that uses the binaries that M2 created (both main and test jars) and run it on an earlier JVM, for verification. It is that Ant script that I'm currently working on, and am having trouble with. See more below... On Thu, 2007-07-19 at 22:19 +0200, Dennis Lundberg wrote: Henri Yandell wrote: snip Finding a (really old) platform to run on = We've said earlier that we should ideally run the tests using a 1.2 jvm. So I installed 1.2.2_17 on my Windows machine and started running tests. That didn't go to well. Here's what I get: Buildfile: build-testing.xml A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.addReference (Ljava/lang/String;Ljava/lang/Object;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.fireMessageLoggedEvent (Lorg/apache/tools/ant/BuildEvent;Ljava/lang/String;I)V': Interpreting method . Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.addCreatedTask (Ljava/lang/String;Lorg/apache/tools/ant/Task;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi init: [echo] Logging Wrapper Library 1.1.1-SNAPSHOT discovery: log4j12-test-warning: test: [echo] Test output can be found in directory G:\apache\jakarta\commons-logging/target/test-reports. [delete] Deleting directory G:\apache\jakarta\commons-logging\target\test-reports [mkdir] Created dir: G:\apache\jakarta\commons-logging\target\test-reports [echo] executing tests [**/*TestCase.java] A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.getDataTypeDefinitions ()Ljava/util/Hashtable;': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/DirectoryScanner.scan ()V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/util/FileUtils.createTempFile (Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;': Interpret ing method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/taskdefs/ProcessDestroyer.add (Ljava/lang/Process;)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) And then it just hangs! This is done using ant 1.6.5. When I tried with ant 1.5.4 it didn't work at all because we use propertyset: BUILD FAILED file:G:/apache/jakarta/commons-logging/build-testing.xml:171: Unexpected element propertyset I don't know the jvm requirements for the different ant versions. I'll be checking in the ant script shortly... Any pointers to what might be going wrong here is greatly appreciated. the good news is that my old machine is now working again :-) here's my bad news: JCL source will not compile for me on a 1.2.2 JVM (IIRC some
Re: Commons Logging 1.1.1 - when?
Sullivan, Sean wrote: Are there plans to release Commons Logging 1.1.1? I am eager to see Commons Logging 1.1.1 because JCL 1.1 throws exceptions when running in a Java applet sandbox. (This bug is already fixed: https://issues.apache.org/jira/browse/LOGGING-106) The roadmap shows 4 issues that are resolved in Commons Logging 1.1.1: https://issues.apache.org/jira/browse/LOGGING?report=com.atlassian.jira. plugin.system.project:roadmap-panel Is anybody working on JCL 1.1.1? Yes, I am. There are still some build issues left to solve before a release can be made. Thanks, Sean -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Running tests on earlier JVMs
Anyone? Dennis Lundberg wrote: Hi I'm trying to put together an an script that will do nothing more than run the tests for commons logging. It's going fairly well. A couple of issues that I found though that I need assistance with. Failing test The two test files in the security package both fail. These tests were run using a 1.3 jvm (see below why that is). Testsuite: org.apache.commons.logging.security.SecurityAllowedTestCase Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,016 sec - Standard Output --- testing permission:class java.util.PropertyPermission:(java.util.PropertyPermission sun.net.inetaddr.ttl read) - --- Testcase: testAllAllowed took 0,016 sec Caused an ERROR null java.lang.NoClassDefFoundError at java.lang.System.setSecurityManager0(System.java:239) at java.lang.System.setSecurityManager(System.java:208) at org.apache.commons.logging.security.SecurityAllowedTestCase.tearDown(SecurityAllowedTestCase.java:77) at org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:142) Testsuite: org.apache.commons.logging.security.SecurityForbiddenTestCase Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,015 sec Testcase: testAllForbidden took 0,015 sec Caused an ERROR null java.lang.NoClassDefFoundError at java.lang.System.setSecurityManager0(System.java:239) at java.lang.System.setSecurityManager(System.java:208) at org.apache.commons.logging.security.SecurityForbiddenTestCase.tearDown(SecurityForbiddenTestCase.java:80) at org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:142) Finding a (really old) platform to run on = We've said earlier that we should ideally run the tests using a 1.2 jvm. So I installed 1.2.2_17 on my Windows machine and started running tests. That didn't go to well. Here's what I get: Buildfile: build-testing.xml A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.addReference (Ljava/lang/String;Ljava/lang/Object;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.fireMessageLoggedEvent (Lorg/apache/tools/ant/BuildEvent;Ljava/lang/String;I)V': Interpreting method . Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.addCreatedTask (Ljava/lang/String;Lorg/apache/tools/ant/Task;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi init: [echo] Logging Wrapper Library 1.1.1-SNAPSHOT discovery: log4j12-test-warning: test: [echo] Test output can be found in directory G:\apache\jakarta\commons-logging/target/test-reports. [delete] Deleting directory G:\apache\jakarta\commons-logging\target\test-reports [mkdir] Created dir: G:\apache\jakarta\commons-logging\target\test-reports [echo] executing tests [**/*TestCase.java] A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.getDataTypeDefinitions ()Ljava/util/Hashtable;': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/DirectoryScanner.scan ()V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/util/FileUtils.createTempFile (Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;': Interpret ing method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/taskdefs/ProcessDestroyer.add (Ljava/lang/Process;)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) [junit] java.lang.IllegalMonitorStateException: current thread not owner [junit] at org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java, Compiled Code) [junit] at java.lang.Thread.run(Thread.java:479) And then it just hangs! This is done using ant
Re: [logging] Running tests on earlier JVMs
Henri Yandell wrote: So sounds like we need an older version of Ant. Like I said (way below) I tried using ant 1.5.4, but that didn't work because the build script is using features that were added to ant 1.6. Do the Security errors happen on more modern JVMs? Are they new tests? They work fine on 1.4.2 for me. They were added, by Simon, to test one of the bugs that were fixed in 1.1.1. On 7/19/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Anyone? Dennis Lundberg wrote: Hi I'm trying to put together an an script that will do nothing more than run the tests for commons logging. It's going fairly well. A couple of issues that I found though that I need assistance with. Failing test The two test files in the security package both fail. These tests were run using a 1.3 jvm (see below why that is). Testsuite: org.apache.commons.logging.security.SecurityAllowedTestCase Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,016 sec - Standard Output --- testing permission:class java.util.PropertyPermission:(java.util.PropertyPermission sun.net.inetaddr.ttl read) - --- Testcase: testAllAllowed took 0,016 sec Caused an ERROR null java.lang.NoClassDefFoundError at java.lang.System.setSecurityManager0(System.java:239) at java.lang.System.setSecurityManager(System.java:208) at org.apache.commons.logging.security.SecurityAllowedTestCase.tearDown(SecurityAllowedTestCase.java:77) at org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:142) Testsuite: org.apache.commons.logging.security.SecurityForbiddenTestCase Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,015 sec Testcase: testAllForbidden took 0,015 sec Caused an ERROR null java.lang.NoClassDefFoundError at java.lang.System.setSecurityManager0(System.java:239) at java.lang.System.setSecurityManager(System.java:208) at org.apache.commons.logging.security.SecurityForbiddenTestCase.tearDown(SecurityForbiddenTestCase.java:80) at org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:142) Finding a (really old) platform to run on = We've said earlier that we should ideally run the tests using a 1.2 jvm. So I installed 1.2.2_17 on my Windows machine and started running tests. That didn't go to well. Here's what I get: Buildfile: build-testing.xml A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.addReference (Ljava/lang/String;Ljava/lang/Object;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/Project.fireMessageLoggedEvent (Lorg/apache/tools/ant/BuildEvent;Ljava/lang/String;I)V': Interpreting method . Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.addCreatedTask (Ljava/lang/String;Lorg/apache/tools/ant/Task;)V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi init: [echo] Logging Wrapper Library 1.1.1-SNAPSHOT discovery: log4j12-test-warning: test: [echo] Test output can be found in directory G:\apache\jakarta\commons-logging/target/test-reports. [delete] Deleting directory G:\apache\jakarta\commons-logging\target\test-reports [mkdir] Created dir: G:\apache\jakarta\commons-logging\target\test-reports [echo] executing tests [**/*TestCase.java] A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/ComponentHelper.getDataTypeDefinitions ()Ljava/util/Hashtable;': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/DirectoryScanner.scan ()V': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/util/FileUtils.createTempFile (Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;': Interpret ing method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in : 'org/apache/tools/ant/taskdefs/ProcessDestroyer.add (Ljava/lang/Process;)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi
Re: [BeanUtils] Progressing towards a 1.8.0 release
Niall Pemberton wrote: BeanUtils is getting close to being ready for a 1.8.0 release IMO (under 10 issues left targeted for 1.8.0). http://issues.apache.org/jira/browse/BEANUTILS One thought I had was to do a 1.8.0 Beta release first to (hopefully) get wider testing - thoughts/opinions on that welcome. Niall, I saw a couple of commits suggesting a Maven 2 site. Are you aiming for that? If so I could go through it, if you want me to. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 snapshot repo?
Dain Sundstrom wrote: Are snapshot jars for commons (specifically commons-dbcp) published anywhere? I expected to see them here http://people.apache.org/repo/m2-snapshot-repository/ Almost none of the commons components use Maven 2 to build or publish their jar-files. So you won't find many commons-snapshots in the directory you mention. There is however a nightly-build script that runs and creates snapshots of all commons components, using their preferred build system (Ant, Maven 1 or Maven 2). You can find the artifacts it produces here: http://vmbuild.apache.org/~commons/nightly/builds/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511880 ] Dennis Lundberg commented on LOGGING-114: - Malcolm, Just so I understand your setup fully: Do you configure commons-logging in any way? Either via a system property or through the use of a commons-logging.properties file? If yes, please tell us how. Do you get any message from log4j, saying that it couldn't find its configuration file? If yes, what does it say. Are you sure that your code that uses commons logging is the one that causes log4j to be loaded? Or could it be that the other library of yours, that use log4j directly, is the first user? Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511556 ] Dennis Lundberg commented on LOGGING-114: - It is not the job of commons-logging to report on errors regarding the underlying logging implementations failure to configure itself. Commons-logging tries its best to send the messages, that the author of a library wants to log, to the logging implementation. Which logging implementation commons-logging sends these messages to is either A. configured in commons logging explicitly or B. found dynamically There is no way for the underlying logging implementation to tell commons-logging anything. So if the underlying logging implementation cannot configure itself correctly, as I understand is your situation here, commons-logging can't do much about it. It is the job of log4j, in this case, to tell you that it cannot load its configuration and from my experience it usually does. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sandbox] Remove stuff from sandbox-trunks
Hi Now that the sandbox-parent has moved away from sandbox-trunks, there isn't a whole lot left. I'd like to remove: http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/src/site/apt/index.apt since it is only an apt version of http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/sandbox/index.xml Having a separate site module for the 1-page-sandbox-site doesn't make a lot of sense. Then we have http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/buildall.sh which seems to have been superseded by the nightly build scripts in http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-nightly/trunk/ It also tries to run a Maven 1 build for the sandbox components. Many of them don't even have a Maven 1 project.xml file. So I say remove this script as well. All that is left now is a couple of license and notice files. Don't know if they are required here, but they don't seem to add much. Each component should have their own copies of these I imagine. Should I remove these files from sandbox-trunks? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
Phil Steitz wrote: +1 - need to do this anyway. On 6/29/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hmm, it seems that I spoke too soon. We need a place in subversion to put the tagged release. Since the pom is currently in sandbox-trunks there simply is no tags directory to put the release in. I propose that we move the sandbox parent out of sandbox-trunks and into a commons-sandbox-parent directory in commons proper. That would make it a sibling to commons-parent. Done. I also deployed the pom. There is one glitch with the release process for it though. When you do mvn release:perform the default goals for the deploy plugin is deploy, deploy:site. This means that it deployed the site for the sandbox-parent, which doesn't really exist. Anyway, I managed to copy the correct page from the production server before the site was synced from people. Just something to remember if we ever do another release of the sandbox parent. The only thing left in sandbox-trunks then would be the site for the sandbox, which consists of one (1) page. That could easily be moved down into a sandbox-site directory, that would be a sibling to the sandbox components. Thoughts? Dennis Lundberg wrote: The results are in: +1 Dennis Lundberg Torsten Curdt Niall Pemberton -0 Rahul Akolkar I will proceed with the release. Dennis Lundberg wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Remove stuff from sandbox-trunks
Brett Porter wrote: the purpose of the apt one was to start a proof of concept for converting the site to m2 (and yes, I haven't touched it in 18 months...) might be better to just move it to a branch or something? So moving it to http://svn.apache.org/repos/asf/jakarta/commons/commons-build/trunk/src/site/apt/sandbox/index.apt would be the right thing to do. commons-build contains the current Maven 1 site for commons. If/when the commons site is moved to Maven 2 this apt page would come into play again. - Brett On 04/07/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Now that the sandbox-parent has moved away from sandbox-trunks, there isn't a whole lot left. I'd like to remove: http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/src/site/apt/index.apt since it is only an apt version of http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/sandbox/index.xml Having a separate site module for the 1-page-sandbox-site doesn't make a lot of sense. Then we have http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/buildall.sh which seems to have been superseded by the nightly build scripts in http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-nightly/trunk/ It also tries to run a Maven 1 build for the sandbox components. Many of them don't even have a Maven 1 project.xml file. So I say remove this script as well. All that is left now is a couple of license and notice files. Don't know if they are required here, but they don't seem to add much. Each component should have their own copies of these I imagine. Should I remove these files from sandbox-trunks? -- Dennis Lundberg - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r553201 - /jakarta/commons/trunks-proper/KEYS
Do I also need to copy the new KEYS file to http://www.apache.org/dist/jakarta/commons/KEYS ? [EMAIL PROTECTED] wrote: Author: dennisl Date: Wed Jul 4 06:31:14 2007 New Revision: 553201 URL: http://svn.apache.org/viewvc?view=revrev=553201 Log: Adding my key. Modified: jakarta/commons/trunks-proper/KEYS Modified: jakarta/commons/trunks-proper/KEYS URL: http://svn.apache.org/viewvc/jakarta/commons/trunks-proper/KEYS?view=diffrev=553201r1=553200r2=553201 == --- jakarta/commons/trunks-proper/KEYS (original) +++ jakarta/commons/trunks-proper/KEYS Wed Jul 4 06:31:14 2007 @@ -1247,3 +1247,39 @@ G1bNzA4f =R1FQ -END PGP PUBLIC KEY BLOCK- +pub 1024D/AF5EC452 2006-08-25 +uid Dennis Lundberg (CODE SIGNING KEY) [EMAIL PROTECTED] +sig 3AF5EC452 2006-08-25 Dennis Lundberg (CODE SIGNING KEY) [EMAIL PROTECTED] +sub 2048g/73A843C2 2006-08-25 +sig AF5EC452 2006-08-25 Dennis Lundberg (CODE SIGNING KEY) [EMAIL PROTECTED] + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.4.6 (MingW32) + +mQGiBETvOwgRBADbar1BLaiJnuVnDEg0aej0Q01fdOnMB8e9fxe3TJZ266LLGljS +FNekCafvn52nx1KyVvkgdgMxqBfw70FKQXdrBBMzowuVAz1ZAcpDjkXeyKa3n/iW +J7VtuhdhIE/+rUiE1go2vkQhdIaad8om/kQDsovbgqxfX6eU2hWL51bJZwCg59D5 +0lXm78y8dlbvGaW0EVdgBesEAJ6rcNAA6rjsi7BUXNIpZe+KF/G/slcLJETgylmw +g0vquZP7n0fVhZZqB68zSmTcukxo36rd0jr9eSlhPj/6j9xs7gpk/UFWLWsziZDO +7kZVLv58v6ktK1Dk8u0F9o75pDBjgxOGR7VPVTblur1dIJ+U14ffJ9fn6wzKY8hx +hZrgA/wIpuJ/aSSns2ccKsErDMPRJP/TGygvrb1Mpfk3tLeGF7owI0sL8L8adKMK +g9kT/8VFoLzeSeEwUDOKDVm2xB/A5pazoUcgxLdwYs6g/XJzA7y4Sbfcac2W5IZ0 +4WGGUobf5Gp/b3NeVuff+V/2UN1YIr/hlOnBOMQDlNie4loQhrQ3RGVubmlzIEx1 +bmRiZXJnIChDT0RFIFNJR05JTkcgS0VZKSA8ZGVubmlzbEBhcGFjaGUub3JnPohg +BBMRAgAgBQJE7zsIAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQM81nM69e +xFLJMQCdF7zrx4SMk6JW9nZSTwHvMR3eNsYAmgKCy/Yq08tAIn9HSddspNIBeXpS +uQINBETvOyQQCACL7yutx3rvWz+FiUfeaA209uZvopjbVrE4oiTCrBV0Wgbmds7l +Kyxb3136dqPpQMn7H6ZsXzNNv7S4WASceWuGMndw5LO5I9nZRj7lfUYmfq2Qc3h7 +2SfJDOgAUo2gJudgfNsyQQTIqnOIPNzIC4UcQqnUmgeFcPjrl5f1v9EVxJppeaO2 +2IafxuMaGACJFcPkYA/8EuQP6dbSmxNstOtoncY/69WRrWTCcM3SLvK+m91KOe02 +LnGz62WMC149uziiBZAF5BXfEUPsbBp1WEf/fIdGUhK4RQ1E78MwrhgWwNiNT7No +EuT6UORrfxCcAiNBjGF7x7KkHwS6I5qsNTd3AAMFB/4oFl87H+IK+49xXcsWJSx4 +04BsXrFFuYCglqqXEjLcTx9fSiK4Sng5UfPxTTYEuwG0fgsimISPb+DIQvHQ/bka +FLdLlS1+Q29wbYB81k602VZbjQYjqCPYrHImo5pcCR9b5Zw8muB36Af70mknNV+h +MnKqSrqvrWvpQ2iBAjaeuGug+O/bblPIDzEW5PJKF2FGjRagw/y2pnEOJZewbN0V +yI9osncY/B69VPh0KlsK9HZceH+9W7K3ALanzg79auH1NShPfld7q9jbOSAaD1p2 +Fd2PjswNkbQFaoWzhMJv7J9Dg9nEuBx09pPNvf2b1mP15IhOdt1nRmhAoheSn9ys +iEkEGBECAAkFAkTvOyQCGwwACgkQM81nM69exFINlgCeJWEyBlANuDYAZ3uxYEC9 +MrUXwYoAnjCUFpe/kmx0wzIm9Bz7G2NeDs5U +=OmtA +-END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Running tests on earlier JVMs
1.5.4 it didn't work at all because we use propertyset: BUILD FAILED file:G:/apache/jakarta/commons-logging/build-testing.xml:171: Unexpected element propertyset I don't know the jvm requirements for the different ant versions. I'll be checking in the ant script shortly... Any pointers to what might be going wrong here is greatly appreciated. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorganising JIRA - Switching to new category
Martin van den Bemt wrote: If no one objects I will create a new category in JIRA called commons and move all commons projects under that category.. A category is that what is found in the right hand drop-down under All Projects on the start page? It says Show All as the default. https://issues.apache.org/jira/secure/Dashboard.jspa -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorganising JIRA - Switching to new category
The two lists seem to be the same. +1 to move to a Commons category. Martin van den Bemt wrote: See https://issues.apache.org/jira/secure/BrowseProject.jspa, Jakarta section. This contains all commons projects.. I already created the commons category and like to move the commons projects over there. If people adjusted their dashboard to eg just show the jakarta category they will miss some projects... Mvgr, Martin Dennis Lundberg wrote: Martin van den Bemt wrote: If no one objects I will create a new category in JIRA called commons and move all commons projects under that category.. A category is that what is found in the right hand drop-down under All Projects on the start page? It says Show All as the default. https://issues.apache.org/jira/secure/Dashboard.jspa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Release commons-sandbox-parent 1
The results are in: +1 Dennis Lundberg Torsten Curdt Niall Pemberton -0 Rahul Akolkar I will proceed with the release. Dennis Lundberg wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
+1 Stephen Colebourne wrote: I also would strongly prefer to use this opportunity to create a commits list and an issues list. Commons is big enough to need it, and it would increase the signal to noise on the main list, especially when searching. Stephen - Original Message From: Martin van den Bemt [EMAIL PROTECTED] Agree with Niall.. Archives are pretty much unusable with commits messages and jira issues.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
+1 from me Dennis Lundberg wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
Hmm, it seems that I spoke too soon. We need a place in subversion to put the tagged release. Since the pom is currently in sandbox-trunks there simply is no tags directory to put the release in. I propose that we move the sandbox parent out of sandbox-trunks and into a commons-sandbox-parent directory in commons proper. That would make it a sibling to commons-parent. The only thing left in sandbox-trunks then would be the site for the sandbox, which consists of one (1) page. That could easily be moved down into a sandbox-site directory, that would be a sibling to the sandbox components. Thoughts? Dennis Lundberg wrote: The results are in: +1 Dennis Lundberg Torsten Curdt Niall Pemberton -0 Rahul Akolkar I will proceed with the release. Dennis Lundberg wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Rahul Akolkar wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. snip/ I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. So I stepped up to do the release. If I don't mind doing the job - why should you care? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Rahul Akolkar wrote: On 6/24/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. snip/ I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. snip/ See line below, and less importantly, some comments above. I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. snap/ imagine? I can only go by reasons stated in this thread (Carlos' and Phil's subsequent posts do not have a new reason IMO). Here is the message that made me start this thread. http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200706.mbox/[EMAIL PROTECTED] Apparently he is working on commons CSV, so if releasing this pom can help him do that then it's a Good Thing TM. It might even help CSV to get promoted out of the sandbox. So I stepped up to do the release. If I don't mind doing the job - why should you care? snap/ Because this is a Commons release. Because (as a more general statement beyond the ASF workings) I believe that merely having someone available to do something, does not by itself, make doing that thing worthwhile. Because (in terms of the ASF workings) do-ocracies do not imply that others should not care about what you are doing when its about releasing artifacts. You misread my previous comment. I was not talking about *what* is being done, but *who* is doing it. You said that releasing the sandbox pom will require work, meaning someone has to do it. I then said that I'll do it. Can we just leave it at that. If we focus on *what* is being done instead. Can you tell me what is wrong with releasing the sandbox parent? Besides the fact that it requires someone has to do the actual work. Because we will have to: * Release periodically Not necessarily. The consensus when we started with Maven 2 poms was that we try to keep the parent(s) stable. Try something out in a component first and it's deemed good for all, then we'll move it to the parent. In my opinion the parent defines the common build process that all components should use. And that should not change that often. - Needs process cycles: RMs, votes (thanks for your cycles on this one) Like I said I'm volunteering to be RM for this release. If you don't have the cycles to check the release, you are perfectly entitled to refrain from voting. - Who knows how often this will have to happen (lesser the better) Agreed. * Update all sandbox component POMs to keep parent versions in sync etc. Again this doesn't have to be a lot of work. Once we get the first release of the sandbox pom out, it is necessary to update the poms of all sandbox components at least once. Again I'm volunteering here. I vote: -0 (non-binding) -Rahul -- Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-sandbox-parent 1
Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Phil Steitz wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 6/23/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. snip/ I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more comfortable), especially given that we are *not* releasing any sandbox jars. Yes, I agree. A stable sandbox-parent will make it easier for components to move out of the sandbox and into commons proper. I have a couple of comments on the pom itself before adding my +1, though. Sorry if I missed this before, but I don't see why we should include the reports that are added to the sandbox POM. The ones in the parent are the only ones that I see as *always* needed. I have thought about suggesting that we drop the RAT report from there. At different stages of development, different reports make sense and I personally prefer to maintain the list per component, other than things like javadoc that you are never going to want to turn off. When I started working on the M2 poms I tried to find a least common denominator of the reports that were on the M1 sites. Some reports are valid for all components while others might only be of interest to some. Out aim should be to establish which plugins are mandatory (goes into the parent) and which are voluntary (goes into a component's pom). The 3 reports that are in the sandbox parent seems like good candidates for the sandbox parent to me: - Taglist - helps track things that are left to do before a release - Cobertura - makes sure the tests coverage is good enough (this one might move to commons-parent) - PMD - checks that the code doesn't smell bad (this one might also move to commons-parent) Another minor comment is that it might be better to move the pom and site into a sandbox-parent in svn. This obviously has nothing to do with the release vote. Yes, that was on my todo-list earlier, but I couldn't find enough time back then. I might have a go at that after this release. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
Well, that's just my point. They shouldn't have to put in an effort because it's a point release - it should be a drop-in replacement. Henri Yandell wrote: Not a problem though. Anyone who has that setup will definitely put in the effort to find out why it's deprecated and adjust their code. Hen On 6/21/07, Dennis Lundberg [EMAIL PROTECTED] wrote: I can see one reason for not deprecating stuff in a point release. If someone is really concerned about deprecation warnings, I would imagine that they could set up their build system to fail if there are deprecation warnings. A point release should be a drop in replacement. So if you add deprecations to a point release it could, in this scenario, possibly fail someone's build if they upgrade commons-io from 1.3.1 to 1.3.2. Henri Yandell wrote: Sorry for being slow on this one. I'm with Jochen and Joerg in not getting why deprecation would indicate a minor release and not be allowed in a bugfix release. Sure it sucks that a new class is immediately being deprecated, but better to get such things out there now rather than waiting. Hen On 6/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. Phil - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
+1 Niall Pemberton wrote: Rahul Akolkar is an existing Jakarta PMC member and Commons Committer. He was against the proposal for Commons to become a TLP. Since that vote passed and the Apache Board has now passed the resolution for Commons to become a TLP I would like to invite Rahul to join the new Apache Commons PMC. It would be a tragedy IMO if we lose valuable members of the Commons Community just because they were originally against the TLP proposal. [ ] +1, don't let Rahul get away - lets try to get him to join the new PMC [ ] -1, no leave him out Niall P.S. Anyone else in the same situation, then I suggest we do the same - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Simon Kitching to join the Apache Commons PMC
+1 Niall Pemberton wrote: Simon Kitching is an existing Jakarta PMC member and Commons Committer. He was against the proposal for Commons to become a TLP. Since that vote passed and the Apache Board has now passed the resolution for Commons to become a TLP I would like to invite Simon to join the new Apache Commons PMC. It would be a tragedy IMO if we lose valuable members of the Commons Community just because they were originally against the TLP proposal. [ ] +1, don't let Simon get away - lets try to get him to join the new PMC [ ] -1, no leave him out Niall P.S. Anyone else in the same situation, then I suggest we do the same - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
I can see one reason for not deprecating stuff in a point release. If someone is really concerned about deprecation warnings, I would imagine that they could set up their build system to fail if there are deprecation warnings. A point release should be a drop in replacement. So if you add deprecations to a point release it could, in this scenario, possibly fail someone's build if they upgrade commons-io from 1.3.1 to 1.3.2. Henri Yandell wrote: Sorry for being slow on this one. I'm with Jochen and Joerg in not getting why deprecation would indicate a minor release and not be allowed in a bugfix release. Sure it sucks that a new class is immediately being deprecated, but better to get such things out there now rather than waiting. Hen On 6/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. Phil - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging classloading
Hi Diagnostics, that was introduced in Commons Logging 1.1, is a great way to troubleshoot classloading issues: http://jakarta.apache.org/commons/logging/troubleshooting.html#Using_JCL_Diagnostics Dennis Thrysøe wrote: Hello, I'm having trouble with commons-logging in a scenario where I am embedding tomcat's jasper in another servlet container. I keep getting the exception about commons-logging being available from multiple classloaders. This seeems to be caused by LogFactory using the ContextClassLoader instead of the classloader that loaded Log and LogFactory. (In this case the classloader that loaded jasper. Therefore I cannot seem to get my JSPs loaded and executed with my webapp classloader, as commons-logging is distributed with both the servlet container and the webapp in question. Is there any way to force commons-logging to use a specific classloader, or any other good ideas on how to use jasper with a webapp that contains commons-logging? Thanks, -dennis --- The information in this email is confidential and may be legally protected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: centralized KEYS file?
Ben Speakmon wrote: Would it be a good idea to have one centralized KEYS file for all commons developers? It'd be easier to update, delete or revoke any single key and remove a lot of duplication. I was reviewing the IO 1.3.2 RC and I couldn't find the key Jochen used to sign the release tarballs. I don't see any reason offhand why it shouldn't be in the same place as the keys to verify any other release. Thoughts? I like the idea of a single KEYS file for commons. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] beanutils logging failed.
Phil Steitz wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070612/beanutils.log http://vmbuild.apache.org/~commons/nightly/logs//20070612/logging.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Now I'm confused. From what I can tell by the log for logging, all the builds were successful. Might be something wrong with the nightly script. Will have a look. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] beanutils logging failed.
Dennis Lundberg wrote: Phil Steitz wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070612/beanutils.log http://vmbuild.apache.org/~commons/nightly/logs//20070612/logging.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Now I'm confused. From what I can tell by the log for logging, all the builds were successful. Might be something wrong with the nightly script. Will have a look. Found it. On line 280 we do this: if [ `ls target/commons-$component*.jar` ] # build succeeded With commons logging there is more than one such jar file, which makes for an unpredictable response from ls. We should probably do something along the lines of this instead: if [ -f target/commons-$component*.jar ] # build succeeded I'll let one of the unix gurus figure that the exact details, since I don't have an environment set up to try this properly. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] logging failed.
I'm unsure why, but it seems that Commons Logging has been built using Maven 1 up until June 9. even though it was listed in the nightly_proper_maven2_list.txt file. When Ben added Email to the list of Maven 2 builds, it triggered Logging to be built with Maven 2 as well. Hopefully my patch to the nightly build script will fix the nightly M2 build of Logging. Phil Steitz wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070611/logging.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] No pom for logging-api
I put one together before. The plan was to release it together with logging 1.1.1, but that sort of stalled. It's available in svn and all that needs to be changed for the 1.1 release is currentVersion, from 1.1.1-SNAPSHOT to 1.1. http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/commons-logging-api.pom Henri Yandell wrote: I thought it was only intended for Tomcat or someone like that. Generally people should just depend on the commons-logging and not worry about the commons-logging-api. I guess it's the same as the commons-logging pom, but without the dependencies; so I'll get to work on that. Hen On 6/2/07, Torsten Curdt [EMAIL PROTECTED] wrote: It is frowned on to use? ...but anyway. If there is an artifact it wouldn't hurt to release a pom for it IMO. cheers -- Torsten On 01.06.2007, at 19:49, Henri Yandell wrote: http://jira.codehaus.org/browse/MEV-461 Should we release a logging-api pom there, or do we even want logging-api to be on the maven repository? Hen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3 (take 2)
+1 Dennis Lundberg wrote: This is the second attempt to release version 3 of commons-parent. The revision to vote on is 542829. Changelog: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?r1=542829r2=511592diff_format=h [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release commons-parent 3 (take 2)
Here are the results of this vote: +1 from: Jochen Wiedmann Rahul Akolkar Niall Pemberton Torsten Curdt Phil Steitz Dennis Lundberg I will proceed with the release. Dennis Lundberg wrote: This is the second attempt to release version 3 of commons-parent. The revision to vote on is 542829. Changelog: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?r1=542829r2=511592diff_format=h [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
Torsten Curdt wrote: snip rant I think we need to establish a little bit more of an agile edge here at commons. Boy we suck at release votes. /rant /me ducks cheers -- Torsten I agree with you on that. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-parent 3 (take 2)
This is the second attempt to release version 3 of commons-parent. The revision to vote on is 542829. Changelog: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?r1=542829r2=511592diff_format=h [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
I have a couple of changes that I'd like to get in before the release: 1. Remove the build/pluginManagement sections from the profiles, as those are not needed. These were added after the last release, when Niall updated to the newer sources plugin. 2. Lock down the version for the javadoc and jxr plugins I'll hold my commit until I get someones approval, as this is an ongoing vote. I volunteer to do the actual release of the pom. Jochen Wiedmann wrote: I don't know how to deal with this thread. The discussion was related to further improvement of the commons-parent. IMO, this is far from blocking the proposed release. (As I wrote, in particular in the case of the commons-parent, nothing prevents us from further releases real soon, if the discussed improvements have been made.) Nevertheless, only Niall confirmed a release. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Bugzilla id 33167
Srinath Narasimhan wrote: Hi, I had originally filed a bug/enhancement for Commons DBCP which I am trying to get added to the main build. http://issues.apache.org/bugzilla/show_bug.cgi?id=33167 Please see: https://issues.apache.org/jira/browse/DBCP-61 I could not find that in the new jira issue tracker. Could you tell me if there is any intention of moving this into the main build? Thanks Srinath. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Bugzilla id 33167
In JIRA the Fix Version/s indicates which version a fix for an issue is scheduled to be included. In this case it is set to 1.3. No release date has been set for that version. Srinath Narasimhan wrote: Thanks for the quick response. The next question is it going to get added in any release ? -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 4:38 PM To: Jakarta Commons Developers List Subject: Re: [DBCP] Bugzilla id 33167 Srinath Narasimhan wrote: Hi, I had originally filed a bug/enhancement for Commons DBCP which I am trying to get added to the main build. http://issues.apache.org/bugzilla/show_bug.cgi?id=33167 Please see: https://issues.apache.org/jira/browse/DBCP-61 I could not find that in the new jira issue tracker. Could you tell me if there is any intention of moving this into the main build? Thanks Srinath. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r529805 - in /jakarta/commons/proper/jci/trunk/src/site: site.xml xdoc/faq.xml
] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r529805 - in /jakarta/commons/proper/jci/trunk/src/site: site.xml xdoc/faq.xml
Rahul Akolkar wrote: On 4/23/07, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: tcurdt Date: Tue Apr 17 16:46:08 2007 New Revision: 529805 URL: http://svn.apache.org/viewvc?view=revrev=529805 Log: rephrased a few o=paragraphs, fixed broken links Modified: jakarta/commons/proper/jci/trunk/src/site/site.xml jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml Modified: jakarta/commons/proper/jci/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/src/site/site.xml?view=diffrev=529805r1=529804r2=529805 == --- jakarta/commons/proper/jci/trunk/src/site/site.xml (original) +++ jakarta/commons/proper/jci/trunk/src/site/site.xml Tue Apr 17 16:46:08 2007 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=ISO-8859-1? +?xml version=1.0? project name=Jakarta Commons JCI bannerRight nameJakarta Commons JCI/name @@ -7,10 +7,10 @@ /bannerRight body menu name=Jakarta Commons JCI -item name=About href=index.html/ -item name=Usage href=usage.html/ -item name=FAQ href=faq.html/ -item name=Downloads href=downloads.html/ +item name=About href=http://jakarta.apache.org/commons/jci/index.html/ +item name=Usage href=http://jakarta.apache.org/commons/jci/usage.html/ +item name=FAQ href=http://jakarta.apache.org/commons/jci/faq.html/ +item name=Downloads href=http://jakarta.apache.org/commons/jci/downloads.html/ This should not be necessary. If you use full URLs like this, you won't be able to navigate a locally built site correctly. What kind of problems did you run into? You stated broken links as the reason for the change in the commit message. snip/ Apparently, the site.xml inheritance does not tweak relative URLs as needed (and expected). -Rahul So, the sub modules of jci are getting menu links that doesn't work? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Niall Pemberton wrote: On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Yea, that happened for me too. I dived into the general JIRA settings and found that nobody was allowed to change the reporter of an issue. I have changed this now so that jira-administrators can do it. Here's what I did to get rid of my old user: Filter all issues reported by old user Bulk change - transition - reopen (for all closed issues) Bulk change - edit - set reporter to new user Bulk change - transition - close Delete old user One thing to keep in mind though, when you reopen an issue the resolution gets reset. So you need to remember the resolution for each issue :-( I'll investigate further. Do you want me to move all issues from [EMAIL PROTECTED] to niallp for you? Niall I suggest hassling Dennis to do it :) Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Niall Pemberton wrote: On 4/5/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 4/5/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Username: [EMAIL PROTECTED] ah, so not the dennislundberg one. :) I was a bit confused at that one not being a jakarta developer. While you're in there, you should delete your doppelganger and assign its reported issue over to your real user. How do you do that - I also have an old id. As JIRA admin you find it in the user browser and select delete. I got a warning when I did that saying This user cannot be deleted at this time because there are issues assigned to them, they have reported issues, or they are currently the lead of a project Yea, that happened for me too. I dived into the general JIRA settings and found that nobody was allowed to change the reporter of an issue. I have changed this now so that jira-administrators can do it. Here's what I did to get rid of my old user: Filter all issues reported by old user Bulk change - transition - reopen (for all closed issues) Bulk change - edit - set reporter to new user Bulk change - transition - close Delete old user One thing to keep in mind though, when you reopen an issue the resolution gets reset. So you need to remember the resolution for each issue :-( I'll investigate further. Do you want me to move all issues from [EMAIL PROTECTED] to niallp for you? Yes please, that would be great if you could. Niall Done, I also removed your old account. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal: move build to m2
Phil Steitz wrote: As we ramp up to a 1.2 release, I think its a good idea to move to Maven 2 as the standard build. That means deprecating the m1 build (leaving in the 1.2 release, if possible), moving the site and nightlies, etc. Lets view this as lazy consensus - i.e., scream now or forever hold your peace. Assuming no objections in the next couple of days, we can start battling - er, I mean working - with m2. Phil +1 Let me know if you need any help... -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
+1 Henri Yandell wrote: I think the end should be nigh for Jakarta (those on private@ will have seen a thread in which I side-topic'd with the feeling that the end should be nigh for Jakarta). Previously I've suggested that Commons should flatten into Jakarta and that Jakarta should become a general 'Java components' project; however there are some negatives to that that I think are critical. Firstly, it leaves the future Jakarta with a lot of dead projects that are going nowhere. That's not going to change in the short to medium term, so it just becomes a millstone for the project's neck. Secondly, the Jakarta PMC will always remain a big group of people who care about the brand name and the various legacies, rather than a small focused PMC. I think this isn't desirable for any active community that are a part of Jakarta currently - trying to have a PMC that are acting as one community when not being one community doesn't work. Thirdly, I think by being here we are helping to delay the inevitable and keeping the old, broken umbrella going. Moving to TLP will help things move along, and will provide a place for things to move to. So with that said - I'd like to propose that we move to commons.apache.org. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Niall Pemberton wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/4/07, Niall Pemberton [EMAIL PROTECTED] wrote: Can anyone say what the usual practice is for assigning groups/roles for people once they become a committer? Theres a Jakarta Developer group - it gets you committer role for Commons Lang and JCI but strangely nothing else. Would be simpler if it was documented somewhere. Yeah, it's a bit of a mess. The new JIRA release added the concept of project roles - which is great for many Apache projects. However we want to be able to grant project roles to N JIRA projects at the same time and it doesn't help with that. So we need to stay on the old system of assigning a group to the project, rather than messing around with roles too much (though the roles stuff does allow for permission to be granted in the short term while a request for being added to the group is made). Jeff did a bulk reconfiguration of JIRA and it was only afterwards that I understood sufficiently that it won't help us much. So now we need to go ahead and add the jakarta-developers group to each project role administrator bit. *pondering* Might be eaier to setup a Jakarta Permission that sets the group as having read/write by default, instead of using the Standard Permission and doing lots of configuring. That should be doable I think. I bow to your greater (and my lack of) Jira knowledge - but seeing that Jakarta Devs causes someone to automatically get JCI and LANG commiter role - shouldn't we just have two groups that do the same for all Commons. I was thinking something like Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects This sound good to me. Then as Henri said, we should set up a new Permission Scheme. We now have a JIRA installation at my day job, so I have taken some time to experiment with groups and permissions. If you feel comfortable with me being a JIRA admin here, I could try to set this up. Niall Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira Groups and Roles
Henri Yandell wrote: On 4/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: Commons Committer group -- commiter role on all components Jakarta PMC -- pmc role on all jakarta sub-projects This sound good to me. Then as Henri said, we should set up a new Permission Scheme. We now have a JIRA installation at my day job, so I have taken some time to experiment with groups and permissions. If you feel comfortable with me being a JIRA admin here, I could try to set this up. Sure. What's your login? Hen Username: [EMAIL PROTECTED] Full Name: Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [parent-pom] versions
Henri Yandell wrote: On 4/2/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 02.04.2007, at 09:49, Stephen Colebourne wrote: Henri Yandell wrote: Personally I think we should only have the plugins defined if the release jar itself needs them for stability. ...and then have the project define the reports they want? Sorry - plugin versions. Or is that the problem now, you can't use a version that's tied to your Maven installation because said plugin is not a part of the core system? Speaking of Maven 2 here. The Maven installation doesn't contain any plugins, they are downloaded when they are needed. Unless you specify the version of a plugin that you want to use, you get the latest version. This in turn is found in the metadata in the repository, from which the plugin is downloaded. Otherwise we just deal with whatever pain Maven is throwing everyone's way and yell at them to fix. Er why? It is not our job to be gump and test commons builds against the latest random collection of maven plugins. Don't get that either. I want to make our life's less painful. Specifying the versions helps a great deal with that. Maybe I'm being Maven1 minded. I don't think we should be wasting time figuring out which plugin version is good and which is bad for the many many plugins that are just there to stick crap on the site. Then again - it's in the central pom and not each project so not a biggy I guess. Go for it. Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [parent-pom] versions
Torsten Curdt wrote: I've noticed that the plugin versions are not specified in the commons parent pom. From my experience this is a *really* bad idea as maven then picks the most recent from local repository. Which again can easily lead to inconsistent site builds across the team. So if no one objects I will add the latest version information to the plugins. For a reproducible site build. cheers -- Torsten +1 This is a good idea, and also a recommended practice. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for Logging 1.1 to run in applets.
The upcoming 1.1.1 release has fixed these issues.
Pavel Vlasov wrote:
Hello,
Today I tried to use HttpClient from an applet and I run into a quite a
number of problems with commons logging version 1.1. Searching internet and
Commons Wiki didn't yield any valuable result.
Thus, I had to modify LogFactory.java around line 320, I added a catch block
for SecurityException, which was missing. Please find code below:
String storeImplementationClass;
try {
storeImplementationClass =
System.getProperty(HASHTABLE_IMPLEMENTATION_PROPERTY);
} catch (SecurityException e) {
storeImplementationClass = null;
}
Also I had to create my own implementation of LogFactory because default
implementation invokes getClasLoader() method, which is prohibited in
Applets.
Here is the no-op implementation:
public class NoOpLogFactory extends LogFactory {
private Log log = new NoOpLog();
private Map attributes = new HashMap();
public Object getAttribute(String name) {
return attributes.get(name);
}
public String[] getAttributeNames() {
return (String[]) new
ArrayList(attributes.keySet()).toArray(new String[attributes.size()]);
}
public Log getInstance(Class clazz) throws LogConfigurationException
{
return log;
}
public Log getInstance(String name) throws LogConfigurationException
{
return log;
}
public void release() {
// Nothing to release
}
public void removeAttribute(String name) {
attributes.remove(name);
}
public void setAttribute(String name, Object value) {
attributes.put(name, value);
}
}
I've installed it by specifying class name in a configuration file in
META-INF/services in one of my jars
Please review these changes and incorporate into the library if appropriate.
Also please let me know if there is another way to make commons logging work
in applets.
---
Best regards, Pavel.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1 release?
Henri Yandell wrote: Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly ready and just needs to be rolled and voted on. Hen I've been meaning to do this for a long time. There are a couple of questions to consider before rolling the release: 1. How should it be built? Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel confident about in it now. Was kind of hoping that logging-1.1.1 would be the first commons release to use Maven 2, but I can be persuaded. 2. If we decide to use Maven 2 we should really change the groupId. This needs to be carefully thought through. Anyway, I'm here to assist in any way can, if you want to be release manager for this. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Release commons-parent 2
Dennis Lundberg skrev: It is time to release a new version of commons-parent. There are a couple of pending releases that would like to use the features in this new version. Here's a run-down on the changes that has been made since version 1 was released: A site.xml file has been added to enable Maven 2 generated sites. It is using the new commons-skin to give the sites the commons look-and-feel. Changes to pom.xml: - Add maven-jar-plugin with locked down version. Also add the necessary entires into the manifest. - Add maven-gpg-plugin used to sign the artifacts during the release. - Add standard set of reports: javadoc, jxr, surefire, jdepend. - Add rat-maven-plugin. - Configure maven-site-plugin to exclude the special Maven 1 files navigation.xml and changes.xml from site generation. - Make the deployment protocol configurable, uses scp by default. - Add snapshot repo for rc profile. - Compile properties are now set to 1.3 as a default value. It can be overridden by components using another version. The revision of the last change is 507361. The vote will be open for the usual 72 hours. Here's my +1 Here are the results of this vote:: +1 from: Niall Pemberton (with a comment to remember to update the version in the appropriate places) Henri Yandell Jochen Wiedmann Dennis Lundberg I will proceed with the release. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-parent 2
It is time to release a new version of commons-parent. There are a couple of pending releases that would like to use the features in this new version. Here's a run-down on the changes that has been made since version 1 was released: A site.xml file has been added to enable Maven 2 generated sites. It is using the new commons-skin to give the sites the commons look-and-feel. Changes to pom.xml: - Add maven-jar-plugin with locked down version. Also add the necessary entires into the manifest. - Add maven-gpg-plugin used to sign the artifacts during the release. - Add standard set of reports: javadoc, jxr, surefire, jdepend. - Add rat-maven-plugin. - Configure maven-site-plugin to exclude the special Maven 1 files navigation.xml and changes.xml from site generation. - Make the deployment protocol configurable, uses scp by default. - Add snapshot repo for rc profile. - Compile properties are now set to 1.3 as a default value. It can be overridden by components using another version. The revision of the last change is 507361. The vote will be open for the usual 72 hours. Here's my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-63) Maven 2 pom.xml
[ https://issues.apache.org/jira/browse/EMAIL-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473244 ] Dennis Lundberg commented on EMAIL-63: -- You need to bump the version of commons-parent from 1 to 2-SNAPSHOT. That will make the site work. Maven 2 pom.xml --- Key: EMAIL-63 URL: https://issues.apache.org/jira/browse/EMAIL-63 Project: Commons Email Issue Type: Improvement Affects Versions: 1.1 Reporter: Ben Speakmon Fix For: 1.1 Attachments: pom.patch, pom.xml, pomv2.xml, pomv3.xml Copied more or less directly from the one just checked in for pool; appropriate substitution made for project info, contributors, dependencies, and test cases. One problem: dumbster-SNAPSHOT is not in any Maven 2 repository that I know of and must be manually installed. Everything else seems to work fine. Attaching file shortly... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
Thanks for bringing this up Henri. Here's my view on this: 1. Maven 1 builds stay as commons-foo (like you said) 2. Maven 2 builds change to org.apache.commons once the component moves to using M2 to build the component *and* putting the artifacts into the M2 repo. This should be done one component at a time - not all at once. As for how to handle relocations I'll talk to the Maven community to get some more feedback. Henri Yandell wrote: Second try - having had it explained to me on #maven why relocating is important [so commons-lang:commons-lang 2.1 and org.apache.commons:commons-lang 3.0 are considered the same and a transitive clash can be recognized]. So, second suggestion: We declare a point after which we won't do any more m1 releases. We'll move wholesale over to m2. On that day (or as near as we can), we run a script on all commons-*/ to do the relocation for all of them ( http://maven.apache.org/guides/mini/guide-relocation.html ). I know I'm clueless - so please change this to whatever the clueful one is. I think it's time for us to drop m1 and move to m2. Hen On 2/12/07, Henri Yandell [EMAIL PROTECTED] wrote: This has come up a number of times and I'm not sure if the last time saw an agreement. My understanding is that we want to move to org.apache.commons. We've dabbled with the idea of relocating, but it sounds like that is more trouble than it's worth. Are we now of the view that: 1) Maven-1 builds stay as commons-foo 2) Maven-2 builds all set the groupId to org.apache.commons ?? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Congratulations to Craig McClanahan...
...for making it into Java Developers Journal's The Top 150 i-Technology Heroes of Today and Yesteryear Read all about it here: http://java.sys-con.com/read/33.htm -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Releasing commons-parent pom version 2
Henri Yandell wrote: On 2/10/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 2/10/07, Niall Pemberton [EMAIL PROTECTED] wrote: Any reason not to release version 2 of the commons-parent pom? Niall, I'd like to throw in my experiences from releasing the commons-fileupload project. In particular, I would like to add the rat-maven-plugin and the gpg-maven-plugin. Would it be ok to wait for that? If not, I may as well add them to 3-SNAPSHOT later on. However, I'd volunteer for 3 then, and not for 2. :-) They're not in the fileupload pom.xml - are they on SNAPSHOT versions (knowing that both are kind of new, so not sure if they have fixed versions)? The maven-gpg-plugin has had an alpha release, 1.0-alpha-1, and has been used to release a couple of M2 plugins. The rat-maven-plugin is still unreleased as far as I can tell. The one thing I think we should avoid is allowing SNAPSHOT versioning into our build system (or at the least it should block a release if we're dependent on a SNAPSHOT plugin). Agreed, the M2 release cycle will actually fail if it finds any SNAPSHOT dependency in the dependency chain. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Releasing commons-parent pom version 2
Jochen Wiedmann wrote: On 2/12/07, Niall Pemberton [EMAIL PROTECTED] wrote: There is also a ongoing vote on the maven dev list to release maven-source-plugin - which should fix the MSOURCES-6 issue and allow us to specify NOTICE/LICENSE as resources elements rather than using the antrun plugin. I believe that will also mean that NOTICE/LICENSE will then automatically be added to the sources jar as well. Good point. I don't know whether that will actually work, but you can be sure that I'll check it. Getting rid of the antrun hack would be nice. There is a 2.0.3-SNAPSHOT of the maven-sources-plugin available in the snapshot-repo, that has this fix in it. I didn't follow the creation of the antrun parts of our pom.xml, so I'm not sure what it is that needs to be tested. If someone can give some specifics I can test it. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Releasing commons-parent pom version 2
Jochen Wiedmann wrote: On 2/12/07, Dennis Lundberg [EMAIL PROTECTED] wrote: There is a 2.0.3-SNAPSHOT of the maven-sources-plugin available in the snapshot-repo, that has this fix in it. I didn't follow the creation of the antrun parts of our pom.xml, so I'm not sure what it is that needs to be tested. If someone can give some specifics I can test it. That's easy. - Reapply Nialls patch that created revision 493942 (and has been reverted with revision 494097). - Run mvn package and check, that NOTICE.txt and LICENSE.txt are indeed copied to target/META-INF/classes. - If that works, run mvn -Prelease package. Watch that the -sources jar file is being built. If the build is successfull, then everything's fine. If the jar file is growing forever and the build doesn't stop, then the bug is still present. Jochen I tried this on fileupload, and it is working fine for me. A vote to release maven-sources-plugin 2.0.3 was started on Feb 11, and is open for 72 hours. I'll await that release and then make the necessary changes to commons-parent. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Releasing commons-parent pom version 2
Niall Pemberton wrote: On 2/10/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Niall Pemberton wrote: Any reason not to release version 2 of the commons-parent pom? No, I was going over what had changed the other night - nothing controversial. If not any volunteers? I'll put together a list of changes and call for a vote. Great - the only thing from memory that I think we talked about before that hasn't been done is adding a set of standard reports. The sandbox pom has the following: maven-javadoc-plugin maven-jxr-plugin maven-pmd-plugin maven-surefire-report-plugin cobertura-maven-plugin jdepend-maven-plugin taglist-maven-plugin IMO we should at least include the jdepend, javadoc, surefire and jxr reports to commons-parent. Niall That sounds reasonable to me. I like the concept of trying out new plugins and configurations, either in the sandbox or in an individual component, and then moving them to commons-parent if they work well. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Releasing commons-parent pom version 2
Niall Pemberton wrote: Any reason not to release version 2 of the commons-parent pom? No, I was going over what had changed the other night - nothing controversial. If not any volunteers? I'll put together a list of changes and call for a vote. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Releasing commons-parent pom version 2
Jochen Wiedmann wrote: On 2/10/07, Niall Pemberton [EMAIL PROTECTED] wrote: Any reason not to release version 2 of the commons-parent pom? Niall, I'd like to throw in my experiences from releasing the commons-fileupload project. In particular, I would like to add the rat-maven-plugin and the gpg-maven-plugin. Would it be ok to wait for that? If not, I may as well add them to 3-SNAPSHOT later on. However, I'd volunteer for 3 then, and not for 2. :-) I haven't used the rat-maven-plugin myself so I can't really speak for it. The gpg-maven-plugin, on the other hand, I have used. It would be a nice addition, as it eases the M2 release process. If you have a working configuration for it, please go ahead and add it to the parent. Jochen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Henri Yandell wrote: On 2/7/07, Stephen Colebourne [EMAIL PROTECTED] wrote: LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Shouldn't be hard for Jochen to fix this prior to release. Website has lost a lot of stuff compared to existing website A lot of stuff. An odd logo for Commons, missing logo for FileUpload, missing ApacheCon advert, missing Commons items on the LHS. The .pom file is an M2 pom, so we need to make sure it goes to the m2 ibiblio repo and not the m1 ibiblio repo [I'm sure you know that Jochen, just stating the obvious as it never hurts]. PGP sig checks out. MD5s are good. The build.xml is odd - it gets jars from repo1.maven.org (good) and then tries to get them from the apache snapshot repo. That's odd - I'm guessing this is a bug in the Maven build.xml plugin? Not a blocker. Without looking actually looking at the code in question, I think it is working as expected. If fileupload or any of its ancestors declare the snapshot repo as a place to look for artifacts, I think it should be used by the ant build as well. snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang 2.3 problems Was: [VOTE] Lang 2.3 (RC2)
Henri Yandell wrote: On 2/8/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Hen, Henri Yandell wrote: Here's the 2nd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Saturday if it gets that far. DateFormatUtils.testLang312 still fail for me, now at the last assert: === % Testsuite: org.apache.commons.lang.time.TimeTestSuite Tests run: 62, Failures: 1, Errors: 0, Time elapsed: 11,174 sec - Standard Output --- WARNING: JDK test failed - testLang312() - --- Testcase: testLang312(org.apache.commons.lang.time.DateFormatUtilsTest): FAILED expected:...9... but was:...8... junit.framework.ComparisonFailure: expected:...9... but was:...8... at org.apache.commons.lang.time.DateFormatUtilsTest.testLang31 (DateFormatUtilsTest.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) === % It seems that we cannot format correctly also if the JDK fails. :-/ Ack :( What kind of environment are you in? timezone/platform/jdk version/locale? Same here GMT+1/Windows XP/1.4.2_13 and 1.5.0_09/sv_SE snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Jörg Schaible wrote: Hi Dennis, Dennis Lundberg wrote: Henri Yandell wrote: On 2/5/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. Yes, I tried to use this description for a M1 - M2 situation. In the end Carlos' advice was to ignore all the old versions and simply start with the new M2 releases also to use the new groupId and add for those releases only a relocation POM. That is a much easier way to do it. I'm starting to think that this is the way to go for Commons. Just change the groupId when we release with M2 and don't relocate older versions. The problem with adjusting the old releases is, that the location for the relocation POMs is already occupied by the automatically generated POMs for M2 on the global M2 repo (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.1/). And since they're already published, they cannot be changed anymore. I think you are allowed to add a relocation section to an already published pom. I vaguely remember discussing this with Carlos back then. [snip] - Jörg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Henri Yandell wrote: On 2/5/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. My understanding was that once we started doing m2 builds we would be changing group ids. What I really mean here is deploying to an m2 repository rather than doing m2 builds. So if Jochen's plan is to do an m2 build and send it to the m2 repository, then this point is moot. * How do we build a 2.0 release and vote on that rather than voting on the release manager's ability to do a release? Is there a way to deploy known files to an m2 repository rather than having to rebuild? I never intended to publish the exact distributables that we voted on. For example, I never intented to change version numbers within the binary distributables from 1.2rc2 to 1.2. How do others do that? This seems currently a process in flux. It seems clear that the standard functionality of M 2.0.4 released plugins does not match the necessary steps for Apache releases. M2 folks have developed and improved some plugins now that support signing and staging, but nothing is released yet. In the mean time you either live with it or you'll process some manual steps. Releases have been made, but not yet for all the plugins that take part in the release process. It is very close though. Which again is really about whether we goto an m2 repository than anything else. We've definitely been shifting in the last few Commons releases to building the actual 1.2 release and then voting on it, rather than building releases with -rc2 in the jar name etc. It's just been a tribal change on the lists currently (Craig kicked off a thread about it a few months ago). Afar from that, I never intended to use the release manager. To be honest, I never got it working. What's the problem here? I use it all the time (although never for an Apache release yet). I was thinking along the lines of mvn -Drelease clean install site assembly:assembly deploy Which is (apart from the deploy) exactly what I did to build the current files. Please also ensure, that you build from the labeled source code in Subversion. That's the main advantage for me using reelase plugin. By labeled, do you mean the svn tag? If you insist, I can omit the deploy and do the deployment manually. (In other words, omit rebuilding the files.) That said, I spent a lot of time in an automatic build exactly for *not* requiring any manual interventions, because I trust my build system more than myself. * How much of the release code can be shared - I can see stuff in the pom.xml, can that stuff be in the parent pom? Yes, but my clear intention was *not* to wait for a release of commons-parent again (I already did so last year for several months), rather than learning from this release and then move the stuff up later. (Note, that I did all changes in a branch, to allow me for careful integration into either trunk or commons-parent later.) +1 there's always room for improvement and we should rather use a project's POM to introduce new parts to a build then to add all stuff immediately to the parent. If the release went fine and the extension has shown to be useful, we might propagate the improvement to the parent *afterwards*. Sounds fine. The m2 versioning of parents does mean that even if you do something that is later considered the wrong direction when things are put in -parent, it won't hurt users very much. +1 Hen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
+1 from me for both Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Promote commons-site to proper and release it
Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. The votes are in: +1 for both from: Niall Pemberton Henri Yandell Simon Kitching Martin van den Bemt Oleg Kalnichevski Oliver Heger Jörg Schaible Dennis Lundberg I will proceed with the promotion and then the release. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
Martin van den Bemt wrote: +1 to both, assuming the project documentation on the main site has nothing to do with the skin, since I think we don't want that menu on the main site. The skin is only about looks. It couldn't care less about the content ;) I'll start a thread about menus, links and content shortly. Mvgr, Martin Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
Oliver Heger wrote: Just one question: I noticed that the links to the Cobertura report open an empty site for some components (did not check all). Is there a problem? (I am asking because I had some trouble when playing with the maven 2 cobertura plug-in a while ago.) There are 2 things that can cause this: 1. It's a multi module build. Cobertura does not support aggregated reports yet, so components like jci will not get any report on the top level. 2. The tests for some sandbox components will not run in Surefire out of the box, so I have disabled the tests in some of them. This leads to no tests for Cobertura to check. The problems are usually class loader related. But, this has nothing to do with the skin itself. This has to do with the build and the reports, which I will start a another discussion about. Otherwise I am +1 for both. Oliver Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Dennis Lundberg wrote:
Dennis Lundberg wrote:
Boris Unckel wrote:
Hi,
yet another issue.
snip
I had a look at the source and found XHTML transistional in the doctype.
Both http://validator.w3.org and http://www.validome.org say it is
not valid.
I think you know the tools, even when not, they are very easy to use
(I did not write: give good hint's for hunting the bugs).
Regards
Boris
This turned out to be trickier than I first thought, but here goes:
1. The xdocs for commons-lang are fine.
2. Rendering of links that include the -character, even if they are
properly encoded as amp; in the xdoc source, seems to be broken. That
is the -character doesn't get escaped properly, resulting in invalid
xhtml. This is filed as DOXIA-85 [1].
DOXIA-85 has been solved. Using a locally build version of Doxia I have
created a staged lang site with validating xhtml code:
http://people.apache.org/~dennisl/commons-lang6/
3. The rendered documents include a css link to css/site.css - a
file which doesn't exist, resulting in invalid css. This is filed as
DOXIA-86 [2].
This is an intended behavior, i.e the file is optional for the user to
put there, and I haven't been able to create a workaround for this. It
could be done in the velocity template like this:
if( the file css/site.css is available on the file system )
{
import the css file
}
Unfortunately I don't know how to. Perhaps someone from the Velocity
project can help out with this?
I figured out a way to work around this issue, by adding an empty
site.css file to commons-skin.
Anyway, this doesn't involve changing commons-skin.
[1] http://jira.codehaus.org/browse/DOXIA-85
[2] http://jira.codehaus.org/browse/DOXIA-86
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Dennis Lundberg wrote: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin Done. 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct Done - Align navigation structure I've created a sample file for this, but will create a new thread to discuss this. - Remove stuff that is inherited from sandbox-parent Done 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components I've staged the sandbox site, with all currently published components here: http://people.apache.org/~dennisl/commons-sandbox/ Please have a look and give me some feedback. Still left to fix: - I've cheated in a few places, regarding the images that I mentioned before. Will be fixed once we decide to ditch M1 for building sandbox sites. - Have to get rid of Version: 1-SNAPSHOT on the main page. - Would like to move sandbox-parent to its own directory in SVN Not yet... - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent See other threads soon... Does this sound OK to you? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Promote commons-site to proper and release it
I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Dennis Lundberg wrote:
Boris Unckel wrote:
Hi,
yet another issue.
snip
I had a look at the source and found XHTML transistional in the doctype.
Both http://validator.w3.org and http://www.validome.org say it is not
valid.
I think you know the tools, even when not, they are very easy to use
(I did not write: give good hint's for hunting the bugs).
Regards
Boris
This turned out to be trickier than I first thought, but here goes:
1. The xdocs for commons-lang are fine.
2. Rendering of links that include the -character, even if they are
properly encoded as amp; in the xdoc source, seems to be broken. That
is the -character doesn't get escaped properly, resulting in invalid
xhtml. This is filed as DOXIA-85 [1].
DOXIA-85 has been solved. Using a locally build version of Doxia I have
created a staged lang site with validating xhtml code:
http://people.apache.org/~dennisl/commons-lang6/
3. The rendered documents include a css link to css/site.css - a file
which doesn't exist, resulting in invalid css. This is filed as DOXIA-86
[2].
This is an intended behavior, i.e the file is optional for the user to
put there, and I haven't been able to create a workaround for this. It
could be done in the velocity template like this:
if( the file css/site.css is available on the file system )
{
import the css file
}
Unfortunately I don't know how to. Perhaps someone from the Velocity
project can help out with this?
Anyway, this doesn't involve changing commons-skin.
[1] http://jira.codehaus.org/browse/DOXIA-85
[2] http://jira.codehaus.org/browse/DOXIA-86
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Dennis Lundberg wrote: Dennis Lundberg wrote: Henri Yandell wrote: Looks good - nice work :) Only bit that leaps out to me as missing are the little arrows to symbolize external links. We may not care. Yes, I have seen that as well. The problem is that the M2 site plugin does not generate a class=externalLink for those links like M1 did. I'll have a look and see if that's difficult to add. I have created a patch for maven-doxia to handle this: http://jira.codehaus.org/browse/DOXIA-87 snip I have fixed this issue. It's not released yet, but using a localy build Doxia I have created yet another staged lang site, that shows how it looks: http://people.apache.org/~dennisl/commons-lang6/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Jörg Schaible wrote: Hi Rahul, Rahul Akolkar wrote on Monday, January 08, 2007 8:47 PM: On 1/8/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Dennis, Dennis Lundberg wrote: [snip] - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. I tried to look at this, but where's the commons-sandbox parent pom? snip/ In trunks-sandbox, more specifically: https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbo x/pom.xml IMHO it makes more sense to have an own commons-sandbox-parent trunk (like any other sandbox component). That way you don't have to checkout the complete sandbox and additionally you get the possibility to create a release for the POM ... or is that not supposed to happen for the sandbox parent POM ? - Jörg Hi Jörg As I said in the first mail in this thread, I would like to move the sandbox parent to be a sibling to the other sandbox components, and thereby have it's own trunk. There are still a couple of more things to do before I feel that we are ready to make that move though. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Niall Pemberton wrote: Hi Denis, Good job on the skin - I added an m2 build to Validator using it and looks great to me - I've published the m2 generated site for Validator here: http://people.apache.org/~niallp/validator-m2/ I can't see any problems with the skin - but noticed the following site issues which look like maven plugin features/bugs: 1) Maven changes absolute URLs specified in site.xml to relative URLs. This isn't a problem for the web sites - but components (like validator) that include them as docs in the distro it means that the breadcrumbs (Jakarta and Commons) and links to previous versions JavaDocs that are only on the site no longer work. Yep, the links will work once the site is published, but it should work for a staged site as well. This is a known issue: http://jira.codehaus.org/browse/MSITE-159 2) The changes report doesn't seem to like content that contains markup - it seems to split out the markup into a separate report - m1 and m2(x2) changes reports are here for comparison: http://jakarta.apache.org/commons/validator/changes-report.html http://people.apache.org/~niallp/validator-m2/changes-report.html (markup removed) I'll take a closer look at this. Unfortunately the M2 plugin is not yet up to par with its M1 counterpart. http://people.apache.org/~niallp/validator-m2/changes.html (removed markup) I noticed this file too. We need to exclude this file from the M2 site build. I'll patch a parent pom shortly. 3) Validator has a custom issue-tracking page - which seems to cause the site plugin to omit it from the project information menu and page: http://people.apache.org/~niallp/validator-m2/project-info.html If I delete the custom version - then m2 generates one and includes it on both the above. Strange, I'll look into it. more comments inline below... On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Here's a status report on how far I have gotten. The sandbox parent is finished. I have added a bunch of reports to it that seems logical, at least to me, for all components. These are: - Cobertura (test coverage) - Javadoc - JXR (cross reference for sources) - PMD - Surefire (test results) - JDepend (metrics) - Taglist (list things left to do) One thing I noticed recently with Cobertura is that it includes some JavaScript files with various (GPL+ other) licenses - maybe we should switch to JCoverage instead: http://tinyurl.com/ynbjge I hadn't noticed that. I'll take it up over in Maven land. The individual components have at least the reports they have in their M1 sites, with these exceptions: Sounds like a good plan - how will this be handled for proper components - is commons-parent the right place to put them or do we need a proper-parent pom? Once we settle on a standard set my plan is to move them to the parent pom. I don't currently see the need for a proper pom. - i18n is missing JCoverage, but Cobertura does the same thing - Id and Proxy are missing Clover, but Cobertura does the same thing - All are missing JavaDoc Report, JavaDoc Warnings Report and Link check, which does not exist in M2 - All are missing Project License which is available in another place in M2 Some components have their own reports as well. These didn't seem like something suitable for all components. These reports are: - Checkstyle (5 component) (requires a configuration file) - Changelog (3 component) - Changes (1 component) (requires a changes.xml file) - FindBugs (1 component) Still to do: - I haven't been able to get the logo in the upper right corner to work simultaneously for M1 and M2. This affects I18n, Id and Proxy. I fixed this in Validator by copying the logo to site/resources/images and including a bannerRight element in site.xml Yes, that's the easy way to go. I was hoping that I wouldn't need to resort to copying stuff in SVN. Some components have the Gimp or Photoshop source file in SVN as well. These need to go somewhere too. - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. - Id has a downloads page that refers to an M1 report. Need to decide how to deal with that. Can't have M1 and M2 working at the same time for this one. I assume you mean cvs-usage.html? While id is in the sandbox we could copy the cvs-usage.html to source-repository.html in the maven.xml and refer to source-repository.html on the downloads page. Yes, that's the file I meant. I think we'll just keep it like is for now. When the M2 site build is finished, we change the page to refer to the appropriate M2 page. We shouldn't need the M1 site build once we've switched to M1. Once its out of the sandbox I would remove the downloads page altogether and replace it with the standard downloads_commons-id.cgi True. Alternatively just delete the downloads page now. Thanks again for doing all this Niall - Publish staged sites
Re: [nightly build] betwixt finder failed.
Niall Pemberton wrote: On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070107/betwixt.log http://people.apache.org/~psteitz/commons-nightlies/20070107/finder.log The Maven 2 installation running the nightly builds needs to upgrade its jar-plugin to version 2.1, otherwise Phil's changes to the parent pom will cause this failure for finder or other M2 builds. What is the best way to do that? Wouldn't it be best to put the explicit versioned dependency in the pom(s) that need it? I don't like having builds depend on local setups. I guess if its maven itself that needs to be upgraded we can doc that somewhere and do it, but if its a plugin, we learned the hard way with m1 that its best to specify these in the poms. Yes I've thought about this some more and I agree that the best thing would be to lock down the versions in a parent pom somewhere, preferably commons-parent. That way we will have reproducible builds no matter runs it. Also, what changes to the parent are you talking about? That was me rather than Phil :-( http://svn.apache.org/viewvc?view=revrevision=493671 Sorry Phil! Maven-jar-plugin stopped adding Implementation-* and Specification-* stuff in the manifest by default starting with version 2.1. You're probably using that new version locally and have not noticed anything. The log says there is a duplicate Implementation-Title. I've added 2.1 to the parent pom http://svn.apache.org/viewvc?view=revrevision=494111 Great, thanks. Niall Thanks for looking into this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] betwixt finder failed.
[EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070107/betwixt.log http://people.apache.org/~psteitz/commons-nightlies/20070107/finder.log The Maven 2 installation running the nightly builds needs to upgrade its jar-plugin to version 2.1, otherwise Phil's changes to the parent pom will cause this failure for finder or other M2 builds. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462828
]
Dennis Lundberg commented on LANG-312:
--
The test case fail for me on Windows XP using Sun's JDK 1.4.2_13 and 1.5.0_09.
I did some simple debugging and printed out the underlying int for both the
Calendar and Date objects. Here are the results:
Running org.apache.commons.lang.time.TimeTestSuite
Cal = -684841660985
Date = -6849
I also printed out the expected pattern and the String created by
SimpleDateFormat:
19/04/1948 != 18/04/1948
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
Fix For: 3.0
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18
Re: [nightly build] betwixt finder failed.
Phil Steitz wrote: On 1/7/07, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070107/betwixt.log http://people.apache.org/~psteitz/commons-nightlies/20070107/finder.log The Maven 2 installation running the nightly builds needs to upgrade its jar-plugin to version 2.1, otherwise Phil's changes to the parent pom will cause this failure for finder or other M2 builds. What is the best way to do that? Wouldn't it be best to put the explicit versioned dependency in the pom(s) that need it? I don't like having builds depend on local setups. I guess if its maven itself that needs to be upgraded we can doc that somewhere and do it, but if its a plugin, we learned the hard way with m1 that its best to specify these in the poms. Yes I've thought about this some more and I agree that the best thing would be to lock down the versions in a parent pom somewhere, preferably commons-parent. That way we will have reproducible builds no matter runs it. Also, what changes to the parent are you talking about? Maven-jar-plugin stopped adding Implementation-* and Specification-* stuff in the manifest by default starting with version 2.1. You're probably using that new version locally and have not noticed anything. The log says there is a duplicate Implementation-Title. Thanks for looking into this. Phil -- Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462850
]
Dennis Lundberg commented on LANG-312:
--
I'm in GMT+1 with locale sv_SE.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
Fix For: 3.0
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-182:00:00 CET until 1948-10-03 3:00:00 CEST
1949-04-102:00:00 CET until 1949-10-02 3:00:00 CEST
b) High summer time
[jira] Created: (SANDBOX-184) ScriptableList uses Java 1.5 code
ScriptableList uses Java 1.5 code - Key: SANDBOX-184 URL: https://issues.apache.org/jira/browse/SANDBOX-184 Project: Commons Sandbox Issue Type: Bug Components: JS2J Reporter: Dennis Lundberg On line 98 in ScriptableList a call is made to Integer.valueOf(int) which is only available since Java 1.5. JS2J currently has Java 1.4 as the minimum requirement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Joerg Heinicke wrote: Henri Yandell flamefew at gmail.com writes: The spam issue is a tricky decision. Sometimes I turn off the notifications to then do a lot of changes, other times I let the spam hit the list because moving an issue into a version is a decision. If there were a lot of them, I'd be tempted to send an email to the list saying Moving these issues into XXX and then do a bulk move with the send-email option turned off. That'd be a nice JIRA feature - bulk-email notification rather than individual notification for each issue. Another way to let it be less bugging would be a splitting of this mailing list into multiple ones. No, not project specific - I know you love the cross-pollination :) But splitting it into commons-cvs|svn|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (don't know a project having this, but would love to see this, especially because of the topic we are actually talking about) and the actual dev list for discussions. This would finally make it possible to read current heavy traffic lists like geronimo-dev and this one on mailing list archives. At the moment I often get lost in the huge amount of mails and I refrain from subscribing to both metioned lists. Maven uses both [EMAIL PROTECTED] and [EMAIL PROTECTED] WDYT? Any chance for implementation? +1 Regards Jörg -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell wrote: On 1/6/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/6/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Henri Yandell flamefew at gmail.com writes: The spam issue is a tricky decision. Sometimes I turn off the notifications to then do a lot of changes, other times I let the spam hit the list because moving an issue into a version is a decision. If there were a lot of them, I'd be tempted to send an email to the list saying Moving these issues into XXX and then do a bulk move with the send-email option turned off. That'd be a nice JIRA feature - bulk-email notification rather than individual notification for each issue. Another way to let it be less bugging would be a splitting of this mailing list into multiple ones. No, not project specific - I know you love the cross-pollination :) But splitting it into commons-cvs|svn|[EMAIL PROTECTED] (many projects have their own list for commit mails), commons-jira|issues|[EMAIL PROTECTED] (don't know a project having this, but would love to see this, especially because of the topic we are actually talking about) and the actual dev list for discussions. This would finally make it possible to read current heavy traffic lists like geronimo-dev and this one on mailing list archives. At the moment I often get lost in the huge amount of mails and I refrain from subscribing to both metioned lists. WDYT? Any chance for implementation? We talked about this a while back, and though there was some disagreement the consensus was definitely in favour of splitting the 'noise' off onto another list. Making the archives more readable was the big reason. It's just not been done. I think it's more common to move things over to the commits list than making a list for each source. Maven currently does this. I can definitely do it for JIRA no problem, so then it's just a matter of getting a wiki change. I'll let this sit for a few days to make sure no-one -1s, and then go ahead and make it happen. Scratch that - I misremembered the solution - it was about different lists, not just moving JIRA and Wiki onto the -commits list. The svn commits still show in the -dev list. No plans to do anything on my part. Why not move all JIRA notifications to [EMAIL PROTECTED] ? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] betwixt failed.
[EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070106/betwixt.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] It seems that Netscape [1] has decided to take down the site where the rss-0.91.dtd file [2] is located. I googled for an alternate location and found one on freshmeat [3]. [1] http://my.netscape.com/ [2] http://my.netscape.com/publish/formats/rss-0.91.dtd [3] http://download.freshmeat.net/backend/rss-0.91.dtd -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Here's a status report on how far I have gotten. The sandbox parent is finished. I have added a bunch of reports to it that seems logical, at least to me, for all components. These are: - Cobertura (test coverage) - Javadoc - JXR (cross reference for sources) - PMD - Surefire (test results) - JDepend (metrics) - Taglist (list things left to do) The individual components have at least the reports they have in their M1 sites, with these exceptions: - i18n is missing JCoverage, but Cobertura does the same thing - Id and Proxy are missing Clover, but Cobertura does the same thing - All are missing JavaDoc Report, JavaDoc Warnings Report and Link check, which does not exist in M2 - All are missing Project License which is available in another place in M2 Some components have their own reports as well. These didn't seem like something suitable for all components. These reports are: - Checkstyle (5 component) (requires a configuration file) - Changelog (3 component) - Changes (1 component) (requires a changes.xml file) - FindBugs (1 component) Still to do: - I haven't been able to get the logo in the upper right corner to work simultaneously for M1 and M2. This affects I18n, Id and Proxy. - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. - Id has a downloads page that refers to an M1 report. Need to decide how to deal with that. Can't have M1 and M2 working at the same time for this one. - Publish staged sites so that you can all see what it looks like. Dennis Lundberg wrote: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct - Align navigation structure - Remove stuff that is inherited from sandbox-parent 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components - Would like to move sandbox-parent to its own directory in SVN - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent Does this sound OK to you? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
I plan on doing all of the necessary changes myself. When all is done I'll ask for feedback on the results. So if you have a project in the sandbox you're involved in - stay tuned :) James Carman wrote: +1 from me (I can't remember if I'm binding or not). Do you need the individual projects to update their poms or are you going to take care of that? On 1/5/07, Henri Yandell [EMAIL PROTECTED] wrote: +1 here. On 1/4/07, Jörg Schaible [EMAIL PROTECTED] wrote: +1 Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sandbox] Using commons-skin for all components
Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct - Align navigation structure - Remove stuff that is inherited from sandbox-parent 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components - Would like to move sandbox-parent to its own directory in SVN - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent Does this sound OK to you? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell wrote: Using the commons-nightly/jira-email.vm swizzle script, I've got a report for the Commons projects that lets us see the status of things. Here's the output: http://people.apache.org/~bayard/jira-report-for-commons.txt The aim is to provide us with information on where projects are release-wise and where we are in terms of answering new issues. Some of our components aren't there - for example Jelly which has 77 unversioned issues and Attributes/Discovery which are ready to be retired. Some of the ones there should probably be removed for having too many unversioned issues. I was pondering whether this would have value to be emailed to commons-dev once a week? Any thoughts? Hen Nice! Just need some help with interpretation: Commons BeanUtils - Component (got that one) 1.8.0 - 19 / 79 ^ ^^ | || + || version || || --+| solved issues | in that vers.? | ---+ total scheduled issues for that version? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] What's in a distribution?
Hi I've been looking at creating distributions for commons logging using Maven 2. So I did some reading on ASF policy regarding distributions and poked around in different commons components, to see if I could find a least common denominator. Unfortunately I haven't. So I've got a couple of questions for you to think about: 1. What should a source distribution include? 2. What should a binary distribution include? Reading the documentation for the assembly-plugin [1] for Maven 2 I found an interesting feature that will come in the next version. It will create an assembly (distribution) of the entire source project, including the Maven POM and other files outside of your source directory structure, but excluding all SCM files and the target directory and archives for it (tar.gz, tar.bz2 and zip). Now this sound to me like the ideal source distro. A complete checkout. Then it's up to the user to build, read or do whatever he or she feels like with it. Who downloads a binary distribution, why and what for? Someone who doesn't use Maven to build their products. Because the don't want to, or don't know how to, build the commons component their selves. Because someone did all the building and assembling for them, i.e. they are lazy as in good lazy. So that's a broad audience we've got there. What do they need? Well in the case of commons they want the jar of course. What else? Some documentation on how to use it, list of dependencies and such. The ASF also has needs when it comes to licensing. We need to put a LICENSE and NOTICE file in there. What are your thoughts on this subject? [1] http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
Henri Yandell wrote: On 1/2/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: Using the commons-nightly/jira-email.vm swizzle script, I've got a report for the Commons projects that lets us see the status of things. Here's the output: http://people.apache.org/~bayard/jira-report-for-commons.txt The aim is to provide us with information on where projects are release-wise and where we are in terms of answering new issues. Some of our components aren't there - for example Jelly which has 77 unversioned issues and Attributes/Discovery which are ready to be retired. Some of the ones there should probably be removed for having too many unversioned issues. I was pondering whether this would have value to be emailed to commons-dev once a week? Any thoughts? Hen Nice! Just need some help with interpretation: Commons BeanUtils - Component (got that one) 1.8.0 - 19 / 79 ^ ^^ | || + || version || || --+| solved issues | in that vers.? | ---+ total scheduled issues for that version? Explaining it would have been a stunning idea :) You got it right. Version, resolved, total. Using resolved seemed more natural than unresolved. After that I leave it up to human interpretation - it's unlikely that 2/2 means that a release should happen, but 31/32 should mean it's time to release soon. And any component with a high number of solved issues deserves a release, no matter what the total says, say like 40/300. I'd like to include a bit of info in the 'Unresolved list on the number of comments (and unique comment authors), but that's not currently implemented (either in Swizzle or JIRA not sure where it's missing), so I need to go figure out why not. One thing that I have seen in reports like this one over in Maven land is the number votes. This is meant to indicate the users wish as to what issues to deal with first. See this one for the Maven plugins: http://repo1.maven.org/reports/plugins/plugin-issues.txt The numbers are: - total number of votes to the left of the plugin name - number of votes for the particular issue, to the left of each issue This one is not sorted alphabetically, but by descending number of votes per plugin. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Dennis Lundberg wrote: Phil Steitz wrote: snip http://people.apache.org/~dennisl/commons-lang4/http://people.apache.org/%7Edennisl/commons-lang4/ puts the nav bar in the middle, as before. That's odd. There must be something more that is wrong then. Unfortunately I haven't been able to reproduce this myself. I looked around to find a linux live-cd with Firefox 2 on it. I found one and burned a copy of Ubuntu 6.10 with Firefox 2.0.0.0. But I can't see the issues that you do. I can however see it on both Ubuntu and Windows if make the font size smaller (!) in firefox (CTRL -) about 6 times, then the navbar pops away to the right a bit. I'll continue searching for a solution. OK, I think I've got it this time. As it turned out I had put in my stylesheet rules in a different place than they should be, so I ended up having contradicting rules for the same selector. The conflicts have been solved and the rules have been moved to the appropriate section in the css file. This solves the all the problems I have seen. I have tested this with: - Firefox 2.0.0.1 on Windows - Internet Explorer 6 on Windows - Firefox 2.0.0.0 on Ubuntu - Konqueror 3.5.2 on Kubuntu Here's yet another staged site for commons-lang. Please help me and try it out on the platforms that had problems before. http://people.apache.org/~dennisl/commons-lang5/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Boris Unckel wrote: Hi, Dennis Lundberg wrote: OK, I think I've got it this time. As it turned out I had put in my stylesheet rules in a different place than they should be, so I ended up having contradicting rules for the same selector. The conflicts have been solved and the rules have been moved to the appropriate section in the css file. This solves the all the problems I have seen. I have tested this with: - Firefox 2.0.0.1 on Windows - Internet Explorer 6 on Windows - Firefox 2.0.0.0 on Ubuntu - Konqueror 3.5.2 on Kubuntu Here's yet another staged site for commons-lang. Please help me and try it out on the platforms that had problems before. http://people.apache.org/~dennisl/commons-lang5/ I have tested with: - Firefox 2.0.0.1 on Windows Vista RC1 (my personal reference) - looks fine - Internet Explorer 7 on Windows Vista RC1 -- looks fine, except headings (Commons Lang, Development, Project Documentation, Commons) on the left nav bar are larger than in Firefox There is a wellknown IE-bug-workaround in the css, that came along from maven-classic-skin, that might be the cause of this. Perhaps MS has fixed the bug in IE7? Anyway, you should be able to see the same difference in size on this site: http://people.apache.org/~dennisl/commons-lang3/ Can you confirm that? -- no show stopper (How many developers using Jakarta Commons are IE users AND will care about that?) - Opera 9.10 on Windows Vista RC1 - looks fine, I do not see any difference to Firefox Regards Boris Thanks for your help in testing this! -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Using Maven 2 for everything
Jochen Wiedmann wrote: On 12/30/06, Dennis Lundberg [EMAIL PROTECTED] wrote: 3. The class files in the test jars are different. Out of curiosity: How did you detect that? I wanted to make *really* sure that everything was OK, so I build everything with both Ant and Maven 2. Then I unpacked the jars that were created by each build. After that I used a diff tool [1] to see which files were different. The tool handles binary files as well, but I couldn't see what the difference was. The first thing that sprung to mind was that they had different class versions. So I googled a bit and found this Swing based tool [2] that can tell you the version of a class, among other things. [1] Araxis Merge, Commercial for Windows only [2] http://sourceforge.net/projects/classeditor/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Boris Unckel wrote: Hi, yet another issue. snip I had a look at the source and found XHTML transistional in the doctype. Both http://validator.w3.org and http://www.validome.org say it is not valid. I think you know the tools, even when not, they are very easy to use (I did not write: give good hint's for hunting the bugs). Regards Boris This turned out to be trickier than I first thought, but here goes: 1. The xdocs for commons-lang are fine. 2. Rendering of links that include the -character, even if they are properly encoded as amp; in the xdoc source, seems to be broken. That is the -character doesn't get escaped properly, resulting in invalid xhtml. This is filed as DOXIA-85 [1]. 3. The rendered documents include a css link to css/site.css - a file which doesn't exist, resulting in invalid css. This is filed as DOXIA-86 [2]. Anyway, this doesn't involve changing commons-skin. [1] http://jira.codehaus.org/browse/DOXIA-85 [2] http://jira.codehaus.org/browse/DOXIA-86 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Dennis Lundberg wrote: Henri Yandell wrote: Looks good - nice work :) Only bit that leaps out to me as missing are the little arrows to symbolize external links. We may not care. Yes, I have seen that as well. The problem is that the M2 site plugin does not generate a class=externalLink for those links like M1 did. I'll have a look and see if that's difficult to add. I have created a patch for maven-doxia to handle this: http://jira.codehaus.org/browse/DOXIA-87 snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-parent] Make deployment URL pluggable
Jochen Wiedmann wrote:
Hi,
in light of
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116560781629523w=2
and following a suggestion by Jörg Schaible, I'd like to propose the
attached patch. It introduces properties
commons.deployment.protocol
commons.deployment.release.url
commons.deployment.rc.url
The former is specifies as scp and may be overwritten, for example,
to be scpexe. The others are used by the release and rc
profiles, respectively. Both are referencing
${commons.deployment.protocol}.
In other words, the proposed patch is upwards compatible with the
current settings, except that it allows to override the deployment
protocol or URL. Both makes sense, IMO. For example, nightly builds
might wish to override the rc URL.
Thoughts? If noone else intervenes, I'll apply the patch.
Jochen
The idea of using a different protocol is fine by me, as long as I can
continue to use scp is I want to. That does seem to be the default
setting. So +1 for that.
I don't see any reason to change the urls though. If the nightly builds
don't want to release an RC then it shouldn't use the rc profile. The
profiles were set up to make sure that nothing get's deployed unless
someone explicitly says it should.
The comment in the patch indicates that it might if users are working
locally on people.apache.org. IIUC you are not supposed to do building
and releasing on that machine. You also risk that someone changes the
url to something that is completely wrong. Unless there is another
reason for it, I'm -1 on that change.
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
