Re: [VFS] Maven groupId problem?
Henning Schmiedehausen wrote: Get a relocation in. problem solved. commons-vfs - org.apache.commons. See e.g. http://repo2.maven.org/maven2/xerces/xerces/2.0.2/xerces-2.0.2.pom on how to do that. Relocations are only of use if the version is upward compatible, otherwise it's counterproductive. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Jörg Schaible wrote: Ralph Goers wrote: This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and the requirement has been added to the web site main page. The test file for LargeTarTestCase has been added to the test-data directory, greatly improving the build time. Many of the messages from the test cases have been removed. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... +1 -1 I revert this vote now, since it is clear that it's no longer binary compatible. And when you look at the long list of project using vfs it is a bad idea to release it th this way (see This artifact is used by ...): http://mvnrepository.com/artifact/commons-vfs/commons-vfs/1.0 - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
James Carman wrote: On Sun, Nov 7, 2010 at 10:03 PM, sebb seb...@gmail.com wrote: I just checked, and the tag agrees with the source archive - apart from the sandbox tree, which is only in the tag. Huh? If you look at the tag that is supposed to be for 1.0 here: http://svn.apache.org/repos/asf/commons/proper/vfs/tags/vfs-1.0/ It contains a pom.xml file in the root directory. If you download an unzip/untar the source distributions from here: http://commons.apache.org/vfs/download_vfs.cgi they do not. How do they agree? Am I looking in the wrong place? No. Just look into the maven.xml. It does not put the pom.xml into the distribution. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
sebb wrote: Most of the generics fixes have now been done. There are still a few raw Class references; most of these can be fixed if DefaultFileSystemConfigBuilder.getConfigClass() is changed to return a FileSystem [1] Can anyone else confirm that this is a sensible change? [1] https://issues.apache.org/jira/browse/VFS-334 No. We use an implementation of FileSystemConfigBuilder that does also not implement FileSystem to introduce more global configuration parameters. What you can do is: protected Class? extends FileSystemConfigBuilder getConfigClass(); - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
On 8 November 2010 08:49, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: Most of the generics fixes have now been done. There are still a few raw Class references; most of these can be fixed if DefaultFileSystemConfigBuilder.getConfigClass() is changed to return a FileSystem [1] Can anyone else confirm that this is a sensible change? [1] https://issues.apache.org/jira/browse/VFS-334 No. We use an implementation of FileSystemConfigBuilder that does also not implement FileSystem to introduce more global configuration parameters. So? None of the FileSystemConfigBuilder classes currently implement FileSystem. What you can do is: protected Class? extends FileSystemConfigBuilder getConfigClass(); No, that won't work, because all the other getConfig() methods return subclasses of FileSystem. The only solution then would be to use Class? throughout. All I'm suggesting is changing the return class from DefaultFileSystemConfigBuilder.getConfigClass() to (say) FileSystem.class. The FileSystemConfigBuilder subclass getConfig() methods are not there because they implement the FileSystem interface, they implement the abstract method in FileSystemComfigBuilder. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
On 8 November 2010 04:14, James Carman ja...@carmanconsulting.com wrote: On Sun, Nov 7, 2010 at 10:03 PM, sebb seb...@gmail.com wrote: I just checked, and the tag agrees with the source archive - apart from the sandbox tree, which is only in the tag. Huh? If you look at the tag that is supposed to be for 1.0 here: http://svn.apache.org/repos/asf/commons/proper/vfs/tags/vfs-1.0/ It contains a pom.xml file in the root directory. If you download an unzip/untar the source distributions from here: http://commons.apache.org/vfs/download_vfs.cgi they do not. How do they agree? Am I looking in the wrong place? Sorry, I overlooked the top-level pom.xml in all the other differences (sandbox). So there was a packaging error. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
sebb wrote: On 8 November 2010 04:14, James Carman ja...@carmanconsulting.com wrote: On Sun, Nov 7, 2010 at 10:03 PM, sebb seb...@gmail.com wrote: I just checked, and the tag agrees with the source archive - apart from the sandbox tree, which is only in the tag. Huh? If you look at the tag that is supposed to be for 1.0 here: http://svn.apache.org/repos/asf/commons/proper/vfs/tags/vfs-1.0/ It contains a pom.xml file in the root directory. If you download an unzip/untar the source distributions from here: http://commons.apache.org/vfs/download_vfs.cgi they do not. How do they agree? Am I looking in the wrong place? Sorry, I overlooked the top-level pom.xml in all the other differences (sandbox). So there was a packaging error. I don't think that the M2 build was ready yet (no executed tests). It was IMHO left out of the binaries on purpose. Vfs 1.0 was meant to be built with M1. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
On 8 November 2010 07:32, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Sunday, November 07, 2010 18:14 To: Commons Developers List Subject: Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0) On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz phil.ste...@gmail.com wrote: I would not -1 the release, but I would encourage the RM to consider making it 1.x if there are no compat breaks. So, how about now that we know there are compat breaks? I would -1 the release now that we know the API is in fact broken between 1 and 2 and they're not doing the package/artifactId change (barring any justification why we think it's okay). Well, that should settle it. API-breakage - new major version - package/artifactId change. So we can take this RC, do the above changes, then keep move on to a Java 5 themed release for 2.1. I think we ought to remove the deprecations as well, otherwise they cannot be removed until 3.0, which I assume will require yet another package/artid change. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
Hi Sebb, sebb wrote: On 8 November 2010 08:49, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: Most of the generics fixes have now been done. There are still a few raw Class references; most of these can be fixed if DefaultFileSystemConfigBuilder.getConfigClass() is changed to return a FileSystem [1] Can anyone else confirm that this is a sensible change? [1] https://issues.apache.org/jira/browse/VFS-334 No. We use an implementation of FileSystemConfigBuilder that does also not implement FileSystem to introduce more global configuration parameters. So? None of the FileSystemConfigBuilder classes currently implement FileSystem. What you can do is: protected Class? extends FileSystemConfigBuilder getConfigClass(); No, that won't work, because all the other getConfig() methods return subclasses of FileSystem. I see. The only solution then would be to use Class? throughout. All I'm suggesting is changing the return class from DefaultFileSystemConfigBuilder.getConfigClass() to (say) FileSystem.class. The FileSystemConfigBuilder subclass getConfig() methods are not there because they implement the FileSystem interface, they implement the abstract method in FileSystemComfigBuilder. I had a closer look at it now and it seems that Class? is the right solution. Basically the class type is used as a key to the options that apply for the current file system, but the stuff from DefaultFileSystemConfiguBuilder are available as options to all FS (as our implementation of FileSystemConfigBuilder does). It does not necessary have to be a FileSystem implementation, it's just a natural choice for a FS implementation. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
On 8 November 2010 10:37, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Sebb, sebb wrote: On 8 November 2010 08:49, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: Most of the generics fixes have now been done. There are still a few raw Class references; most of these can be fixed if DefaultFileSystemConfigBuilder.getConfigClass() is changed to return a FileSystem [1] Can anyone else confirm that this is a sensible change? [1] https://issues.apache.org/jira/browse/VFS-334 No. We use an implementation of FileSystemConfigBuilder that does also not implement FileSystem to introduce more global configuration parameters. So? None of the FileSystemConfigBuilder classes currently implement FileSystem. What you can do is: protected Class? extends FileSystemConfigBuilder getConfigClass(); No, that won't work, because all the other getConfig() methods return subclasses of FileSystem. I see. The only solution then would be to use Class? throughout. All I'm suggesting is changing the return class from DefaultFileSystemConfigBuilder.getConfigClass() to (say) FileSystem.class. The FileSystemConfigBuilder subclass getConfig() methods are not there because they implement the FileSystem interface, they implement the abstract method in FileSystemComfigBuilder. I had a closer look at it now and it seems that Class? is the right solution. Basically the class type is used as a key to the options that apply for the current file system, but the stuff from DefaultFileSystemConfiguBuilder are available as options to all FS (as our implementation of FileSystemConfigBuilder does). It does not necessary have to be a FileSystem implementation, it's just a natural choice for a FS implementation. Would there be any harm in using the FS interface class in this case? i.e., use the implementation class for all real file systems, and use the FileSystem interface for generic options. Won't that work just as well? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1032424 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math: analysis/UnivariateRealFunction.java util/MathUtils.java
Le 08/11/2010 00:49, er...@apache.org a écrit : Author: erans Date: Sun Nov 7 23:49:42 2010 New Revision: 1032424 URL: http://svn.apache.org/viewvc?rev=1032424view=rev Log: MATH-195 Added requested Javadoc comment. Removed unused import. Fine. Thanks Gilles. Luc Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/UnivariateRealFunction.java commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/UnivariateRealFunction.java URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/UnivariateRealFunction.java?rev=1032424r1=1032423r2=1032424view=diff == --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/UnivariateRealFunction.java (original) +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/UnivariateRealFunction.java Sun Nov 7 23:49:42 2010 @@ -27,6 +27,22 @@ public interface UnivariateRealFunction * * @param x Point at which the function value should be computed. * @return the value. + * @throws IllegalArgumentException when the activated method itself can + * ascertain that preconditions specified in the API expressed at the + * level of the activated method have been violated. In the vast + * majority of cases where Commons-Math throws IllegalArgumentException, + * it is the result of argument checking of actual parameters immediately + * passed to a method. + * @throws org.apache.commons.math.exception.FunctionEvaluationException + * when the method that may encounter errors during evaluation. + * This should be thrown only in circumstances where, at the level of the + * activated function, IllegalArgumentException is not appropriate and it + * should indicate that while formal preconditions of the method have not + * been violated, an irrecoverable error has occurred evaluating a + * function at some (usually lower) level of the call stack. + * Convergence failures, runtime exceptions (even IllegalArgumentException) + * in user code or lower level methods can cause (and should be wrapped in) + * a FunctionEvaluationException. */ double value(double x); } Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java?rev=1032424r1=1032423r2=1032424view=diff == --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java (original) +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java Sun Nov 7 23:49:42 2010 @@ -23,7 +23,6 @@ import java.util.Arrays; import java.util.List; import java.util.ArrayList; import java.util.Comparator; -import java.util.Map; import java.util.Collections; import org.apache.commons.math.MathRuntimeException; - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release Commons VFS 2.0
+1 release it I don't like using a build named commons-vfs-20070611.jar because no official release exists... Also, if VFS2 isn't backward compatible and lists all changes to make during upgrade, we should consider patching FileContentInputStream to return false in method markSupported() See https://issues.apache.org/jira/browse/VFS-301 And no problem for me if you change the package or not and no problem if you're going to java 6. Regards, KERDUDOU Ronan VIRAGE Group (France) RD : +33 (0)2 53 55 10 22 r...@viragegroup.com www.viragegroup.com -Message d'origine- De : Ralph Goers [mailto:ralph.go...@dslextreme.com] Envoyé : jeudi 4 novembre 2010 00:23 À : Commons Developers List Objet : [VOTE] Release Commons VFS 2.0 This is a vote to release Apache Commons VFS 2.0. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Ralph tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project -2.0/ site: http://people.apache.org/~rgoers/commons-vfs/index.html The following artifacts have been staged to the Apache Nexus Staging repository org.apache.commons-028 (u:rgoers, a:38.101.196.246). commons-vfs-project-2.0-src.zip commons-vfs-project-2.0-src.tar.gz commons-vfs-project-2.0-source-release.zip.asc commons-vfs-project-2.0-bin.tar.gz.asc commons-vfs-project-2.0.pom commons-vfs-project-2.0-site.xml commons-vfs-project-2.0-bin.zip commons-vfs-project-2.0-src.zip.asc commons-vfs-project-2.0-source-release.zip commons-vfs-project-2.0-site.xml.asc commons-vfs-project-2.0-src.tar.gz.asc commons-vfs-project-2.0.pom.asc commons-vfs-project-2.0-bin.zip.asc commons-vfs-project-2.0-bin.tar.gz commons-vfs-2.0.pom.asc commons-vfs-2.0-tests.jar.asc commons-vfs-2.0-sources.jar commons-vfs-2.0-sources.jar.asc commons-vfs-2.0.jar commons-vfs-2.0.jar.asc commons-vfs-2.0.pom commons-vfs-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar commons-vfs-2.0-javadoc.jar commons-vfs-sandbox-2.0-sources.jar commons-vfs-sandbox-2.0-sources.jar.asc commons-vfs-sandbox-2.0-javadoc.jar commons-vfs-sandbox-2.0.jar.asc commons-vfs-sandbox-2.0.pom commons-vfs-sandbox-2.0.jar commons-vfs-sandbox-2.0.pom.asc commons-vfs-sandbox-2.0-javadoc.jar.asc commons-vfs-examples-2.0-javadoc.jar.asc commons-vfs-examples-2.0-javadoc.jar commons-vfs-examples-2.0-sources.jar.asc commons-vfs-examples-2.0-sources.jar commons-vfs-examples-2.0.jar.asc commons-vfs-examples-2.0.pom commons-vfs-examples-2.0.jar commons-vfs-examples-2.0.pom.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Update dependencies?
sebb wrote: The following dependencies could potentially be updated: ant:ant ... 1.6.2 - 1.6.5 commons-httpclient:commons-httpclient . 3.0 - 3.1 commons-collections:commons-collections . 3.1 - 3.2.1 javax.mail:mail . 1.4 - 1.4.1 org.apache.jackrabbit:jackrabbit-webdav ... 1.5.2 - 2.1.2 xml-apis:xml-apis 1.0.b2 - 2.0.2 xml-apis:xml-apis 1.0.b2 - 1.3.04 2.x series is bogus and the artifacts are effectively a lot older than 1.3.x. And do we still need it anyway? The ones provided by the JDK 1.5 could be new enough. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Update dependencies?
On 8 November 2010 12:46, James Carman ja...@carmanconsulting.com wrote: Why do we have a dependency on ant? No idea - looks like it's not needed. Perhaps someone thought it was needed for the Maven Antrun plugin? On Mon, Nov 8, 2010 at 7:13 AM, sebb seb...@gmail.com wrote: The following dependencies could potentially be updated: ant:ant ... 1.6.2 - 1.6.5 commons-httpclient:commons-httpclient . 3.0 - 3.1 commons-collections:commons-collections . 3.1 - 3.2.1 javax.mail:mail . 1.4 - 1.4.1 org.apache.jackrabbit:jackrabbit-webdav ... 1.5.2 - 2.1.2 xml-apis:xml-apis 1.0.b2 - 2.0.2 I think we should update most, if not all of them. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VFS] Update dependencies?
-Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Monday, November 08, 2010 04:46 To: Commons Developers List Subject: Re: [VFS] Update dependencies? Why do we have a dependency on ant? On Mon, Nov 8, 2010 at 7:13 AM, sebb seb...@gmail.com wrote: The following dependencies could potentially be updated: ant:ant ... 1.6.2 - 1.6.5 commons-httpclient:commons-httpclient . 3.0 - 3.1 HttpClient 3.0 to 3.1 should be a drop-in but 3.1 to 4.0.3 will require code changes. So we should also plan for that. Gary commons-collections:commons-collections . 3.1 - 3.2.1 javax.mail:mail . 1.4 - 1.4.1 org.apache.jackrabbit:jackrabbit-webdav ... 1.5.2 - 2.1.2 xml-apis:xml-apis 1.0.b2 - 2.0.2 I think we should update most, if not all of them. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Update dependencies?
sebb wrote: On 8 November 2010 12:46, James Carman ja...@carmanconsulting.com wrote: Why do we have a dependency on ant? No idea - looks like it's not needed. Perhaps someone thought it was needed for the Maven Antrun plugin? No. VfsTask is based on Ant: core/src/main/java/org/apache/commons/vfs/tasks/VfsTask.java However, I am not sure how this stuff is used. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Update dependencies?
sebb wrote: On 8 November 2010 16:05, sebb seb...@gmail.com wrote: On 8 November 2010 12:46, James Carman ja...@carmanconsulting.com wrote: Why do we have a dependency on ant? No idea - looks like it's not needed. Actually, the tasks package uses org.apache.tools.ant (I was looking for org.apache.ant) See also: http://commons.apache.org/vfs/anttasks.html - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Update dependencies?
On 8 November 2010 16:14, Gary Gregory ggreg...@seagullsoftware.com wrote: -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Monday, November 08, 2010 04:46 To: Commons Developers List Subject: Re: [VFS] Update dependencies? Why do we have a dependency on ant? On Mon, Nov 8, 2010 at 7:13 AM, sebb seb...@gmail.com wrote: The following dependencies could potentially be updated: ant:ant ... 1.6.2 - 1.6.5 commons-httpclient:commons-httpclient . 3.0 - 3.1 HttpClient 3.0 to 3.1 should be a drop-in but 3.1 to 4.0.3 will require code changes. So we should also plan for that. That should be a long-term goal. The 4.x lines are still evolving, and AFAIK 3.1 performs well enough for simple HTTP(S) requests. Gary commons-collections:commons-collections . 3.1 - 3.2.1 javax.mail:mail . 1.4 - 1.4.1 org.apache.jackrabbit:jackrabbit-webdav ... 1.5.2 - 2.1.2 xml-apis:xml-apis 1.0.b2 - 2.0.2 I think we should update most, if not all of them. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Exec - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=1488projectId=80 Build statistics: State: Failed Previous State: Ok Started at: Mon 8 Nov 2010 21:33:50 + Finished at: Mon 8 Nov 2010 21:35:58 + Total time: 2m 8s Build Trigger: Schedule Build Number: 34 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.32-24-server arch: amd64 Family: unix SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 92 Failures: 1 Errors: 0 Success Rate: 98 Total time: 73.73 Test Failures: DefaultExecutorTest testExecuteWatchdogSync : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: killing the subprocess did not work : 5 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.exec.DefaultExecutorTest.testExecuteWatchdogSync(DefaultExecutorTest.java:288) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
On Mon, Nov 8, 2010 at 9:43 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: Henning, it isn't as simple as you believe. See, for example, this thread: http://marc.info/?t=12825660982r=1w=2 The conclusion was, as I read it at the time, that you should expect that users still have to edit their respective pom files. Which is a blocker, IMO. You would have to change your pom to select version 2.0 or 1.1 anyway, so what if they have to edit one more line to fix the groupId? Apart from that, what do we gain? Noone has actual problems with the current groupId. It's simply that people don't like it. Jochen On Mon, Nov 8, 2010 at 4:08 AM, Henning Schmiedehausen henn...@schmiedehausen.org wrote: I don't get it. Sorry. :-) So maven1 kind of added ad-hoc groups. They chose to use the same as the artifactId as the groupId when they constituted that back in the maven1 days. That turned out to be suboptimal. But some artifacts that were in the maven1 tree (most of commons) ended up in the commons-* locations. Pretty much everyone agrees that this was a mistake and these artifacts should have been put into org.apache.commons. However, they were not. Why should be stay locked into these mistakes forever? Maven offers a relocation mechanism. So we use it and put the new releases into the more sane location which is org.apache.commons:commons-vfs. Life goes on afterwards. Relocation helps people to transition. I love backwards compatibility as the next guy, but we do have to move on at some point. JDK 1.3 and Maven 1 are gone for five+ years now. Everyone who is still using them will not upgrade anyway. Not leveraging what exists in 2010 seems to wrong to me. Let's acknowledge mistakes of the past and move on. +1 to org.apache.commons:* for all new releases. +1 to JDK5+ (even though I would prefer JDK6+) for all new releases. -h On Sun, Nov 7, 2010 at 18:48, James Carman ja...@carmanconsulting.com wrote: On Sun, Nov 7, 2010 at 9:43 PM, Henning Schmiedehausen henn...@schmiedehausen.org wrote: This is an old, buggy location and it should be cleaned up over time. Being locked into the mistakes of the past because some tool can not understand it, doesn't seem to be reasonable to me. The cat's sort of out of the bag now. It pisses people (well at least it does me) off when you start moving stuff around on them. All of a sudden, you start seeing blah blah moved to blah blah in your build output. VFS apparently wasn't a Maven 2 project at the time it was released. The source distribution doesn't contain a pom.xml file. I'm more worried about how the tag is out of sync with the official released source. That's not good. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Net - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=1491projectId=107 Build statistics: State: Failed Previous State: Ok Started at: Tue 9 Nov 2010 02:24:31 + Finished at: Tue 9 Nov 2010 02:30:18 + Total time: 5m 46s Build Trigger: Schedule Build Number: 13 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.32-24-server arch: amd64 Family: unix SCM Changes: Changed: sebb @ Tue 9 Nov 2010 01:37:33 + Comment: Revert NET-276 changes that break the binary API Will be re-applied in 3.0 Files changed: /commons/proper/net/trunk/src/main/java/org/apache/commons/net/nntp/ArticlePointer.java ( 1032805 ) /commons/proper/net/trunk/src/main/java/org/apache/commons/net/nntp/NNTPClient.java ( 1032805 ) /commons/proper/net/trunk/src/main/java/org/apache/commons/net/nntp/NewsgroupInfo.java ( 1032805 ) Changed: sebb @ Tue 9 Nov 2010 01:39:42 + Comment: Remove NET-276 from changes Files changed: /commons/proper/net/trunk/RELEASE-NOTES.txt ( 1032806 ) /commons/proper/net/trunk/src/changes/changes.xml ( 1032806 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 138 Failures: 1 Errors: 0 Success Rate: 99 Total time: 139.046 Test Failures: TFTPTest testASCIIDownloads : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: Entry 5 Error java.io.IOException: Connection timed out. at junit.framework.Assert.fail(Assert.java:47) at org.apache.commons.net.tftp.TFTPTest.testASCIIDownloads(TFTPTest.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) at org.apache.maven.surefire.Surefire.run(Surefire.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
