[jira] (MNGSITE-223) No need to setup M2_HOME environment at http://maven.apache.org/download.cgi
Dan Tran created MNGSITE-223: Summary: No need to setup M2_HOME environment at http://maven.apache.org/download.cgi Key: MNGSITE-223 URL: https://jira.codehaus.org/browse/MNGSITE-223 Project: Maven Project Web Site Issue Type: Task Reporter: Dan Tran Starting with Maven 2.1 M2_HOME is self-discover at bin/mvn script. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ https://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane StClair updated MNG-1991: --- Attachment: war-deps.tar Comment duplicated on MWAR-253, but example project is also relevant here so I'll cross-post. Example project attached (also at https://github.com/srstclair/war-deps) shows the current behavior, meaning that transitive dependencies of the war dependency are not available on the classpath (the war-deps-via-war module's tests fail). I agree that transitive dependencies should be resolved for war dependencies. Currently the best workaround I can come up with is to declare a second dependency on the war's pom, which does add transitive dependencies to the classpath (see war-deps-overlay). Is that the recommended approach? > Can't get transitive dependencies from a war pom when this war is added as a > depdency of a project > -- > > Key: MNG-1991 > URL: https://jira.codehaus.org/browse/MNG-1991 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2 >Reporter: Emmanuel Venisse > Attachments: war-deps.tar > > > I have a project (continuum-core-it) that need to use all transitive > dependencies of a war (continuum-webapp). If i add the war as a dependency of > the project with packaging war, war dependencies aren't shown by project, > maven doesn't try to resolve them and doesn't add them in classpath. > If if replace packaging from war to pom, all dependencies are resolved and > added to classpath. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.
[ https://jira.codehaus.org/browse/MWAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane StClair updated MWAR-253: --- Attachment: war-deps.tar Example project attached (also at https://github.com/srstclair/war-deps) shows the current behavior, meaning that transitive dependencies of the war dependency are not available on the classpath (the war-deps-via-war module's tests fail). I agree with Maarten that transitive dependencies should be resolved for war dependencies. Currently the best workaround I can come up with is to declare a second dependency on the war's pom, which does add transitive dependencies to the classpath (see war-deps-overlay). Is that the recommended approach? > Inherit dependencies from a WAR type dependency when it is overlayed. > - > > Key: MWAR-253 > URL: https://jira.codehaus.org/browse/MWAR-253 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Maarten Billemont > Attachments: war-deps.tar > > > When WAR artifact B depends on WAR artifact A, and also defines an overlay of > A, B should inherit all A's dependencies. > This issue is related to MNG-1991, but can be resolved without much > discussion as it's unrelated to skinny WARs and such. > Classes in B are guaranteed to have runtime access to all A's declared > dependencies when A is an overlay of B. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-230) make it easier to set the HTTP user agent in a configurable way across HTTP wagons, and provide a default for Wagon
[ https://jira.codehaus.org/browse/WAGON-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361768#comment-361768 ] Robert Scholte commented on WAGON-230: -- [~brettporter], does WAGON-401 match your requirements enough? > make it easier to set the HTTP user agent in a configurable way across HTTP > wagons, and provide a default for Wagon > --- > > Key: WAGON-230 > URL: https://jira.codehaus.org/browse/WAGON-230 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight, wagon-webdav >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter > Fix For: 1.1 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-412) Error injecting constructor, java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
[ https://jira.codehaus.org/browse/WAGON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed WAGON-412. Resolution: Duplicate Assignee: Robert Scholte > Error injecting constructor, java.lang.NoClassDefFoundError: > org/apache/commons/logging/LogFactory > -- > > Key: WAGON-412 > URL: https://jira.codehaus.org/browse/WAGON-412 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 2.6 > Environment: Apache Maven 3.1.1 > (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 16:22:22+0100) > Maven home: /opt/maven.apache.org/apache-maven-3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: /home/david/opt/java.sun.com/jdk1.7.0_45/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "3.8.0-35-generic", arch: "amd64", family: "unix" >Reporter: David Ireland >Assignee: Robert Scholte >Priority: Critical > Attachments: webdav-error.log > > > When I try to deploy using the wagon, it fails to initialise with the > attached error. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-409) Wagon-webdav-jackrabbit throws Class Not Found Exception.
[ https://jira.codehaus.org/browse/WAGON-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed WAGON-409. Resolution: Fixed Fix Version/s: 2.9 Assignee: Robert Scholte Fixed in [6543c88c0099e22c845552bbbc9862d517b7be1b|http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/6543c88c] > Wagon-webdav-jackrabbit throws Class Not Found Exception. > - > > Key: WAGON-409 > URL: https://jira.codehaus.org/browse/WAGON-409 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 2.5, 2.6 > Environment: Maven 3.1.1, fedora, jenkins >Reporter: Eric Barboni >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.9 > > Attachments: dependenciesfix.patch, log.txt > > > I try to upgrade to the 2.6 version of jackrabbit wagon on a previoulsy > working project (with version 2.4). > During instantiation of MultiThreadedHttpConnectionManager the LogFactory > class is not available and break deploy. > The removal of dependencies wagon-http-shared after 2.4 seems to be the cause > of the issue. http-shared was providing commons logging as transitive > dependencies ofr jackrabbit. > Best Regards > I copy paste extract from the jenkins logs in attachement. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-434) Remove test-scope for slf4j deps in dependencyManagement
[
https://jira.codehaus.org/browse/WAGON-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed WAGON-434.
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Robert Scholte
Fixed in
[f4b0c9c309b71f51e757f0db8e084de1975eede1|http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/f4b0c9c3]
> Remove test-scope for slf4j deps in dependencyManagement
>
>
> Key: WAGON-434
> URL: https://jira.codehaus.org/browse/WAGON-434
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.8
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 2.9
>
>
> The slf4j dependencies have {{test}} as their scope. However, if one of the
> third party dependencies depends on slf4j, some issues will appear at
> runtime. Giving a dependency the test-scope implies that it is not available
> at runtime anymore.
> Wagen-webDAV is one module which is effected by this.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-434) Remove test-scope for slf4j deps in dependencyManagement
Robert Scholte created WAGON-434:
Summary: Remove test-scope for slf4j deps in dependencyManagement
Key: WAGON-434
URL: https://jira.codehaus.org/browse/WAGON-434
Project: Maven Wagon
Issue Type: Bug
Components: wagon-webdav
Affects Versions: 2.8
Reporter: Robert Scholte
The slf4j dependencies have {{test}} as their scope. However, if one of the
third party dependencies depends on slf4j, some issues will appear at runtime.
Giving a dependency the test-scope implies that it is not available at runtime
anymore.
Wagen-webDAV is one module which is effected by this.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-404) Wagon webdav not honoring relative path
[ https://jira.codehaus.org/browse/WAGON-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361760#comment-361760 ] Robert Scholte commented on WAGON-404: -- Could you add some configuration how and where you want to use relative paths? > Wagon webdav not honoring relative path > --- > > Key: WAGON-404 > URL: https://jira.codehaus.org/browse/WAGON-404 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 2.2 >Reporter: Gangadharan Ramakrishnan > > We are using maven 3.0.4 with maven site plugin 3.3 and > wagon-webdav-jackrabbit 2.2 version. Appears like wagon is not honoring the > relative path and fails with 500 status code while uploading sitedocs to > nexus. I tried searching all forums however seems to be an existing issue and > did not find a fix. I even tried using until 2.5 to test and the bug exists > in the latest version as well > Appreciate if there is a fix/workaround to this problem > 09:07:41 [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:deploy (default-cli) on > project : Error uploading site: Failed to transfer file: > http://nexus.x.com:8081/nexus/content/repositories/site/com..maven/xx/1.0.2/../../../com..//1.0.0-SNAPSHOT///apidocs/index.html. > Return code is: 500 -> [Help 1] -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-377) Webdab upload fails frequently
[
https://jira.codehaus.org/browse/WAGON-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361759#comment-361759
]
Robert Scholte commented on WAGON-377:
--
In case of the {{maven-deploy-plugin}} there's already such a parameter
[retryFailedDeploymentCount|http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#retryFailedDeploymentCount]
> Webdab upload fails frequently
> --
>
> Key: WAGON-377
> URL: https://jira.codehaus.org/browse/WAGON-377
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-webdav
>Affects Versions: 2.2
> Environment: Linux
>Reporter: Albert Kurucz
>
> My problem is really not with the WebDAV component of the WAGON, but my
> internet connection is unreliable sometimes. mvn release:perform needs to
> upload huge number of files and frequently I am getting
> "java.net.SocketException: Connection reset" in the middle of the process.
> As a workaround: besides I would like to have
> adjustable for WebDAV. Maybe it is already possible somehow to setRetryCount,
> but I am just not informed.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-409) Wagon-webdav-jackrabbit throws Class Not Found Exception.
[ https://jira.codehaus.org/browse/WAGON-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361758#comment-361758 ] Robert Scholte commented on WAGON-409: -- http://search.maven.org/#artifactdetails%7Corg.apache.jackrabbit%7Cjackrabbit-webdav%7C2.9.0%7Cbundle I see that they've chosen to use jcl-over-slj4j. I think we should do the same. > Wagon-webdav-jackrabbit throws Class Not Found Exception. > - > > Key: WAGON-409 > URL: https://jira.codehaus.org/browse/WAGON-409 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 2.5, 2.6 > Environment: Maven 3.1.1, fedora, jenkins >Reporter: Eric Barboni >Priority: Critical > Attachments: dependenciesfix.patch, log.txt > > > I try to upgrade to the 2.6 version of jackrabbit wagon on a previoulsy > working project (with version 2.4). > During instantiation of MultiThreadedHttpConnectionManager the LogFactory > class is not available and break deploy. > The removal of dependencies wagon-http-shared after 2.4 seems to be the cause > of the issue. http-shared was providing commons logging as transitive > dependencies ofr jackrabbit. > Best Regards > I copy paste extract from the jenkins logs in attachement. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361756#comment-361756
]
Kristian Rosenvold commented on MASSEMBLY-742:
--
Sorry for not telling, but I already fixed this on trunk. You could verify the
fix since you have it all checked out.
And yes, we're waiting for commons-compress 1.10, which should arrive in a week
or two.
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5605: Fix Version/s: 3.2.6 > ssh-wagon hangs > --- > > Key: MNG-5605 > URL: https://jira.codehaus.org/browse/MNG-5605 > Project: Maven > Issue Type: Bug > Components: Deployment >Affects Versions: 3.2.1 >Reporter: Frank Cornelis >Priority: Blocker > Fix For: 3.2.6 > > > When releasing (using maven-release-plugin) via Maven 3.1.1 everything works > as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden > hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
