http://blog.gmane.org/gmane.comp.apache.maven.issues hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.apache.maven.issues/38535 <pre> [ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326957#comment-326957 ] Robert Scholte commented on MRELEASE-431: ----------------------------------------- There are at least two options: - through Plexus Components ( example is [Maven Compiler Plugin|http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#420] where you can choose a compiler by its id. Implementations are marked as a Component and can be chosen by the hint. - through Plexus Configuration. I couldn't find a good example, but it should be something like this: {code:xml} &lt;configuration&gt; &lt;versionPolicyManager implementation="com.acme.custom.MyVersionPolicyManager"&gt; &lt;/versionPolicyManager&gt; &lt;/configuration&gt; {code} The advantage of the latter is that it is very straightforward if you want to use additional fields/setters on your VersionPolicyManager. For that reason this would be my choice right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Robert Scholte (JIRA 2013-06-18T21:21:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38534 <pre> [ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326956#comment-326956 ] Robert Munteanu commented on MRELEASE-431: ------------------------------------------ Right, so I'll create a VersionPolicyManager interface, and I can look it up based on the configured versionPolicy parameter. What I'm not sure is how to actually provide and look up implementations for this interface, since I'm not familiar with Maven component wiring. Where can I find the docs or a working example? And for now I can add a release-api project to the release reactor, and you can decide whether to move it to a shared component later, since it would be more difficult for me, not being a Maven committer. WDYT? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Robert Munteanu (JIRA 2013-06-18T20:43:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38533 <pre> [ https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326955#comment-326955 ] Peter Kahn commented on MDEP-406: --------------------------------- Actually, this works for me. I checked my effective pom and found I used version 2.4 which didn't yet support the feature. Thanks and apologies for the churn -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Peter Kahn (JIRA 2013-06-18T19:01:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38532 <pre> [ https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326954#comment-326954 ] Peter Kahn commented on MDEP-406: --------------------------------- I think it is this as I too have this problem. The skip setting in the configuration for at least the copy-dependencies mojo doesn't appear to work properly. I would expect the skip xml below to skip the execution, but it does not. h2. Goal Conditionally execute copy-dependencies for specific modules in my project. h2. Approach * Top level pom defines copy-dependency execution using property *skipIncludeCompileDeps* to control execution * Top level pom sets *skipIncludeCompileDeps* to true * Child poms will automatically skip execution unless they override property definition h2. Root Pom {code} &lt;properties&gt; &lt;skipIncludeCompileDeps&gt;true&lt;/skipIncludeCompileDeps&gt; &lt;/properties&gt; .... &lt;build&gt; &lt;plugins&gt; &lt;plugin&gt; &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt; &lt;artifactId&gt;maven-dependency-plugin&lt;/artifactId&gt; &lt;executions&gt; &lt;execution&gt; &lt;id&gt;ROOT POM: Gather Compile Dependencies For Scan&lt;/id&gt; &lt;phase&gt;validate&lt;/phase&gt; &lt;goals&gt; &lt;goal&gt;copy-dependencies&lt;/goal&gt; &lt;/goals&gt; &lt;configuration&gt; &lt;skip&gt;true&lt;/skip&gt; &lt;includeScope&gt;compile&lt;/includeScope&gt; &lt;outputDirectory&gt;${project.build.directory}/compileScopeDependencies&lt;/outputDirectory&gt; &lt;/configuration&gt; &lt;/execution&gt; &lt;/executions&gt; &lt;/plugin&gt; &lt;/plugins&gt; &lt;/build&gt; {code} h2. Module Using common execution to gather deps {code} ... &lt;properties&gt; &lt;skipIncludeCompileDeps&gt;false&lt;/skipIncludeCompileDeps&gt; &lt;/properties&gt;{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Peter Kahn (JIRA 2013-06-18T18:54:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38531 <pre> [ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326943#comment-326943 ] Robert Scholte commented on MRELEASE-431: ----------------------------------------- There are a lot of issues related to version policies. I could try to collect all wishes, but I'm afraid that I'll forget a few and that in the near future developers invent more exotic ways of version policies. To prevent this, we should define a {{VersionPolicyManager}} interface (probably in the separated {{api}}-project), so everyone can code his own version. It'll be just a matter of injecting your preferred implementation. I'm not sure if I should introduce a {{release-api}} project for this or start a new shared component. With the latter we could also reuse it for the versions-maven-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Robert Scholte (JIRA 2013-06-18T17:38:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38530 <pre> [ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated MRELEASE-431: ------------------------------------- Attachment: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Robert Munteanu (JIRA 2013-06-18T16:06:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38529 <pre> [ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326938#comment-326938 ] Robert Munteanu commented on MRELEASE-431: ------------------------------------------ I've attached a patch which adds a 'versionPolicy' property to the plugin. Possible values are 'default' - which is what the plugin does today - and 'odd-even', which ensures that snapshot dependencies are always odd and release versions are always even. You can also review the [commit on github|https://github.com/rombert/release/commit/35e42901868d5c18289e6687bbecdd78cddbf03e] as well. I tried to keep changes minimal and self-contained and also added tests as well as I could. I'm open to iterating on this so please let me know what you think. Thanks! Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Robert Munteanu (JIRA 2013-06-18T16:06:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38528 <pre> [ https://issues.apache.org/jira/browse/MPOM-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MPOM-44: --------------------- Attachment: MPOM-44.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Sebb (JIRA 2013-06-18T15:05:21 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38527 <pre>Sebb created MPOM-44: ------------------------ Summary: Compiler version settings cannot be overridden by defining maven.compiler.source/target Key: MPOM-44 URL: https://issues.apache.org/jira/browse/MPOM-44 Project: Maven POMs Issue Type: Bug Components: maven-plugins Affects Versions: ASF-13 Reporter: Sebb The compiler plugin by default picks up the source and target from the properties maven.compiler.source and maven.compiler.target. Unfortunately, the Apache POM uses the following fixed values to specify the version: {code} &lt;build&gt; &lt;pluginManagement&gt; &lt;plugins&gt; &lt;plugin&gt; &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt; &lt;artifactId&gt;maven-compiler-plugin&lt;/artifactId&gt; &lt;version&gt;2.5.1&lt;/version&gt; &lt;configuration&gt; &lt;source&gt;1.4&lt;/source&gt; &lt;target&gt;1.4&lt;/target&gt; &lt;/configuration&gt; {code} This means that child poms which use the properties expecting them to be honoured have to override the configuration as follows: {code} &lt;plugin&gt; &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt; &lt;artifactId&gt;maven-compiler-plugin&lt;/artifactId&gt; &lt;configuration&gt; &lt;source&gt;${maven.compile.source}&lt;/source&gt; &lt;target&gt;${maven.compile.target}&lt;/target&gt; &lt;/configuration&gt; &lt;/plugin&gt; {code} This is unnecessary and wrong. For compatibility, the Apache Pom does need to still specify the default source/target as 1.4 (the plugin default is 1.5), but it should do so by using the standard properties which can then be overridden. In fact, if the properties are defined, the compiler plugin config could be dropped, as it is the default behaviour. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Sebb (JIRA 2013-06-18T14:57:20 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38526 <pre> [ https://jira.codehaus.org/browse/WAGON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326915#comment-326915 ] Olivier Lamy commented on WAGON-381: ------------------------------------ still weird for me. I added a unit test https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=05098b3f0f0378a7272f0d9491ef356889bfc67f And those huge files (with Content-Length or Chunked) are correctly downloaded. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Olivier Lamy (JIRA 2013-06-18T13:38:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38525 <pre>Stefan Fromm created MNG-5485: --------------------------------- Summary: ClassRealmAdapter.getParent() handles null parents incorrectly Key: MNG-5485 URL: https://jira.codehaus.org/browse/MNG-5485 Project: Maven 2 &amp; 3 Issue Type: Bug Affects Versions: 3.0.5 Environment: Java 1.6.0_30, Windows XP Professional 2002 SP3 Reporter: Stefan Fromm Here is the code from plexus classworlds 2.4.x. {noformat} public ClassRealm getParent() { return ClassRealmAdapter.getInstance( realm.getParentRealm() ); } public ClassRealm getParentRealm() { return ClassRealmAdapter.getInstance( realm.getParentRealm() ); } public static ClassRealmAdapter getInstance( org.codehaus.plexus.classworlds.realm.ClassRealm newRealm ) { ClassRealmAdapter adapter = new ClassRealmAdapter( newRealm ); return adapter; } {noformat} If the parent of the backend realm is {{null}}, then there is returned a new {{ClassRealmAdapter}} instead of {{null}}. Calling methods on the returned {{ClassRealmAdapter}} produces NPEs. I think, that {{getParent()}} and {{getParentRealm()}} could be patched like this: {noformat} public ClassRealm getParentRealm() { return realm.getParentRealm() != null ? ClassRealmAdapter.getInstance( realm.getParentRealm()) : null; } public ClassRealm getParent() { return getParentRealm(); } {noformat} Or should {{null}} be handled in {{ClassRealmAdapter.getInstance()}}? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Stefan Fromm (JIRA 2013-06-18T10:03:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38524 <pre> [ https://jira.codehaus.org/browse/MCHECKSTYLE-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326882#comment-326882 ] Oleg Kalnichevski commented on MCHECKSTYLE-194: ----------------------------------------------- [INFO] --- maven-clean-plugin:2.5:clean (default-clean) &lt; at &gt; httpcore --- [INFO] Deleting /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target [INFO] [INFO] --- maven-clover2-plugin:3.1.10.1:setup (default-cli) &lt; at &gt; httpcore --- [INFO] Clover Version 3.1.10, built on January 08 2013 (build-885) [INFO] Loaded from: /home/oleg/.m2/repository/com/cenqua/clover/clover/3.1.10/clover-3.1.10.jar [INFO] Clover: Open Source License registered to Apache. [INFO] Creating new database at '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/clover.db'. [INFO] Processing files at 1.6 source level. [INFO] Clover all over. Instrumented 220 files (15 packages). [INFO] Elapsed time = 1.585 secs. (138.801 files/sec, 18,435.961 srclines/sec) [INFO] Clover Version 3.1.10, built on January 08 2013 (build-885) [INFO] Loaded from: /home/oleg/.m2/repository/com/cenqua/clover/clover/3.1.10/clover-3.1.10.jar [INFO] Clover: Open Source License registered to Apache. [INFO] Updating existing database at '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/clover.db'. [INFO] Processing files at 1.6 source level. [INFO] Clover all over. Instrumented 88 files (15 packages). [INFO] 633 test methods detected. [INFO] Elapsed time = 0.76 secs. (115.789 files/sec, 22,477.633 srclines/sec) [INFO] [INFO] --- maven-checkstyle-plugin:2.9.1:checkstyle (validate) &lt; at &gt; httpcore --- [INFO] Starting audit... /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/src-instrumented/org/apache/http/ProtocolException.java:1: Line does not match expected header line of '/*'. /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/src-instrumented/org/apache/http/concurrent/Cancellable.java:1: Line does not match expected header line of '/*'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Oleg Kalnichevski (JIRA 2013-06-18T09:23:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38523 <pre>Oleg Kalnichevski created MCHECKSTYLE-194: --------------------------------------------- Summary: Stylecheck audit invoked on intermedaite files generated by Clover2 plugin Key: MCHECKSTYLE-194 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-194 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski This issue may not necessarily be a problem with Maven Stylecheck plugin but I just unable to pinpoint the exact culprit here and the Stylecheck appears to be trying to audit intermediate files generated by Clover2 report. I am really unsure how to approach this problem. Please let me know if you need more info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Oleg Kalnichevski (JIRA 2013-06-18T09:23:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38522 <pre>Oleg Kalnichevski created MCHECKSTYLE-193: --------------------------------------------- Summary: Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration Key: MCHECKSTYLE-193 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-193 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski Resource files get included into checkstyle audit regardless of explicit sourceDirectory / includes / excludes configuration, which seems wrong to me. I found no way of forcing version 2.10 to revert to the behavior of version 2.9.1 with regards to project resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Oleg Kalnichevski (JIRA 2013-06-18T08:13:04 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38521 <pre> [ https://jira.codehaus.org/browse/MCHECKSTYLE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326870#comment-326870 ] Oleg Kalnichevski commented on MCHECKSTYLE-193: ----------------------------------------------- [DEBUG] executeCheckstyle start headerLocation : hc-stylecheck/asl2.header [DEBUG] Added 220 source files found in '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/java'. [DEBUG] Added 1 resource files found in '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources'. [DEBUG] Added 221 files to process. [DEBUG] The resource 'null' was not found with resourceLoader org.codehaus.plexus.resource.loader.URLResourceLoader. [DEBUG] The resource 'null' was not found with resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader. [DEBUG] request.getConfigLocation() hc-stylecheck/default.xml [DEBUG] Extension realms for project org.apache.httpcomponents:project:pom:7-SNAPSHOT: (none) [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] [DEBUG] Extension realms for project org.apache:apache:pom:13: (none) [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] ... [INFO] Starting audit... /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources/org/apache/http/version.properties:1: Missing a header - not enough lines in file. /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources/org/apache/http/version.properties:17: Trailing whitespace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Oleg Kalnichevski (JIRA 2013-06-18T08:13:04 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38520 <pre> [ https://jira.codehaus.org/browse/SUREFIRE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen updated SUREFIRE-998: ---------------------------------------- Attachment: pastebin-surefire-encoding-test (1).zip Updated test project which redirects output to file and print the defaultCharset. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Mirko Friedenhagen (JIRA 2013-06-17T20:11:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38519 <pre> [ https://jira.codehaus.org/browse/SUREFIRE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen reopened SUREFIRE-998: ----------------------------------------- Kristian, I am afraid the logic is not working correctly, I updated my test-project at: https://github.com/mfriedenhagen/pastebin/tree/surefire-encoding-test *surefire-2.14.1* {{env JAVA_TOOL_OPTIONS="-Dfile.encoding=ISO-8859-1" mvn -Dmaven-surefire-plugin.version=2.14.1}} Umlauts are encoded (correctly) as ISO-8859-1 in target/surefire-reports/net.friedenhagen.surefireencodingtest.EncodingTest-output.txt and (correctly as stated by the XML-declaration) as UTF-8 in target/surefire-reports/TEST-net.friedenhagen.surefireencodingtest.EncodingTest.xml *surefire-2.15* {{env JAVA_TOOL_OPTIONS="-Dfile.encoding=ISO-8859-1" mvn -Dmaven-surefire-plugin.version=2.15}} Umlauts are encoded (correctly) as ISO-8859-1 in target/surefire-reports/net.friedenhagen.surefireencodingtest.EncodingTest-output.txt and (*incorrectly* as the XML-declaration state they should be UTF-8) as well as ISO-8859-1 in target/surefire-reports/TEST-net.friedenhagen.surefireencodingtest.EncodingTest.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Mirko Friedenhagen (JIRA 2013-06-17T20:08:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38518 <pre> [ https://jira.codehaus.org/browse/SUREFIRE-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326859#comment-326859 ] Andreas Gudian commented on SUREFIRE-1005: ------------------------------------------ Next try - cb908dd79452af854f8c2f7c7d544a3e5abc611d :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Andreas Gudian (JIRA 2013-06-17T19:35:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38517 <pre>Julien Boulay created MDEP-419: ---------------------------------- Summary: dependency:list, dependency:build-classpath and dependency:tree result with the different dependencies order Key: MDEP-419 URL: https://jira.codehaus.org/browse/MDEP-419 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: build-classpath, resolve, tree Affects Versions: 2.8 Reporter: Julien Boulay dependency:list and dependency:build-classpath goals doesn't resolve dependencies in the order declared in the project pom.xml. It should respect the given order as it is done for dependency:tree -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Julien Boulay (JIRA 2013-06-17T13:20:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38516 <pre> [ https://jira.codehaus.org/browse/WAGON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326840#comment-326840 ] Stefan Braune edited comment on WAGON-363 at 6/17/13 8:13 AM: -------------------------------------------------------------- This problem still persists with wagon-ftp:2.4 (and below). I fixed that issue by myself in class org.apache.maven.wagon.providers.ftp.FtpWagon. The issue was, that while making directories recursively, the code tests whether a directory already exists by entering it and seeing whether that worked or not. After that (and maybe after creating the directory) it will enter it again. If the directory already existed (as it is the case for ".."), it enters it a second time. That's the whole bug. The original version reads like this: {code:title=FtpWagon.java (original)} // we only create the nextDir if it doesn't yet exist if (!ftp.changeWorkingDirectory(nextDir)) { ok &amp;= ftp.makeDirectory(nextDir); } if (ok) { // set the permissions for the freshly created directory setPermissions(permissions); ftp.changeWorkingDirectory(nextDir); // now create the deeper directories final String remainingDirs = fileName.substring(slashPos + 1); ok &amp;= makeFtpDirectoryRecursive(remainingDirs, permissions); } {code} The fixed version looks like this (notice the changedDir boolean variable, which fixes the whole thing): {code:title=FtpWagon.java (fixed)} boolean changedDir = false; // we only create the nextDir if it doesn't yet exist if (!ftp.changeWorkingDirectory(nextDir)) { ok &amp;= ftp.makeDirectory(nextDir); } else { changedDir = true; } if (ok) { // set the permissions for the freshly created directory setPermissions(permissions); if (!changedDir) { ftp.changeWorkingDirectory(nextDir); } // now create the deeper directories final String remainingDirs = fileName.substring(slashPos + 1); ok &amp;= makeFtpDirectoryRecursive(remainingDirs, permissions); } {code} I hope, that this patch will be integrated soon. :) was (Author: stefan.braune): This problem still persists with wagon-ftp:2.4 (and below). I fixed that issue by myself in class org.apache.maven.wagon.providers.ftp.FtpWagon. The issue was, that while making directories recursively, the code tests whether a directory already exists by entering it and seeing whether that worked or not. After that (and maybe after creating the directory) it will enter it again. If the directory already existed (as it is the case for ".."), it enters it a second time. That's the whole bug. The original version reads like this: // we only create the nextDir if it doesn't yet exist if (!ftp.changeWorkingDirectory(nextDir)) { ok &amp;= ftp.makeDirectory(nextDir); } if (ok) { // set the permissions for the freshly created directory setPermissions(permissions); ftp.changeWorkingDirectory(nextDir); // now create the deeper directories final String remainingDirs = fileName.substring(slashPos + 1); ok &amp;= makeFtpDirectoryRecursive(remainingDirs, permissions); } The fixed version looks like this (notice the changedDir boolean variable, which fixes the whole thing): boolean changedDir = false; // we only create the nextDir if it doesn't yet exist if (!ftp.changeWorkingDirectory(nextDir)) { ok &amp;= ftp.makeDirectory(nextDir); } else { changedDir = true; } if (ok) { // set the permissions for the freshly created directory setPermissions(permissions); if (!changedDir) { ftp.changeWorkingDirectory(nextDir); } // now create the deeper directories final String remainingDirs = fileName.substring(slashPos + 1); ok &amp;= makeFtpDirectoryRecursive(remainingDirs, permissions); } I hope, that this patch will be integrated soon. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Stefan Braune (JIRA 2013-06-17T13:14:03 http://permalink.gmane.org/gmane.comp.apache.maven.issues/38515 <pre> [ https://jira.codehaus.org/browse/WAGON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=326840#comment-326840 ] Stefan Braune commented on WAGON-363: ------------------------------------- This problem still persists with wagon-ftp:2.4 (and below). I fixed that issue by myself in class org.apache.maven.wagon.providers.ftp.FtpWagon. The issue was, that while making directories recursively, the code tests whether a directory already exists by entering it and seeing whether that worked or not. After that (and maybe after creating the directory) it will enter it again. If the directory already existed (as it is the case for ".."), it enters it a second time. That's the whole bug. The original version reads like this: // we only create the nextDir if it doesn't yet exist if (!ftp.changeWorkingDirectory(nextDir)) { ok &amp;= ftp.makeDirectory(nextDir); } if (ok) { // set the permissions for the freshly created directory setPermissions(permissions); ftp.changeWorkingDirectory(nextDir); // now create the deeper directories final String remainingDirs = fileName.substring(slashPos + 1); ok &amp;= makeFtpDirectoryRecursive(remainingDirs, permissions); } The fixed version looks like this (notice the changedDir boolean variable, which fixes the whole thing): boolean changedDir = false; // we only create the nextDir if it doesn't yet exist if (!ftp.changeWorkingDirectory(nextDir)) { ok &amp;= ftp.makeDirectory(nextDir); } else { changedDir = true; } if (ok) { // set the permissions for the freshly created directory setPermissions(permissions); if (!changedDir) { ftp.changeWorkingDirectory(nextDir); } // now create the deeper directories final String remainingDirs = fileName.substring(slashPos + 1); ok &amp;= makeFtpDirectoryRecursive(remainingDirs, permissions); } I hope, that this patch will be integrated soon. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira </pre> Stefan Braune (JIRA 2013-06-17T13:12:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.maven.issues