[jira] (WAGON-388) remove wagon-http-shared4 dependency on httpclient
[ https://jira.codehaus.org/browse/WAGON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed WAGON-388. --- Resolution: Fixed Fix Version/s: 2.5 Assignee: Herve Boutemy ok, sone in [5fcc6315|http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/5fcc6315] doc updated in [f0ea14a8|http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/f0ea14a8] > remove wagon-http-shared4 dependency on httpclient > -- > > Key: WAGON-388 > URL: https://jira.codehaus.org/browse/WAGON-388 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.0, 2.4 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.5 > > > AbstractHttpClientWagon uses classes from > [HttpClient|http://hc.apache.org/httpcomponents-client-ga/httpclient/index.html] > Lightweight wagon extends AbstractHttpClientWagon but uses JRE java.net > classes > AbstractHttpClientWagon should not depend on httpclient: it can depend on > [HttpCore|http://hc.apache.org/httpcomponents-core-ga/index.html], if useful > to share some utilities between wagon-http and wagon-http-lightweight, but > not HttpClient > Such separation, possible now that HttpComponents has 2 separate layers, will > ease maintenance -- 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] (MEAR-168) Use build final name as default context root
[
https://jira.codehaus.org/browse/MEAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318881#comment-318881
]
Stéphane Nicoll edited comment on MEAR-168 at 2/9/13 9:32 AM:
--
2.8.1 and 2.9 are not even released so you can't be affected by those.
was (Author: sni):
2.8.1 and 2.9 are not even released so you can be affected by those.
> Use build final name as default context root
>
>
> Key: MEAR-168
> URL: https://jira.codehaus.org/browse/MEAR-168
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: all
>Reporter: José Volmei Dal Prá Junior
>
> Sometimes we need to make some conventions when dealing with several modules.
> We need to use the "${project.build.finalName}" as the default "contextRoot"
> mapping.
> The suggestion is: make a global configuration parameter with name
> "mustUseBuildFinalNameAsDefaultWebContextRoot". If this is set to true then
> the "WebModule.getDefaultContextRoot" method must use the build final name as
> context root.
> The global configuration parameter should have false as default value.
> Thanks.
--
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] (MNG-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319025#comment-319025 ] Herve Boutemy commented on MNG-5181: cli option renamed to -llr / --legacy-local-repository MAVEN_OPTS: -Dmaven.legacyLocalRepo=true in [720bef7d|http://git-wip-us.apache.org/repos/asf/maven/commit/720bef7d] > New resolution from local repository is very confusing > -- > > Key: MNG-5181 > URL: https://jira.codehaus.org/browse/MNG-5181 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 >Reporter: Arnaud Heritier >Assignee: Olivier Lamy > Fix For: 3.1.0 > > > I just discover the change introduced in Maven 3.x to try to improve the > resolution mechanism and to avoid to use a local artifact which may not be > available in its remote repository : > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository > Even if the feature is interesting it has several problems : > # When an artifact isn't accessible from its remote repository it isn't used > by maven which replies a classical "dependency not found error". It is really > annoying for a user with some Maven 2 skills which will have a look at his > local repo, will find the artifact and won't understand why Maven doesn't use > it. At least the error reported by Maven should be clear that even if the > dependency is available locally, it isn't used because it's remote repository > isn't available. > # This behavior cannot be configured to be only a warning for example. It is > really annoying because it doesn't take care of some context and constraints > we may have in a development team. Let's imagine that the remote artifact is > really removed. Cool Maven broke the build to warn us. But it brakes the > build of all the team whereas perhaps only one of them may try to solve the > issue (and it can be a long resolution). Thus having the ability to configure > if this control is blocker or warning may allow the team to configure it as > blocker on the CI server and as warning on the development environment. > # This behavior may introduce some bad practices for example when we are > using a staging feature on a repository manager. In our case my teams have a > dedicated profile to activate a staging repository when we are validating a > release. I recommend to not have this profile always activated but to do it > only on-demand to avoid them to DL staging stuffs they don't need. With this > new feature they need for all builds they run to activate this staging > profile while binaries are stored in it. When you have to do it 20 times per > day minimum let's imagine what the developer does : It adds it as an > alwaysActive profile and then forget to remove it when the release is ended. > For all these reason I would like we improve this feature to make it more > usable and before all bet understandable for ours users. -- 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] (MDEP-295) Add ability to strip classifier
[ https://jira.codehaus.org/browse/MDEP-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-295: --- Assignee: (was: Paul Gier) > Add ability to strip classifier > --- > > Key: MDEP-295 > URL: https://jira.codehaus.org/browse/MDEP-295 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies >Reporter: Jason Smith > Attachments: > 0002-stripClassifier-option-added-to-the-copy-dependency-.patch, > episode3.patch, good.patch > > > In addition to the ability to specify that the version be stripped from the > artifact it would be helpful to be able to specify that the classifier be > stripped also. -- 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] (WAGON-384) Maven fails to download artifacts larger than 2 GB
[ https://jira.codehaus.org/browse/WAGON-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bernardet updated WAGON-384: Attachment: AbstractWagon.java Fix proposal by updating the API. > Maven fails to download artifacts larger than 2 GB > -- > > Key: WAGON-384 > URL: https://jira.codehaus.org/browse/WAGON-384 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 2.2 > Environment: This issue is not dependent on the operating system and > hardware. >Reporter: Robert Baker > Attachments: AbstractWagon.java, AbstractWagon.java > > > If a Maven build includes a dependency for an artifact that is larger than 2 > GB in size, the download of the artifact during the build terminates at 2 GB > and the following error is reported by Maven: > [WARNING] Checksum validation failed, expected > 5b0fafa21f2b3e9c4e3b7ef3c5306f82bcb9fc85 but is > e9ef494d39de097b9a02531993688ceebdce39e1 > Maven repeats the download a second time with the same error result, then > build fails. > The failure is caused when the transfer method in AbstractWagon.java receives > maxSize parameter, which is an integer, set to Integer.MAX_VALUE, rather than > the actual size of the artifact. This value is then decremented to zero, > which causes the download to terminate prematurely. The attached file > (AbstractWagon.java) contains changes in the transfer method that use the > value Integer.MAX_VALUE as a trigger that causes the routine to ignore the > maxSize parameter's value and download the artifact until an EOF is detected, > regardless of its size. -- 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] (WAGON-384) Maven fails to download artifacts larger than 2 GB
[ https://jira.codehaus.org/browse/WAGON-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319029#comment-319029 ] William Bernardet commented on WAGON-384: - I am currently facing this issue already during the deployment of artifact if their size is over 2GB they get truncated at 2GB as well. But I would propose a different solution to fix the issue, by deprecating all method offering a maxSize int as parameter and offer a fixed API which offer similar API as long, because rest of the API (like Resource) is using long to store the size, so it make sense to use the same type in here as well. > Maven fails to download artifacts larger than 2 GB > -- > > Key: WAGON-384 > URL: https://jira.codehaus.org/browse/WAGON-384 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 2.2 > Environment: This issue is not dependent on the operating system and > hardware. >Reporter: Robert Baker > Attachments: AbstractWagon.java, AbstractWagon.java > > > If a Maven build includes a dependency for an artifact that is larger than 2 > GB in size, the download of the artifact during the build terminates at 2 GB > and the following error is reported by Maven: > [WARNING] Checksum validation failed, expected > 5b0fafa21f2b3e9c4e3b7ef3c5306f82bcb9fc85 but is > e9ef494d39de097b9a02531993688ceebdce39e1 > Maven repeats the download a second time with the same error result, then > build fails. > The failure is caused when the transfer method in AbstractWagon.java receives > maxSize parameter, which is an integer, set to Integer.MAX_VALUE, rather than > the actual size of the artifact. This value is then decremented to zero, > which causes the download to terminate prematurely. The attached file > (AbstractWagon.java) contains changes in the transfer method that use the > value Integer.MAX_VALUE as a trigger that causes the routine to ignore the > maxSize parameter's value and download the artifact until an EOF is detected, > regardless of its size. -- 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] (WAGON-389) Incorrect versions on gh-pages
Archimedes Trajano created WAGON-389: Summary: Incorrect versions on gh-pages Key: WAGON-389 URL: https://jira.codehaus.org/browse/WAGON-389 Project: Maven Wagon Issue Type: Bug Environment: http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html Reporter: Archimedes Trajano Please correct the versions. This is what I used. org.apache.maven.wagon wagon-scm 2.3 org.apache.maven.scm maven-scm-manager-plexus 1.8.1 org.apache.maven.scm maven-scm-api 1.8.1 org.apache.maven.scm maven-scm-provider-gitexe 1.8.1 -- 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] (WAGON-390) gh-pages example fails due to extra /
Archimedes Trajano created WAGON-390: Summary: gh-pages example fails due to extra / Key: WAGON-390 URL: https://jira.codehaus.org/browse/WAGON-390 Project: Maven Wagon Issue Type: Bug Reporter: Archimedes Trajano Priority: Critical It appears that the "./" is appended to the URL but that is not correct and the result is [INFO]>>> to scm:git:ssh://github.com/trajano/trajano.git/./ Uploading: ./ to scm:git:ssh://github.com/trajano/trajano.git/ I don't think it should try to use relative paths for this scheme. This is the result when doing it on the command line. trajano@RISETTE /tmp $ git clone ssh://g...@github.com/trajano/trajano.git/ Cloning into 'trajano'... ERROR: Repository not found. fatal: The remote end hung up unexpectedly trajano@RISETTE /tmp $ git clone ssh://g...@github.com/trajano/trajano.git Cloning into 'trajano'... remote: Counting objects: 157, done. -- 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] (MSHARED-275) Non file URLs with other schemes are getting relative URLs when it may not be supported
Archimedes Trajano created MSHARED-275: -- Summary: Non file URLs with other schemes are getting relative URLs when it may not be supported Key: MSHARED-275 URL: https://jira.codehaus.org/browse/MSHARED-275 Project: Maven Shared Components Issue Type: Bug Reporter: Archimedes Trajano The logic found in http://maven.apache.org/shared/maven-doxia-tools/xref/org/apache/maven/doxia/tools/DefaultSiteTool.html#274 May need to change to not call getRelativeFilePath because it is likely causing the issue: [DEBUG] Mapped url: scm:git:https://github.com/trajano/coding-standards.git to relative path: ..\coding-standards.git It should just leave the mapping as scm:git:https://github.com/trajano/coding-standards.git -- 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] (WAGON-354) Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
[
https://jira.codehaus.org/browse/WAGON-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319030#comment-319030
]
Archimedes Trajano commented on WAGON-354:
--
Is there a workaround for Maven 3?
> Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
> --
>
> Key: WAGON-354
> URL: https://jira.codehaus.org/browse/WAGON-354
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0, 2.0
> Environment: Maven 3.0.3, Site-Plugin 3.0, Wagon 2.0
>Reporter: Juergen Kellerer
>Priority: Critical
> Fix For: backlog
>
>
> I always get StringIndexOutOfBoundsException on the attempt to deploy a site
> with SFTP using Maven 3 + Site Plugin 3.
> Calling *"mvn site-deploy"* causes:
> {noformat}
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:464)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deploy(AbstractDeployMojo.java:296)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deployTo(AbstractDeployMojo.java:257)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:165)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Error occurred
> while deploying 'c:\Projects\OS\doxia-include\target\site' to remo
> te repository:
> sftp://web.sourceforge.net/home/groups/d/do/doxia-include/htdocs/:
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:286)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:447)
> ... 24 more
> Caused by: 4:
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1713)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.mkdir(SftpWagon.java:204)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.ftpRecursivePut(SftpWagon.java:300)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:277)
> ... 25 more
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 0
> at java.lang.String.charAt(String.java:686)
> at
> com.jcraft.jsch.ChannelSftp.remoteAbsolutePath(ChannelSftp.java:2367)
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1691)
> ... 28 more
> {noformat}
> *The configuration is*:
> {code:xml}
>
> doxia-include
>
>
>
> ${application.id}.shell.sourceforge.net
> ${application.id}.shell.sourceforge.net
>
> sftp://web.sourceforge.net/home/groups/d/do/${application.id}/htdocs
>
> {code}
> (Btw. I tried variuous urls, "../htdocs", "../htdocs/" and "../htdocs/." but
> the site plugin always normalizes them to "../htdocs/", which is actually the
> right thing to do.)
> *My assumption why it happens:*
> I looked at the sources of wagon (particularly to the methods mentioned in
> the stack trace), and I think the issue seems to be that:
> - Site Plugin 3 always normalizes the remote directory to end with a trailing
> slash.
> - WagonSftp.putDirectory:277 calls ScpHelper.getResourceFilename(
> destinationDirectory ) on this directory which returns an empty string.
> - WagonSfto.ftpRecursivePut:300 calls mkdir with an empty string which causes
> the exception.
> Actually it looks as if older site plugins added a trailing "/." to the path
> instead of just "/" as otherwise it would have been broken before (I did not
> verify this). Nevertheless I think the bug is in the Wagon implementation as
> it should not fail if the destination is given like this.
--
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] (WAGON-384) Maven fails to download artifacts larger than 2 GB
[ https://jira.codehaus.org/browse/WAGON-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319031#comment-319031 ] Olivier Lamy commented on WAGON-384: can you provide a patch ? I mean something which show the diff because it's only a file without any indication on what has changes. Note you can provide pull request too via this code mirror: https://github.com/apache/maven-wagon > Maven fails to download artifacts larger than 2 GB > -- > > Key: WAGON-384 > URL: https://jira.codehaus.org/browse/WAGON-384 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 2.2 > Environment: This issue is not dependent on the operating system and > hardware. >Reporter: Robert Baker > Attachments: AbstractWagon.java, AbstractWagon.java > > > If a Maven build includes a dependency for an artifact that is larger than 2 > GB in size, the download of the artifact during the build terminates at 2 GB > and the following error is reported by Maven: > [WARNING] Checksum validation failed, expected > 5b0fafa21f2b3e9c4e3b7ef3c5306f82bcb9fc85 but is > e9ef494d39de097b9a02531993688ceebdce39e1 > Maven repeats the download a second time with the same error result, then > build fails. > The failure is caused when the transfer method in AbstractWagon.java receives > maxSize parameter, which is an integer, set to Integer.MAX_VALUE, rather than > the actual size of the artifact. This value is then decremented to zero, > which causes the download to terminate prematurely. The attached file > (AbstractWagon.java) contains changes in the transfer method that use the > value Integer.MAX_VALUE as a trigger that causes the routine to ignore the > maxSize parameter's value and download the artifact until an EOF is detected, > regardless of its size. -- 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] (DOXIATOOLS-32) DefaultSiteTool.getRelativePath returns nonsense if both paths are absolute with different scheme
[ https://jira.codehaus.org/browse/DOXIATOOLS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319032#comment-319032 ] Archimedes Trajano commented on DOXIATOOLS-32: -- It should provide an option to disable relative path calculation or something. > DefaultSiteTool.getRelativePath returns nonsense if both paths are absolute > with different scheme > - > > Key: DOXIATOOLS-32 > URL: https://jira.codehaus.org/browse/DOXIATOOLS-32 > Project: Maven Doxia Tools > Issue Type: Bug > Components: Doxia Integration Tools >Affects Versions: doxia-integration-tools-1.4 >Reporter: Lukas Theussl > > See MSITE-600: for the two method parameters from = > "scp://localhost:/tmp/blop" and to = "file:///tmp/bloop" the result is a > relative path that is plain nonsense. It should return just the 'to' > argument, since both paths are absolute. -- 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] (MSHARED-275) Non file URLs with other schemes are getting relative URLs when it may not be supported
[ https://jira.codehaus.org/browse/MSHARED-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Archimedes Trajano closed MSHARED-275. -- Resolution: Duplicate > Non file URLs with other schemes are getting relative URLs when it may not be > supported > --- > > Key: MSHARED-275 > URL: https://jira.codehaus.org/browse/MSHARED-275 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Archimedes Trajano > > The logic found in > http://maven.apache.org/shared/maven-doxia-tools/xref/org/apache/maven/doxia/tools/DefaultSiteTool.html#274 > May need to change to not call getRelativeFilePath because it is likely > causing the issue: > [DEBUG] Mapped url: scm:git:https://github.com/trajano/coding-standards.git > to relative path: ..\coding-standards.git > It should just leave the mapping as > scm:git:https://github.com/trajano/coding-standards.git -- 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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages
[ https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319099#comment-319099 ] Archimedes Trajano commented on WAGON-374: -- I agree with you Rob, I don't think this is a "Won't fix" situation. Anyway I found a work around for this by using the https:// URL rather than the SSH URL. However, you'd still have trouble if you're using inheritance because the "relativizing" will kick in on the scm: scheme when it should not. > Deploying your Maven site to GitHub's gh-pages > -- > > Key: WAGON-374 > URL: https://jira.codehaus.org/browse/WAGON-374 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-scm >Affects Versions: 2.2 >Reporter: Samuel Santos >Assignee: Olivier Lamy > > The example at > http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html for > deploying a Maven site to GitHub's pages does not work. -- 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] (WAGON-374) Deploying your Maven site to GitHub's gh-pages
[ https://jira.codehaus.org/browse/WAGON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319100#comment-319100 ] Archimedes Trajano commented on WAGON-374: -- Though trying to traverse through the code to figure out a proper way of fixing this, is a bit tedious, I think a few things can be alleviated by using the java.nio.Path to handle the relativization of the paths. Unfortunately that would make maven require JDK7. > Deploying your Maven site to GitHub's gh-pages > -- > > Key: WAGON-374 > URL: https://jira.codehaus.org/browse/WAGON-374 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-scm >Affects Versions: 2.2 >Reporter: Samuel Santos >Assignee: Olivier Lamy > > The example at > http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html for > deploying a Maven site to GitHub's pages does not work. -- 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
