[jira] (SUREFIRE-654) TestNG: Recognize successful tests when using invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355195#comment-355195
]
Andrew Phillips commented on SUREFIRE-654:
--
> Closing as fixed for now.
Great, thanks, [~agudian]
> TestNG: Recognize successful tests when using invocationCount and
> successPercentage parameters on the @Test annotation
> --
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: New Feature
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
>Assignee: Andreas Gudian
> Fix For: 2.18
>
> Attachments: bugtest.tar.gz, surefire654.diff,
> surefire-fix-test-build-output.txt, surefire-fix-test.zip
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-654) TestNG: Recognize successful tests when using invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355195#comment-355195
]
Andrew Phillips edited comment on SUREFIRE-654 at 10/29/14 3:01 PM:
> Closing as fixed for now.
Great, thanks, [~agudian]!
was (Author: demobox):
> Closing as fixed for now.
Great, thanks, [~agudian]
> TestNG: Recognize successful tests when using invocationCount and
> successPercentage parameters on the @Test annotation
> --
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: New Feature
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
>Assignee: Andreas Gudian
> Fix For: 2.18
>
> Attachments: bugtest.tar.gz, surefire654.diff,
> surefire-fix-test-build-output.txt, surefire-fix-test.zip
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-654) Surefire does not recognize successful tests using TestNG with the invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354996#comment-354996
]
Andrew Phillips commented on SUREFIRE-654:
--
> I'll do the review and check why the fix is not working for Andrew Phillips
Thanks, [~agudian]!
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation
> ---
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
>Assignee: Andreas Gudian
> Fix For: 2.18
>
> Attachments: bugtest.tar.gz, surefire654.diff,
> surefire-fix-test-build-output.txt, surefire-fix-test.zip
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-654) Surefire does not recognize successful tests using TestNG with the invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354753#comment-354753
]
Andrew Phillips commented on SUREFIRE-654:
--
Hi [~tibor17]:
Thanks for the hints! At this point, I am not able to investigate *why* exactly
the test case I attached is failing - I just wanted to point out that, for me
at least, the patch doesn't seem to be working.
I hope this will help whoever will review the patch determine whether it's
correct or not.
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation
> ---
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
> Attachments: bugtest.tar.gz, surefire654.diff,
> surefire-fix-test-build-output.txt, surefire-fix-test.zip
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-654) Surefire does not recognize successful tests using TestNG with the invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Phillips updated SUREFIRE-654:
-
Attachment: surefire-fix-test-build-output.txt
surefire-fix-test.zip
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation
> ---
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
> Attachments: bugtest.tar.gz, surefire654.diff,
> surefire-fix-test-build-output.txt, surefire-fix-test.zip
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-654) Surefire does not recognize successful tests using TestNG with the invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354700#comment-354700
]
Andrew Phillips commented on SUREFIRE-654:
--
Unfortunately, this patch doesn't seem to work for me :-( What I did:
1. Cloned the surefire project
2. Reverted to the 2.17 release commit and applied the patch
3. Built and installed the surefire plugin locally (version 2.17-SUREFIRE-654)
4. Ran the attached project with {{mvn clean test}}
The test should fail as all four invocations fail, but even with a success
percentage of 99% the build succeeds. See attached output.
My environment:
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T12:37:52-05:00)
Maven home: C:\Program Files (x86)\Apache\maven-3.2.1\bin\..
Java version: 1.7.0_40, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_40\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation
> ---
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
> Attachments: bugtest.tar.gz, surefire654.diff,
> surefire-fix-test-build-output.txt, surefire-fix-test.zip
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-654) Surefire does not recognize successful tests using TestNG with the invocationCount and successPercentage parameters on the @Test annotation
[
https://jira.codehaus.org/browse/SUREFIRE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354678#comment-354678
]
Andrew Phillips commented on SUREFIRE-654:
--
We're also running into this with Apache jclouds, so it would be great to see
some movement here.
I understand [~agudian]'s comment about trying to keep the change minimal, but
looking at the PR it's indeed a small change which seems to be (this coming
from someone without much knowledge of the Surefire internals) "in the right
place".
Is there some existing functionality that is working correctly that this PR is
breaking?
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation
> ---
>
> Key: SUREFIRE-654
> URL: https://jira.codehaus.org/browse/SUREFIRE-654
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.6
> Environment: Apache Maven 2.2.1 (rdebian-4)
> Java version: 1.6.0-18
> Java home: /usr/lib/jvm/java-6-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix"
> Ubuntu 10.10
>Reporter: Steve Stodola
> Attachments: bugtest.tar.gz, surefire654.diff
>
>
> Surefire does not recognize successful tests using TestNG with the
> invocationCount and successPercentage parameters on the @Test annotation.
> BugTest.java in the attached file has an invocationCount = 100 with a
> successPercentage = 1. 1 test in 100 needs to pass for the test to be
> considered successful. However when running *{{mvn clean test}}* Surefire
> reports the tests as failed. The generated report shows the tests as passing.
> Surefire should be identifying this test as passing.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287979#comment-287979 ] Andrew Phillips commented on MRRESOURCES-55: Verified with a version built locally from an SVN checkout (r1229389) - works as expected. Yay ;-) > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: https://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips >Assignee: Robert Scholte > Fix For: 1.3 > > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287978#comment-287978 ] Andrew Phillips commented on MRRESOURCES-55: Thanks, Robert! I won't be able to verify this immediately but will try to do so as soon as possible > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: https://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips >Assignee: Robert Scholte > Fix For: 1.3 > > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287848#comment-287848 ] Andrew Phillips commented on MRRESOURCES-55: Thanks for the update, Robert. Good luck ;-) > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: https://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips >Assignee: Robert Scholte > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[
https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287737#comment-287737
]
Andrew Phillips commented on MRRESOURCES-55:
Thanks for updating the downloader, Robert!
Any idea if/when the changes to
{code}ProcessRemoteResourcesMojo.downloadBundles{code} (that will actually use
the new functionality in downloader) could be included?
> Support groupId:artifactId:version:type and
> groupId:artifactId:version:type:classifier as resource bundle references
>
>
> Key: MRRESOURCES-55
> URL: https://jira.codehaus.org/browse/MRRESOURCES-55
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Andrew Phillips
>Assignee: Robert Scholte
> Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt,
> MRRESOURCES-55-remote-resources-patch.txt
>
>
> Currently, the RR plugin only support groupId:artifactId:version as an
> identifier for a remote bundle. However, there are quite a few use cases
> (e.g. platform-specific bundles) where it would be very useful to be able to
> identify bundles additionally by classifier. The current workaround we use -
> different versions - works, but isn't particularly elegant or semantically
> accurate.
> The proposal therefore is to also allow identifiers of the type
> groupId:artifactId:version:type:classifier
> As Brett pointed out in an IRC chat, this automatically adds the type to the
> identifier as well. One could ignore it or enforce 'jar' (the current
> default), but on the other hand there seems to be no reason *not* to allow
> types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much
> sense.
> Two potential implementations, with tests, are attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ https://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279699#comment-279699 ] Andrew Phillips commented on WAGON-319: --- @Olivier: Thanks! I hope Marcin can test - we're no longer using Google Code (i.e. the WebDAV wagon) for our use case :-( > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: WAGON-319 > URL: https://jira.codehaus.org/browse/WAGON-319 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531-corrected-style.diff, > patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/support/issues/detail?id=4786). There is a > suspicion that '/./' part of URL is an error cause. > It has been discussed also on Maven mailing list: > http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html > Becau
[jira] Commented: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[
https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=277896#comment-277896
]
Andrew Phillips commented on MRRESOURCES-55:
@Robert: Agreed. {{VersionRange.createFromVersion}} looks more appropriate
here. May have been careless syntax completion - {{createFromVersion}} appears
to be the natural choice here anyway.
Thanks for spotting this!
> Support groupId:artifactId:version:type and
> groupId:artifactId:version:type:classifier as resource bundle references
>
>
> Key: MRRESOURCES-55
> URL: https://jira.codehaus.org/browse/MRRESOURCES-55
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Andrew Phillips
> Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt,
> MRRESOURCES-55-remote-resources-patch.txt
>
>
> Currently, the RR plugin only support groupId:artifactId:version as an
> identifier for a remote bundle. However, there are quite a few use cases
> (e.g. platform-specific bundles) where it would be very useful to be able to
> identify bundles additionally by classifier. The current workaround we use -
> different versions - works, but isn't particularly elegant or semantically
> accurate.
> The proposal therefore is to also allow identifiers of the type
> groupId:artifactId:version:type:classifier
> As Brett pointed out in an IRC chat, this automatically adds the type to the
> identifier as well. One could ignore it or enforce 'jar' (the current
> default), but on the other hand there seems to be no reason *not* to allow
> types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much
> sense.
> Two potential implementations, with tests, are attached.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated MRRESOURCES-55: --- Attachment: MRRESOURCES-55-remote-resources-patch.txt This the patch (including unit and integration tests) for the RR plugin itself. The other patch (MRRESOURCES-55-preserve-original-codepath-patch.txt) is for the maven-downloader. > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: http://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[
http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269512#action_269512
]
Andrew Phillips commented on MRRESOURCES-55:
Implementation note: the suggested patch completely preserves the original
codepath, for minimum impact on existing code. A "cleaner" implementation could
let
{noformat}
ProcessRemoteResourcesMojo.downloadBundles
{noformat}
*always* call the new 7-arg version of {{Downloader.download}}
{noformat}
public File download(groupId, artifactId, version, type, classifier,
localRepository, remoteRepositories)
{noformat}
Equally, {{DefaultDownloader.download}} itself could always call
{noformat}
artifactFactory.createDependencyArtifact(groupId, artifactId, versionRange,
type, classifier, scope)
{noformat}
but then the defaulting logic ("if no type then type = 'jar' etc.") that is
currently in {{ArtifactFactory}} would have to be "lifted up" to
{{DefaultDownloader}} or even {{ProcessRemoteResourcesMojo}}, which seems like
abstraction leakage.
> Support groupId:artifactId:version:type and
> groupId:artifactId:version:type:classifier as resource bundle references
>
>
> Key: MRRESOURCES-55
> URL: http://jira.codehaus.org/browse/MRRESOURCES-55
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Andrew Phillips
> Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt
>
>
> Currently, the RR plugin only support groupId:artifactId:version as an
> identifier for a remote bundle. However, there are quite a few use cases
> (e.g. platform-specific bundles) where it would be very useful to be able to
> identify bundles additionally by classifier. The current workaround we use -
> different versions - works, but isn't particularly elegant or semantically
> accurate.
> The proposal therefore is to also allow identifiers of the type
> groupId:artifactId:version:type:classifier
> As Brett pointed out in an IRC chat, this automatically adds the type to the
> identifier as well. One could ignore it or enforce 'jar' (the current
> default), but on the other hand there seems to be no reason *not* to allow
> types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much
> sense.
> Two potential implementations, with tests, are attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated MRRESOURCES-55: --- Attachment: MRRESOURCES-55-preserve-original-codepath-patch.txt > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: http://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references Key: MRRESOURCES-55 URL: http://jira.codehaus.org/browse/MRRESOURCES-55 Project: Maven 2.x Remote Resources Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Andrew Phillips Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt Currently, the RR plugin only support groupId:artifactId:version as an identifier for a remote bundle. However, there are quite a few use cases (e.g. platform-specific bundles) where it would be very useful to be able to identify bundles additionally by classifier. The current workaround we use - different versions - works, but isn't particularly elegant or semantically accurate. The proposal therefore is to also allow identifiers of the type groupId:artifactId:version:type:classifier As Brett pointed out in an IRC chat, this automatically adds the type to the identifier as well. One could ignore it or enforce 'jar' (the current default), but on the other hand there seems to be no reason *not* to allow types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much sense. Two potential implementations, with tests, are attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-328) Allow putDirectory to continue even if an individual file transfer fails
[ http://jira.codehaus.org/browse/WAGON-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268123#action_268123 ] Andrew Phillips commented on WAGON-328: --- Version with patch applied available for testing at https://github.com/demobox/wagon-webdav-jackrabbit/tree/1.0-beta-8-WAGON-319.328 > Allow putDirectory to continue even if an individual file transfer fails > > > Key: WAGON-328 > URL: http://jira.codehaus.org/browse/WAGON-328 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Affects Versions: 1.0-beta-8 >Reporter: Andrew Phillips > Attachments: WAGON-328-patch.diff > > > The current WebDAV wagon implements putDirectory as a recursive sequence of > individual put commands for the individual files. This means that failure of > an individual put will abort the entire putDirectory. > This, of course, is generally correct and desired behaviour. However, in a > few cases it may not be critical that all files in a directory are correctly > uploaded. The use case in mind here is uploading Maven sites to not 100% > reliable DAV resources, e.g. Google Code (see also [WAGON-319]). > The request would be thus to add a "continueOnFailure" option (or similar) > which would not throw a TransferFailureException if put fails, but instead > log a warning or similar. This option would be false by default. > Admittedly, the better/"correct" place to address this issue would be in the > code that *calls* the wagon (in the case of this example, in the Maven Site > plugin), because it can make the context-specific decision of whether to be > lenient with errors or not. > However, there is no "putDirectoryLeniently" wagon method that the parent can > call, and this use case does not seem significant enough to merit changing > the wagon interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-328) Allow putDirectory to continue even if an individual file transfer fails
[ http://jira.codehaus.org/browse/WAGON-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated WAGON-328: -- Attachment: WAGON-328-patch.diff > Allow putDirectory to continue even if an individual file transfer fails > > > Key: WAGON-328 > URL: http://jira.codehaus.org/browse/WAGON-328 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Affects Versions: 1.0-beta-8 >Reporter: Andrew Phillips > Attachments: WAGON-328-patch.diff > > > The current WebDAV wagon implements putDirectory as a recursive sequence of > individual put commands for the individual files. This means that failure of > an individual put will abort the entire putDirectory. > This, of course, is generally correct and desired behaviour. However, in a > few cases it may not be critical that all files in a directory are correctly > uploaded. The use case in mind here is uploading Maven sites to not 100% > reliable DAV resources, e.g. Google Code (see also [WAGON-319]). > The request would be thus to add a "continueOnFailure" option (or similar) > which would not throw a TransferFailureException if put fails, but instead > log a warning or similar. This option would be false by default. > Admittedly, the better/"correct" place to address this issue would be in the > code that *calls* the wagon (in the case of this example, in the Maven Site > plugin), because it can make the context-specific decision of whether to be > lenient with errors or not. > However, there is no "putDirectoryLeniently" wagon method that the parent can > call, and this use case does not seem significant enough to merit changing > the wagon interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-328) Allow putDirectory to continue even if an individual file transfer fails
Allow putDirectory to continue even if an individual file transfer fails Key: WAGON-328 URL: http://jira.codehaus.org/browse/WAGON-328 Project: Maven Wagon Issue Type: Improvement Components: wagon-webdav Affects Versions: 1.0-beta-8 Reporter: Andrew Phillips The current WebDAV wagon implements putDirectory as a recursive sequence of individual put commands for the individual files. This means that failure of an individual put will abort the entire putDirectory. This, of course, is generally correct and desired behaviour. However, in a few cases it may not be critical that all files in a directory are correctly uploaded. The use case in mind here is uploading Maven sites to not 100% reliable DAV resources, e.g. Google Code (see also [WAGON-319]). The request would be thus to add a "continueOnFailure" option (or similar) which would not throw a TransferFailureException if put fails, but instead log a warning or similar. This option would be false by default. Admittedly, the better/"correct" place to address this issue would be in the code that *calls* the wagon (in the case of this example, in the Maven Site plugin), because it can make the context-specific decision of whether to be lenient with errors or not. However, there is no "putDirectoryLeniently" wagon method that the parent can call, and this use case does not seem significant enough to merit changing the wagon interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264485#action_264485 ] Andrew Phillips commented on WAGON-319: --- See also https://github.com/demobox/wagon-webdav-jackrabbit/ > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: WAGON-319 > URL: http://jira.codehaus.org/browse/WAGON-319 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531-corrected-style.diff, > patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/support/issues/detail?id=4786). There is a > suspicion that '/./' part of URL is an error cause. > It has been discussed also on Maven mailing list: > http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html > Because I don't know exactly which Maven plugin is responsible for URL
[jira] Commented: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[
http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264478#action_264478
]
Andrew Phillips commented on MSITE-531:
---
@Lukas: well, it depends a bit on whether you see the ability to provide
normalized URLs as the responsbility of the Site plugin or not. Currently, the
unnormalized URL that is causing the problem with Google Code is straight from
{{site.distributionManagement.url}}.
But indeed, the issue currently affects only DAV on Google Code, and it's not
really a bug in the wagon either, just a feature request (the bug is on
Google's side). Hence my annoyed comment [1] over at the correct issue,
WAGON-319 ;-)
As far as I'm concerned you can mark this as "Not a bug" and refer to the wagon
issue.
[1]
http://jira.codehaus.org/browse/WAGON-319?focusedCommentId=264473&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_264473
> Site deployment fails on googlecode repository (unnecessary '/./' path
> element in WebDAV URL)
> -
>
> Key: MSITE-531
> URL: http://jira.codehaus.org/browse/MSITE-531
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.1, 3.0-beta-3
> Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2,
> wagon-webdav-jackrabbit 1.0-beta-7
>Reporter: Marcin Kuthan
> Attachments: patch-MSITE-531-corrected-style.diff,
> patch-MSITE-531.diff
>
>
> Hi,
> I configured my project to use Wagon WebDAV provider to deploy project
> site. In general it works as I expected but it fails if the site is
> deployed on googlecode.
> Transfer error: org.apache.maven.wagon.TransferFailedException: Failed
> to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site:
> Failed to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
>
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to
> transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/ma
[jira] Issue Comment Edited: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[
http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264478#action_264478
]
Andrew Phillips edited comment on MSITE-531 at 4/23/11 7:30 AM:
@Lukas: well, it depends a bit on whether you see the ability to provide
normalized URLs as the responsibility of the Site plugin or not. Currently, the
unnormalized URL that is causing the problem with Google Code is straight from
{{site.distributionManagement.url}}.
But indeed, the issue currently affects only DAV on Google Code, and it's not
really a bug in the wagon either, just a feature request (the bug is on
Google's side). Hence my annoyed comment [1] over at the correct issue,
WAGON-319 ;-)
As far as I'm concerned you can mark this as "Not a bug" and refer to the wagon
issue.
Happy Easter!
[1]
http://jira.codehaus.org/browse/WAGON-319?focusedCommentId=264473&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_264473
was (Author: demobox):
@Lukas: well, it depends a bit on whether you see the ability to provide
normalized URLs as the responsbility of the Site plugin or not. Currently, the
unnormalized URL that is causing the problem with Google Code is straight from
{{site.distributionManagement.url}}.
But indeed, the issue currently affects only DAV on Google Code, and it's not
really a bug in the wagon either, just a feature request (the bug is on
Google's side). Hence my annoyed comment [1] over at the correct issue,
WAGON-319 ;-)
As far as I'm concerned you can mark this as "Not a bug" and refer to the wagon
issue.
[1]
http://jira.codehaus.org/browse/WAGON-319?focusedCommentId=264473&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_264473
> Site deployment fails on googlecode repository (unnecessary '/./' path
> element in WebDAV URL)
> -
>
> Key: MSITE-531
> URL: http://jira.codehaus.org/browse/MSITE-531
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.1, 3.0-beta-3
> Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2,
> wagon-webdav-jackrabbit 1.0-beta-7
>Reporter: Marcin Kuthan
> Attachments: patch-MSITE-531-corrected-style.diff,
> patch-MSITE-531.diff
>
>
> Hi,
> I configured my project to use Wagon WebDAV provider to deploy project
> site. In general it works as I expected but it fails if the site is
> deployed on googlecode.
> Transfer error: org.apache.maven.wagon.TransferFailedException: Failed
> to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site:
> Failed to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>
[jira] Updated: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated MSITE-531: -- Attachment: patch-MSITE-531-corrected-style.diff Corrected a style error (opening bracket on wrong line) > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: MSITE-531 > URL: http://jira.codehaus.org/browse/MSITE-531 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.1, 3.0-beta-3 > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531-corrected-style.diff, > patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/support/issues/detail
[jira] Updated: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated WAGON-319: -- Attachment: patch-MSITE-531-corrected-style.diff Corrected a style error (opening bracket on wrong line) > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: WAGON-319 > URL: http://jira.codehaus.org/browse/WAGON-319 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531-corrected-style.diff, > patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/support/issues/detail?id=4786). There is a > suspicion that '/./' part of URL is an error cause. > It has been discussed also on Maven mailing list: > http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html > Because I don't know exactly which Maven plugin is responsible for URL >
[jira] Commented: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264473#action_264473 ] Andrew Phillips commented on WAGON-319: --- #*^#$#&...added comments and patch to the "wrong" issue. See http://jira.codehaus.org/browse/MSITE-531?focusedCommentId=264471&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_264471 http://jira.codehaus.org/browse/MSITE-531?focusedCommentId=264472&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_264472 Patch also attached here again, for convenience. > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: WAGON-319 > URL: http://jira.codehaus.org/browse/WAGON-319 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/suppor
[jira] Updated: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated WAGON-319: -- Attachment: patch-MSITE-531.diff > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: WAGON-319 > URL: http://jira.codehaus.org/browse/WAGON-319 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/support/issues/detail?id=4786). There is a > suspicion that '/./' part of URL is an error cause. > It has been discussed also on Maven mailing list: > http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html > Because I don't know exactly which Maven plugin is responsible for URL > pre-processing during site deployment, the similar issue was created for site > plugin: > http://jira.codehaus.o
[jira] Updated: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated MSITE-531: -- Attachment: patch-MSITE-531.diff > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: MSITE-531 > URL: http://jira.codehaus.org/browse/MSITE-531 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.1, 3.0-beta-3 > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode bug tracker > (http://code.google.com/p/support/issues/detail?id=4786). There is a > suspicion that '/./' part of URL is an error cause. > It has been discussed also on Mave
[jira] Commented: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[ http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264472#action_264472 ] Andrew Phillips commented on MSITE-531: --- Patched based on 1.0-beta-8-SNAPSHOT rev 1095983 attached, with test cases. A build of the JAR is also available at http://www.mediafire.com/?6971gq1cqqxw4dq. > Site deployment fails on googlecode repository (unnecessary '/./' path > element in WebDAV URL) > - > > Key: MSITE-531 > URL: http://jira.codehaus.org/browse/MSITE-531 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.1, 3.0-beta-3 > Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2, > wagon-webdav-jackrabbit 1.0-beta-7 >Reporter: Marcin Kuthan > Attachments: patch-MSITE-531.diff > > > Hi, > I configured my project to use Wagon WebDAV provider to deploy project > site. In general it works as I expected but it fails if the site is > deployed on googlecode. > Transfer error: org.apache.maven.wagon.TransferFailedException: Failed > to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site: > Failed to transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy > (default-deploy) on project corporate-pom: Error uploading site > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to > transfer file: > https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css. > Return code is: 500 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:188) > > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:182) > > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:257) > ... 21 more > I filled an issue in googlecode
[jira] Commented: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[
http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264471#action_264471
]
Andrew Phillips commented on MSITE-531:
---
OK, so the first part of the fix was relatively simple, replacing the above
snippet with
{code}
String target = UriUtils.normalizePath( destinationDirectory + "/" +
listFiles[i].getName() );
if ( listFiles[i].isDirectory() )
{
putDirectory( listFiles[i], target );
}
else
{
put( listFiles[i], target );
}
{code}
where {{normalizePath}} simply calls {{URI.normalize()}} [1].
This would be enough in this test case, but in a multi-module project Maven
produces URLs like
https://jclouds.googlecode.com/svn/maven-sites/jclouds-project/1.0-SNAPSHOT/../../../jclouds-project/1.0-SNAPSHOT/css/maven-base.css
and Google Code is also not able to deal with the '../../..' part.
Unfortunately, that bit sits inside the repository URL [2], which isn't so
easily accessible. One reasonable place to intercept this repo whilst limiting
the effects to the WebDavWagon is to intercept the original {{connect}} method
in AbstractWagon [3] as follows:
{code}
public void connect( Repository repository, AuthenticationInfo
authenticationInfo, ProxyInfoProvider proxyInfoProvider )
throws ConnectionException, AuthenticationException
{
repository.setUrl( UriUtils.normalizeUrl( repository.getUrl(),
repository.getBasedir() ) );
super.connect( repository, authenticationInfo, proxyInfoProvider );
}
{code}
{{normalizeUrl}} has to do some slightly funky things here because Maven
Wagon's PathUtils [4] aren't able to deal with a 'dav:https' URL properly, but
the test cases all pass.
[1] http://download.oracle.com/javase/6/docs/api/java/net/URI.html#normalize()
[2]
http://maven.apache.org/plugins/maven-site-plugin/xref/org/apache/maven/plugins/site/wagon/repository/Repository.html
[3]
http://maven.apache.org/wagon/wagon-provider-api/xref/org/apache/maven/wagon/AbstractWagon.html
[4]
http://maven.apache.org/plugins/maven-site-plugin/xref/org/apache/maven/plugins/site/wagon/PathUtils.html
> Site deployment fails on googlecode repository (unnecessary '/./' path
> element in WebDAV URL)
> -
>
> Key: MSITE-531
> URL: http://jira.codehaus.org/browse/MSITE-531
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.1, 3.0-beta-3
> Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2,
> wagon-webdav-jackrabbit 1.0-beta-7
>Reporter: Marcin Kuthan
>
> Hi,
> I configured my project to use Wagon WebDAV provider to deploy project
> site. In general it works as I expected but it fails if the site is
> deployed on googlecode.
> Transfer error: org.apache.maven.wagon.TransferFailedException: Failed
> to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site:
> Failed to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(D
[jira] Commented: (WAGON-319) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[
http://jira.codehaus.org/browse/WAGON-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264363#action_264363
]
Andrew Phillips commented on WAGON-319:
---
As regards MSITE-531, it would appear the WebDavWagon is responsible for this
(see
http://jira.codehaus.org/browse/MSITE-531?focusedCommentId=264362&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_264362).
It's inside WebDavWagon:539ff [1] where
{code}
public void putDirectory( File sourceDirectory, String destinationDirectory )
...
// either
putDirectory( listFiles[i], destinationDirectory + "/" +
listFiles[i].getName() );
// or
String target = destinationDirectory + "/" + listFiles[i].getName();
put( listFiles[i], target );
{code}
where {{destinationDirectory}}, which comes from SiteDeployMojo, is {{.}}.
[1]
http://maven.apache.org/wagon/wagon-providers/wagon-webdav/xref/org/apache/maven/wagon/providers/webdav/WebDavWagon.html
> Site deployment fails on googlecode repository (unnecessary '/./' path
> element in WebDAV URL)
> -
>
> Key: WAGON-319
> URL: http://jira.codehaus.org/browse/WAGON-319
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
> Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2,
> wagon-webdav-jackrabbit 1.0-beta-7
>Reporter: Marcin Kuthan
>
> Hi,
> I configured my project to use Wagon WebDAV provider to deploy project
> site. In general it works as I expected but it fails if the site is
> deployed on googlecode.
> Transfer error: org.apache.maven.wagon.TransferFailedException: Failed
> to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site:
> Failed to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
>
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to
> transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368)
>
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280)
>
> at
> org.apache.maven.wagon.providers.webdav.WebD
[jira] Commented: (MSITE-531) Site deployment fails on googlecode repository (unnecessary '/./' path element in WebDAV URL)
[
http://jira.codehaus.org/browse/MSITE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264362#action_264362
]
Andrew Phillips commented on MSITE-531:
---
I think you'll find the offending code is indeed in the WebDAV wagon. The
SiteDeployMojo [1] calls, in line 215
{code}
wagon.putDirectory( inputDirectory, "." );
{code}
where inputDirectory is presumably the site source. WebDavWagon [2] then starts
with (lines 539ff)
{code}
public void putDirectory( File sourceDirectory, String destinationDirectory )
...
// either
putDirectory( listFiles[i], destinationDirectory + "/" +
listFiles[i].getName() );
// or
String target = destinationDirectory + "/" + listFiles[i].getName();
put( listFiles[i], target );
{code}
where {{destinationDirectory}} is {{.}}.
[1]
http://maven.apache.org/plugins/maven-site-plugin/xref/org/apache/maven/plugins/site/SiteDeployMojo.html
[2]
http://maven.apache.org/wagon/wagon-providers/wagon-webdav/xref/org/apache/maven/wagon/providers/webdav/WebDavWagon.html
> Site deployment fails on googlecode repository (unnecessary '/./' path
> element in WebDAV URL)
> -
>
> Key: MSITE-531
> URL: http://jira.codehaus.org/browse/MSITE-531
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.1, 3.0-beta-3
> Environment: Maven 2.2.1, 3.0.1, wagon-webdav 1.0-beta-2,
> wagon-webdav-jackrabbit 1.0-beta-7
>Reporter: Marcin Kuthan
>
> Hi,
> I configured my project to use Wagon WebDAV provider to deploy project
> site. In general it works as I expected but it fails if the site is
> deployed on googlecode.
> Transfer error: org.apache.maven.wagon.TransferFailedException: Failed
> to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site:
> Failed to transfer file:
> https://m4enterprise.googlecode.com/svn/site/./css/maven-base.css.
> Return code is: 500 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy
> (default-deploy) on project corporate-pom: Error uploading site
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:271)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
>
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to
> transfer file:
> https://m4enterprise.googlecode.com/sv
[jira] Commented: (MASSEMBLY-457) The empty assemblies should be skipped in multimodule projects.
[ http://jira.codehaus.org/browse/MASSEMBLY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236543#action_236543 ] Andrew Phillips commented on MASSEMBLY-457: --- @John: I see your point. However, Kek already mentioned this possibility in the description and indicated why it isn't a sufficient solution in some situations: > I know, there could be used a "skip" parameter for assembly deactivation > in submodules, but this solution is not effective for management in large > projects (we have about 1000 submodules). Seems like a valid point, too. So whilst auto-skipping by default would indeed be a dangerous idea, is there any reason why auto-skipping behaviour couldn't be explicitly enabled via some parameter? Again, from the description: > May be - some new parameter "ignoreEmptyAssembly" should be added to > switch on/off the behaviour of this patch. > The empty assemblies should be skipped in multimodule projects. > --- > > Key: MASSEMBLY-457 > URL: http://jira.codehaus.org/browse/MASSEMBLY-457 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-5 > Environment: Windows7, java1.6, maven 2.2.1 or Linux + Hudson 1.33x >Reporter: Kek >Assignee: John Casey >Priority: Critical > Fix For: 2.2-beta-6 > > Attachments: patch.txt, test-modules.zip > > > Our workspace contains > - multimodule project (like in attached test-modules.zip) > - defined assembly on parent to zip src/main/config or src/test/config > folders and attach the zip to module > - but some child-modules could have empty config folders > than we obtain > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create > assembly: Error creating assembly archive config: You must set at least one > file. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > 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:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive config: You must set at least one > file. > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:421) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > ... 17 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive config: You must set at least one file. > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:194) > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:370) > ... 19 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at > least one file. > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:272) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:250) > at > org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:8
[jira] Commented: (MSITE-505) Unable to use SVN SCM wagon to upload a site
[ http://jira.codehaus.org/browse/MSITE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235853#action_235853 ] Andrew Phillips commented on MSITE-505: --- See also http://mail-archives.apache.org/mod_mbox/maven-users/201009.mbox/%3c560995.77447...@web25505.mail.ukl.yahoo.com%3e > Unable to use SVN SCM wagon to upload a site > > > Key: MSITE-505 > URL: http://jira.codehaus.org/browse/MSITE-505 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-2 > Environment: Maven 3.0-beta-3 (r990787; 2010-08-30 14:44:03+0200) > Maven site plugin 3.0-beta-3-SNAPSHOT >Reporter: Andrew Phillips > Attachments: mvn-X-output.txt, pom.xml > > > Even though the SCM project is apparently able to correctly pick up the SVN > provider in the attached POM, the site plugin is unable to deploy to a site > with an 'scm:svn...' URL and warns that > [WARNING] No SCM providers configured. > Here the abbreviated output of two commands - see the attachment for the full > output. > > mvn scm:status > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building SCM deploy:site test 1.0-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-scm-plugin:1.4:status (default-cli) @ scm-deploy-test --- > [INFO] Executing: cmd.exe /X /C "svn --non-interactive status" > [INFO] Working directory: XXX > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > > mvn site:deploy -X > [DEBUG] The site will be deployed to url 'scm:svn:https://acme.com/svn/site' > with id 'scm-deploy-test-site' > [DEBUG] repository protocol scm > [DEBUG] getProxy 'protocol' : scm > [DEBUG] getProxy 'protocol' : scm no ProxyInfo found > [DEBUG] found proxyInfo null > [DEBUG] authenticationInfo with id 'scm-deploy-test-site' : null > [WARNING] No SCM providers configured. > [DEBUG] configureWagon > [DEBUG] configureWagon server XXX > ... > [DEBUG] configureWagon server XXX > [DEBUG] connect with authenticationInfo and without proxyInfo > scm:svn:https://acme.com/svn/site - Session: Opened > Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No > such provider: 'svn'. > scm:svn:https://acme.com/svn/site - Session: Disconnecting > scm:svn:https://acme.com/svn/site - Session: Disconnected > [INFO] > > [INFO] BUILD FAILURE > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-505) Unable to use SVN SCM wagon to upload a site
[ http://jira.codehaus.org/browse/MSITE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235852#action_235852 ] Andrew Phillips commented on MSITE-505: --- The POM includes commented-out experiments involving adding the SVN provider to the SCM and/or site plugins as plugin dependencies, and/or setting true. Unfortunately, neither of these helped. One thing I noticed is that the site plugin's POM [1] contains dependencies on (amongst others) the WebDAV wagon, but not on any SVN SCM providers (WebDAV works fine for publishing sites). [1] https://svn.apache.org/repos/asf/maven/plugins/branches/maven-site-plugin-3.x/pom.xml > Unable to use SVN SCM wagon to upload a site > > > Key: MSITE-505 > URL: http://jira.codehaus.org/browse/MSITE-505 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-2 > Environment: Maven 3.0-beta-3 (r990787; 2010-08-30 14:44:03+0200) > Maven site plugin 3.0-beta-3-SNAPSHOT >Reporter: Andrew Phillips > Attachments: mvn-X-output.txt, pom.xml > > > Even though the SCM project is apparently able to correctly pick up the SVN > provider in the attached POM, the site plugin is unable to deploy to a site > with an 'scm:svn...' URL and warns that > [WARNING] No SCM providers configured. > Here the abbreviated output of two commands - see the attachment for the full > output. > > mvn scm:status > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building SCM deploy:site test 1.0-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-scm-plugin:1.4:status (default-cli) @ scm-deploy-test --- > [INFO] Executing: cmd.exe /X /C "svn --non-interactive status" > [INFO] Working directory: XXX > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > > mvn site:deploy -X > [DEBUG] The site will be deployed to url 'scm:svn:https://acme.com/svn/site' > with id 'scm-deploy-test-site' > [DEBUG] repository protocol scm > [DEBUG] getProxy 'protocol' : scm > [DEBUG] getProxy 'protocol' : scm no ProxyInfo found > [DEBUG] found proxyInfo null > [DEBUG] authenticationInfo with id 'scm-deploy-test-site' : null > [WARNING] No SCM providers configured. > [DEBUG] configureWagon > [DEBUG] configureWagon server XXX > ... > [DEBUG] configureWagon server XXX > [DEBUG] connect with authenticationInfo and without proxyInfo > scm:svn:https://acme.com/svn/site - Session: Opened > Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No > such provider: 'svn'. > scm:svn:https://acme.com/svn/site - Session: Disconnecting > scm:svn:https://acme.com/svn/site - Session: Disconnected > [INFO] > > [INFO] BUILD FAILURE > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-505) Unable to use SVN SCM wagon to upload a site
Unable to use SVN SCM wagon to upload a site Key: MSITE-505 URL: http://jira.codehaus.org/browse/MSITE-505 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 3.0-beta-2 Environment: Maven 3.0-beta-3 (r990787; 2010-08-30 14:44:03+0200) Maven site plugin 3.0-beta-3-SNAPSHOT Reporter: Andrew Phillips Attachments: mvn-X-output.txt, pom.xml Even though the SCM project is apparently able to correctly pick up the SVN provider in the attached POM, the site plugin is unable to deploy to a site with an 'scm:svn...' URL and warns that [WARNING] No SCM providers configured. Here the abbreviated output of two commands - see the attachment for the full output. > mvn scm:status [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building SCM deploy:site test 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-scm-plugin:1.4:status (default-cli) @ scm-deploy-test --- [INFO] Executing: cmd.exe /X /C "svn --non-interactive status" [INFO] Working directory: XXX [INFO] [INFO] BUILD SUCCESS [INFO] > mvn site:deploy -X [DEBUG] The site will be deployed to url 'scm:svn:https://acme.com/svn/site' with id 'scm-deploy-test-site' [DEBUG] repository protocol scm [DEBUG] getProxy 'protocol' : scm [DEBUG] getProxy 'protocol' : scm no ProxyInfo found [DEBUG] found proxyInfo null [DEBUG] authenticationInfo with id 'scm-deploy-test-site' : null [WARNING] No SCM providers configured. [DEBUG] configureWagon [DEBUG] configureWagon server XXX ... [DEBUG] configureWagon server XXX [DEBUG] connect with authenticationInfo and without proxyInfo scm:svn:https://acme.com/svn/site - Session: Opened Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No such provider: 'svn'. scm:svn:https://acme.com/svn/site - Session: Disconnecting scm:svn:https://acme.com/svn/site - Session: Disconnected [INFO] [INFO] BUILD FAILURE [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
http://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233302#action_233302
]
Andrew Phillips commented on MNG-4687:
--
I ran into this problem setting up a Maven project to be hosted by the de-facto
"Maven people" themselves on the Nexus OSS server [1], and got the following
answer from Juven Xu at Sonatype:
> From: Juven Xu <@sonatype.com>
> Subject: Re: Inheriting from oss-parent for Nexus releases causes warning?
>
> IMO Maven should not log this warning if no relativePath is specified. The
> project structure has no problem, it's a problem of Maven.
So I guess that should count as another +1 vote ;-)
[1]
https://docs.sonatype.org/display/repository/sonatype+oss+maven+repository+usage+guide#SonatypeOSSMavenRepositoryUsageGuide-7.POMandsettingsconfig
> Maven should not warn about incorrect parent path when no relativePath is
> specified
> ---
>
> Key: MNG-4687
> URL: http://jira.codehaus.org/browse/MNG-4687
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 3.0-beta-1
>Reporter: Paul Gier
>Priority: Minor
> Attachments: MNG-relativePath.zip
>
>
> If a module pom uses a parent other than the one in the parent directory,
> maven logs a warning. In some cases it is necessary that a module pom has an
> external parent pom, and there is no way to refer to this external pom in the
> relativePath. If nothing is specified in the relativePath, Maven should not
> log the warning.
> {noformat}
> [WARNING] 'parent.relativePath' of POM
> org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
> (/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
> org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
> please verify your project structure @
> {noformat}
> The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ http://jira.codehaus.org/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201883#action_201883 ] Andrew Phillips commented on MASSEMBLY-360: --- @Keith: looks like we have a very similar set-up; the difference is that in our case the "merged" spring.handlers and spring.schemas files (see Chris Wilkes' comment above) are kept in src/main/resources/META-INF, i.e. not generated automatically during the build phase. That's not quite so nice, but since a project's Spring dependencies are generally unchanging it's not *that* much work to keep these files up to date manually. The assembly descriptor section is then simply: true META-INF/spring.handlers META-INF/spring.schemas ... and the spring.handlers and spring.schemas file from src/main/resources/META-INF is included automatically. > When using mulitple Spring dependencies, the files from META-INF (from the > Spring jars) overwrite each other in an executable jar-with-dependencies. > > > Key: MASSEMBLY-360 > URL: http://jira.codehaus.org/browse/MASSEMBLY-360 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Windows XP, Java 5 >Reporter: Marielle Enderman > > I'm working on a Java 5 project with maven 2 and I need to deliver an > executable jar file. In this project I'm using different Spring dependencies: > >org.springframework > spring-beans > 2.5.5 > > > org.springframework > spring-context > 2.5.5 > > For maven packaging I'm using the maven-assembly plugin to create an > executable jar with dependencies (using the jar-with-dependencies > descriptor). Everything works fine, except that Spring's XSD files can't be > found. At least: not all of them. The fact is: Every Spring JAR file contains > a META-INF directory with files like spring.handlers and spring.schemas which > contain list of locations of respectively namespace handlers and schemas. > Unfortunately these files aren't merged during packaging so the META_INF of > the executable JAR file only contains the last one added. > This can result in errors like this: > Example 1: The spring-context-2.5.xsd can't be found: > WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored > XML validation warning org.xml.sax.SAXParseException: schema_reference.4: > Failed to read schema document > 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', > because 1) could not find the document; 2) the document could not be read; 3) > the root element of the document is not . > Example 2: The NamespaceHandler for the spring context namespace can't be > located: > Exception in thread "main" > org.springframework.beans.factory.parsing.BeanDefinitionParsingException: > Configuration problem: Unable to locate Spring NamespaceHandler for XML > schema namespace [http://www.springframework.org/schema/context] > When I manually merge the files, the executable JAR file works fine. > I hope this problem can be solved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
