[jira] Commented: (MEV-536) Broken checksums and signature for maven-2.0.7.pom
[ http://jira.codehaus.org/browse/MEV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136330#action_136330 ] John Casey commented on MEV-536: It seems that the signature for the archives (tar.gz, tar.bz2, zip) are also bad. I'm not sure how to proceed on that part of the issue. > Broken checksums and signature for maven-2.0.7.pom > -- > > Key: MEV-536 > URL: http://jira.codehaus.org/browse/MEV-536 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: John Casey > > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.7/maven-2.0.7.pom > .md5 and .sha1 are broken due to being in incorrect format (generated by BSD > checksum tools?) > .asc is bad signature. -- 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] Reopened: (MEV-536) Broken checksums and signature for maven-2.0.7.pom
[ http://jira.codehaus.org/browse/MEV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey reopened MEV-536: Assignee: Jason van Zyl (was: John Casey) do we need to correct the gpg signatures for these archives? If not, is this going to be an issue with your gpg information going forward? > Broken checksums and signature for maven-2.0.7.pom > -- > > Key: MEV-536 > URL: http://jira.codehaus.org/browse/MEV-536 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: Jason van Zyl > > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.7/maven-2.0.7.pom > .md5 and .sha1 are broken due to being in incorrect format (generated by BSD > checksum tools?) > .asc is bad signature. -- 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: (MEV-572) http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry
[ http://jira.codehaus.org/browse/MEV-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136333#action_136333 ] John Casey commented on MEV-572: Carlos, can you expand on what the issue is here, and maybe where to find those rewrite rules (the link above doesn't work). I'm happy to take care of it, but not sure where to find the information I need. > http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry > -- > > Key: MEV-572 > URL: http://jira.codehaus.org/browse/MEV-572 > Project: Maven Evangelism > Issue Type: Bug >Reporter: SebbASF > > The directory of http://repo1.maven.org/maven/batik/jars/ looks like this to > me: > ... > batik-1.5-fop-0.20-5.jar 22-Jan-2004 08:37 2.0M > batik-1.5-fop-0.20-5.jar.md5 22-Jan-2004 08:37 33 > ... > However, when the md5 is downloaded, it is exactly the same as the jar > - i.e. not the 33 bytes of hash+EOL expected. > Looks like there is a bad link or perhaps a bad htaccess file which is > causing the wrong file to be downloaded. > The equivalent ibiblio entry seems OK: > http://mirrors.ibiblio.org/pub/mirrors/maven/batik/jars/ -- 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] Closed: (MEV-577) com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom cannot find saaj-impl 1.3
[ http://jira.codehaus.org/browse/MEV-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-577. -- Assignee: John Casey Resolution: Fixed I added a relocation POM that was a copy of com.sun.xml:saaj-impl:1.3 to javax.xml.soap:saaj-impl:1.3 since the jaxrpc-impl POM is useless without it. Reversing this - if we should need to do so - is a simple matter of deleting javax/xml/soap/saaj-impl from the repository. > com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom cannot find > saaj-impl 1.3 > --- > > Key: MEV-577 > URL: http://jira.codehaus.org/browse/MEV-577 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: deckrider >Assignee: John Casey > > Hello, > I am using... > http://repo1.maven.org/maven2/com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom > ...which contains... > > javax.xml.soap > saaj-impl > 1.3 > > However... > http://repo1.maven.org/maven2/javax/xml/soap/saaj-impl > ...doesn't exist. > I did a search and found that... > http://repo1.maven.org/maven2/com/sun/xml/saaj-impl/1.3/saaj-impl-1.3.pom > ...does exist, and includes relocation information. This relocation > information appears to be valid, since... > http://repo1.maven.org/maven2/com/sun/xml/messaging/saaj/saaj-impl/1.3/saaj-impl-1.3.pom > ...exists. > So to fix this, please copy... > http://repo1.maven.org/maven2/com/sun/xml/saaj-impl/1.3/saaj-impl-1.3.pom > ...to... > http://repo1.maven.org/maven2/javax/xml/soap/saaj-impl/1.3/saaj-impl-1.3.pom > Thanks. -- 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] Closed: (WAGON-53) Doesn't make use of the local repository in global settings.xml
[
http://jira.codehaus.org/browse/WAGON-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed WAGON-53.
-
Assignee: Brett Porter
Resolution: Cannot Reproduce
Fix Version/s: (was: 1.0-beta-3)
is working with 1.0-beta-3 and v1.0 of the SCM library
> Doesn't make use of the local repository in global settings.xml
> ---
>
> Key: WAGON-53
> URL: http://jira.codehaus.org/browse/WAGON-53
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-scm
>Affects Versions: 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4, 1.0-alpha-5,
> 1.0-alpha-6, 1.0-alpha-7, 1.0-beta-1
> Environment: windows xp, maven 2.0.4
>Reporter: Jean Deruelle
>Assignee: Brett Porter
>
> when trying to deploy a jar to a svn repository , wagon-scm continues to use
> the standard local repository location instead of the one located in
> M2_HOME/conf/setting.xml.
> ...
>
>
> svn-repository
> scm:svn:https://[EMAIL
> PROTECTED]/svn/maven2-repository/trunk/repository
>
>
>
>
> org.apache.maven.wagon
> wagon-scm
> 1.0-alpha-5
>
>
> Here is the log :
> [INFO] [deploy:deploy]
> Uploading:
> scm:svn:https://maven2-repository.dev.java.net/svn/maven2-repository/trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0/maven-slee-du-plugin-1.0.jar
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository
> [INFO] Command line: svn add --non-recursive ${user.home}/.m2/repository/org
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
> [INFO] Command line: svn add --non-recursive
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\1.0
> [INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
> --non-interactive checkout
> https://maven2-repository.dev.java.net/svn/maven2-repository/
> trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0 1.0
> [INFO] Working directory:
> C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
> [INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
> --non-interactive commit --file
> C:\DOCUME~1\T405732\LOCALS~1\Temp\maven-scm-465347372.commit
> ${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error deploying artifact: Unable to commit file svn:
> 'C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\ma
> ven-slee-du-plugin' is not a working copy
--
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] Closed: (WAGON-66) Error when password is wrong is not clear
[ http://jira.codehaus.org/browse/WAGON-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-66. - Assignee: Brett Porter Resolution: Fixed fixed during adjustments for WAGON-100 > Error when password is wrong is not clear > - > > Key: WAGON-66 > URL: http://jira.codehaus.org/browse/WAGON-66 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-scm >Affects Versions: 1.0-beta-1 >Reporter: Carlos Sanchez >Assignee: Brett Porter >Priority: Minor > Fix For: 1.0-beta-3 > > > I get a "Unable to create directories in the remote repository" when password > is wrong in settings.xml, message needs to be improved > [INFO] > > [INFO] Error uploading site > Embedded error: Unable to create directories in the remote repository: > http://maestro.carlos.org/repos/,yproject/trunk/www/site/0.5-SNAPSHOT > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:327) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:120) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:269) > 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:585) > 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: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:172) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:418) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Unable to create > directories in the remote repository: > http://maestro.carlos.org/repos/myproject/trunk/www/site/0.5-SNAPSHOT > at > org.apache.maven.wagon.providers.scm.ScmWagon.mkdirs(ScmWagon.java:422) > at > org.apache.maven.wagon.providers.scm.ScmWagon.putInternal(ScmWagon.java:244) > at > org.apache.maven.wagon.providers.scm.ScmWagon.putDirectory(ScmWagon.java:442) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:156) > ... 18 more -- 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] Closed: (WAGON-92) Wrong URL computation causes svn commit error
[
http://jira.codehaus.org/browse/WAGON-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed WAGON-92.
-
Assignee: Brett Porter
Resolution: Fixed
> Wrong URL computation causes svn commit error
> -
>
> Key: WAGON-92
> URL: http://jira.codehaus.org/browse/WAGON-92
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-scm
>Reporter: Kohsuke Kawaguchi
>Assignee: Brett Porter
> Fix For: 1.0-beta-3
>
>
> In ScmWagon.java line 388, the following code exists:
> {noformat}
> scmRepository = getScmRepository( getRepository().getUrl() + "/"
> + target );
> CheckOutScmResult ret = scmProvider.checkOut( scmRepository,
> new ScmFileSet( new
> File( checkoutDirectory, "" ) ),
> (ScmVersion) null,
> false );
> checkScmResult( ret );
> {noformat}
> On Windows where the directory separator in 'target' is back slave, this
> creates incorrect URL, causing the check out operation to fail like this:
> {noformat}
> Caused by: org.apache.maven.wagon.TransferFailedException: Unable to commit
> file. The svn command failed. svn: URL
> 'file:///c:/kohsuke/My%20Projects/experiments/wagon-scm/repo/test%5Cstax-ex%5C1.2-SNAPSHOT'
> doesn't exist
> at
> org.apache.maven.wagon.providers.scm.ScmWagon.checkScmResult(ScmWagon.java:514)
> at
> org.apache.maven.wagon.providers.scm.ScmWagon.checkOut(ScmWagon.java:393)
> at
> org.apache.maven.wagon.providers.scm.ScmWagon.putInternal(ScmWagon.java:287)
> at
> org.apache.maven.wagon.providers.scm.ScmWagon.put(ScmWagon.java:259)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:222)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:151)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
> ... 19 more
> {noformat}
> Unlike file path, a path separator in URL is always '/'. I confirmed that the
> following change makes this work.
> {noformat}
> scmRepository = getScmRepository( getRepository().getUrl() + "/"
> + target.replace('\\','/') );
> {noformat}
--
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-176) Add support for uploading file with server-side umask setting
[ http://jira.codehaus.org/browse/WAGON-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-176: --- Fix Version/s: (was: 1.0-beta-3) 1.x could you adapt your patch so that it's only triggered based on a configuration option? Maybe umask? In addition, I think you can reuse the executeCommand function for much of this > Add support for uploading file with server-side umask setting > - > > Key: WAGON-176 > URL: http://jira.codehaus.org/browse/WAGON-176 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ssh >Reporter: Jun Futagawa > Fix For: 1.x > > Attachments: ScpWagon-server_side_umask.patch > > > Here's a patch for wagon-ssh that uploads a file according to a set value of > umask on the server side. > In our project, the project member uploads the file to the directory that > directory mode is 2775. And, umask 002 is set to all the user accounts. > However, wagon-ssh always up-loads the file by 644 permission when there is > no filePermissions setting in the Maven's setting.xml file. -- 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: (MRELEASE-347) release:prepare, it try to create jar file and failed, since the source directory is deleted by clean ?
release:prepare, it try to create jar file and failed, since the source directory is deleted by clean ? --- Key: MRELEASE-347 URL: http://jira.codehaus.org/browse/MRELEASE-347 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-7 Environment: cvs is the source code repository, unix is env Reporter: Michael Meng release:prepare -- it first clean the target folder, then it should do the verify, but why it run resources, compile and jar ? Did something wrong on my pom.xml or what might go wrong ? why the verify trigger the resources, compile and jar ? while the target folder is empty Any help will be appreciated. Michael $ mvn release:prepare [INFO] [release:prepare] ... [INFO] Executing goals 'clean verify'... [INFO] Executing: mvn clean verify --no-plugin-updates [INFO] Scanning for projects... [INFO] [INFO] Building UBH Service Project [INFO]task-segment: [clean, verify] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. .. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Not compiling test sources [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] [WARNING] JAR will be empty - no content was marked for inclusion! -- 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] Closed: (MEV-457) Geronimo jar fails to download
[ http://jira.codehaus.org/browse/MEV-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-457. -- Assignee: John Casey Resolution: Fixed Fixed for 1.1.1, though the POM for 1.1 is still missing. I didn't put the converted POM into 1.1 because I was concerned that it would change the way 1.1 is used in projects today (since maven stubs out a missing POM for a dependency, which means the dependencies for 1.1 as discovered by maven would change if I fixed the pom). Also, fixed the metadata at the artifactId level. > Geronimo jar fails to download > -- > > Key: MEV-457 > URL: http://jira.codehaus.org/browse/MEV-457 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Henri Yandell >Assignee: John Casey > > If you look at http://www.ibiblio.org/maven/geronimo/jars/, you can see that > there is a geronimo-javamail-transport-1.1.1.jar file. If you try to click on > that/download it you get a reply of 'Not found'. > (http://www.ibiblio.org/maven/geronimo/jars/geronimo-javamail-transport-1.1.1.jar) > mod_rewrite or permissions problem? -- 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: (MPLUGIN-118) missing / in closing tag in generated pom snippet
missing / in closing tag in generated pom snippet
-
Key: MPLUGIN-118
URL: http://jira.codehaus.org/browse/MPLUGIN-118
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 2.4.1
Reporter: Herve Boutemy
example:
{code:xml}
org.apache.maven.plugins *<--- should be *
maven-shade-plugin
1.2-SNAPSHOT
...
org.apache.maven.plugins
maven-shade-plugin
1.2-SNAPSHOT
{code}
--
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] Closed: (MPLUGIN-118) missing / in closing tag in generated pom snippet
[
http://jira.codehaus.org/browse/MPLUGIN-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPLUGIN-118.
-
Assignee: Herve Boutemy
Resolution: Fixed
Fix Version/s: 2.4.2
fixed in r660706
> missing / in closing tag in generated pom snippet
> -
>
> Key: MPLUGIN-118
> URL: http://jira.codehaus.org/browse/MPLUGIN-118
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.4.2
>
>
> example:
> {code:xml}
>
>
>
> org.apache.maven.plugins *<--- should be
> *
> maven-shade-plugin
> 1.2-SNAPSHOT
>
> ...
>
>
>
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> 1.2-SNAPSHOT
>
> {code}
--
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: (MEV-536) Broken checksums and signature for maven-2.0.7.pom
[ http://jira.codehaus.org/browse/MEV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136379#action_136379 ] Brian Fox commented on MEV-536: --- John, can you resign those jars? > Broken checksums and signature for maven-2.0.7.pom > -- > > Key: MEV-536 > URL: http://jira.codehaus.org/browse/MEV-536 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: Jason van Zyl > > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.7/maven-2.0.7.pom > .md5 and .sha1 are broken due to being in incorrect format (generated by BSD > checksum tools?) > .asc is bad signature. -- 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: (MJAVADOC-97) enable internal/external dependency references as links
[
http://jira.codehaus.org/browse/MJAVADOC-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136380#action_136380
]
Cleber Zarate commented on MJAVADOC-97:
---
Matthew, this code is using the project's url as the maven site. However, there
are some cases where the project site is different from the generated maven
site.
So I changed the code to use the distributionManagement site. If the project
doesn't have one, them attempts to use the project's website.
Here's the code:
@2575
if (model != null)
{
String site;
if(model.getDistributionManagement()!=null &&
model.getDistributionManagement().getSite() !=null){
String url =
model.getDistributionManagement().getSite().getUrl();
if(url.indexOf("http://";)>=0)
site =
url.substring(url.indexOf("http://";)); //FIXME: make sure every site url will
be http.
else site = url;
}
else if(model.getUrl() != null)
site = model.getUrl();
//attempts to use the project's url.
addArgIfNotEmpty(arguments, "-link",
JavadocUtil
.quotedPathArgument(site + "/apidocs"),
true); //TODO: fix the
getUrl() method to return the URL with the version.
}
I'm using the substring since there's another protocol (dav:) being used for
uploading the website. Maybe there's a better solution for that.
Note that these patches won't work with dependencies that doesn't follow maven
conventions for the site (for instance, hibernate uses
http://www.hibernate.org/hib_docs/v3/api/ ).
> enable internal/external dependency references as links
>
>
> Key: MJAVADOC-97
> URL: http://jira.codehaus.org/browse/MJAVADOC-97
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Richard van Nieuwenhoven
>Assignee: Kenney Westerhof
>Priority: Minor
> Attachments: maven-javadoc-plugin-2.1.patch,
> MJAVADOC-97-maven-javadoc-plugin.patch
>
>
> This patch enables the java doc plugin to autmaticaly connect the dependent
> javadoc pages as links.
> There is no more need to add links in your pom's for internal and external
> maven projects.
> The plugin resolves the dependencies and adds the defined project url's
> extended with "/apidocs" to the links in the plugin.
> TODO: a warning occures when the project has no javadocs (or no maven
> generated javadoc on its homepage) ..
--
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: (MJAVADOC-97) enable internal/external dependency references as links
[ http://jira.codehaus.org/browse/MJAVADOC-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136381#action_136381 ] Matthew Beermann commented on MJAVADOC-97: -- I specifically avoided that approach, since it assumes a) that the project is using WebDAV to deploy the site, and b) that the publishing URL is the same as the public access URL. Those both seem like very large assumptions; larger, in my view, than the assumption about the field... > enable internal/external dependency references as links > > > Key: MJAVADOC-97 > URL: http://jira.codehaus.org/browse/MJAVADOC-97 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Richard van Nieuwenhoven >Assignee: Kenney Westerhof >Priority: Minor > Attachments: maven-javadoc-plugin-2.1.patch, > MJAVADOC-97-maven-javadoc-plugin.patch > > > This patch enables the java doc plugin to autmaticaly connect the dependent > javadoc pages as links. > There is no more need to add links in your pom's for internal and external > maven projects. > The plugin resolves the dependencies and adds the defined project url's > extended with "/apidocs" to the links in the plugin. > TODO: a warning occures when the project has no javadocs (or no maven > generated javadoc on its homepage) .. -- 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: (NMAVEN-129) Deploy plugin documentation doesn't match behavior: -Dversion vs. -DartifactVersion
Deploy plugin documentation doesn't match behavior: -Dversion vs. -DartifactVersion Key: NMAVEN-129 URL: http://jira.codehaus.org/browse/NMAVEN-129 Project: NMaven Issue Type: Bug Affects Versions: 0.14 (Unreleased) Environment: NMaven 0.14 branch + patches Reporter: Wendy Smoak The 'usage' page for the deploy plugin says to use -Dversion, but this results in an error message. http://incubator.apache.org/nmaven/0.14/plugins/maven-deploy-plugin/usage.html C:\temp>mvn org.apache.maven.dotnet.plugins:maven-deploy-plugin:deploy-file -Dfile=sample.dll -DgroupId=Examples -DartifactId=SampleProject -Dversion=1.0 -Dpackaging=library -Durl=file:///tmp/repo ... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'deploy:deploy-file' [0] Inside the definition for plugin 'maven-deploy-plugin' specify the following: ... VALUE -OR- on the command line, specify: '-DartifactVersion=VALUE' Apparently it should be -DartifactVersion=1.0 Is there some reason this needs to differ from the Java deploy plugin, which uses -Dversion when deploying? -- 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] Closed: (MNG-2569) Expressions not evaluated inside
[ http://jira.codehaus.org/browse/MNG-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2569. -- Resolution: Duplicate This is a duplicate of the linked issue and a contentious one at that. Anything done here should be in the context of the other issue in 2.1 ( if at all) > Expressions not evaluated inside > - > > Key: MNG-2569 > URL: http://jira.codehaus.org/browse/MNG-2569 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, POM, Reactor and workspace >Affects Versions: 2.0.4 > Environment: WinXP > Java 1.5_08 > Maven 2.04 >Reporter: Thomas Minor >Priority: Minor > Fix For: Reviewed Pending Version Assignment > > > The version tag within the parrent block does not evaluate properties. > If I put a Version String directly in there, it works. > A correctly defined property doesn't. -- 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: (NMAVEN-130) NPE when deploying to remote repo
NPE when deploying to remote repo - Key: NMAVEN-130 URL: http://jira.codehaus.org/browse/NMAVEN-130 Project: NMaven Issue Type: Bug Affects Versions: 0.14 (Unreleased) Environment: NMaven 0.14 branch + patches Reporter: Wendy Smoak Deploying to a remote repo results in a NullPointerException C:\Temp>mvn org.apache.maven.dotnet.plugins:maven-deploy-plugin:deploy-file -Dfile=sample.dll -DgroupId=Examples -DartifactId=SampleProject -DartifactVersion=1.0 -Dpackaging=library -Durl=file:///temp/repo ... [INFO] [deploy:deploy-file] Uploading: file:///temp/repo/Examples/SampleProject/1.0/SampleProject-1.0.dll 3K uploaded [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:919) at org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository(ProjectArtifactMetadata.java:86) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:437) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86) at org.apache.maven.dotnet.plugins.DeployFileMojo.execute(DeployFileMojo.java:150) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) 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) [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Tue May 27 16:05:57 MST 2008 [INFO] Final Memory: 6M/14M [INFO] The file is deployed, but without metadata: C:\Temp>tree /F repo Folder PATH listing Volume serial number is BCCB-CB88 C:\TEMP\REPO └───Examples └───SampleProject └───1.0 SampleProject-1.0.dll SampleProject-1.0.dll.md5 SampleProject-1.0.dll.sha1 -- 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] Closed: (NMAVEN-42) Conversion from a csproj File to a pom.xml File
[ http://jira.codehaus.org/browse/NMAVEN-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed NMAVEN-42. - Resolution: Duplicate NMAVEN-119 is a duplicate of this one > Conversion from a csproj File to a pom.xml File > --- > > Key: NMAVEN-42 > URL: http://jira.codehaus.org/browse/NMAVEN-42 > Project: NMaven > Issue Type: New Feature >Reporter: Shane Isbell >Priority: Minor > > The framework should support converting from a csproject file to a pom. This > has two advantages: 1) recovering from a corrupted or outdated pom (one that > is older than the csproject file) and 2) helping to transition existing > projects to NMaven. -- 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: (NMAVEN-131) Deploy plugin should generate a minimal pom if one is not supplied
Deploy plugin should generate a minimal pom if one is not supplied -- Key: NMAVEN-131 URL: http://jira.codehaus.org/browse/NMAVEN-131 Project: NMaven Issue Type: New Feature Affects Versions: 0.14 (Unreleased) Environment: NMaven 0.14 branch + patches Reporter: Wendy Smoak When deploying libraries to a remote repo, the deploy plugin should generate a pom by default. (The Java version of this plugin has a 'generatePom' parameter that defaults to true.) Workaround: create a minimal pom and use -DpomFile=/path/to/pom.xml when deploying libraries to a remote repo. -- 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-156) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/WAGON-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136391#action_136391 ] Brett Porter commented on WAGON-156: ok, I'm testing this against people.apache.org with the latest code and found: * files don't exist, no settings, no umask (default of 22) - deploys as 775, 644 * files don't exist, no settings, umask 2 - deploys as 775, 664 * files don't exist, settings set fp to 666, no umask - deploys as 775, 644 (bug) * files don't exist, settings set fp to 666, umask 2 - deploys as 775, 664 (bug) * directoryPermissions works when it doesn't exist * file permissions are not changed if they already existed * sftp sets permissions correctly, but is very slow by comparison I'll look into whether the scp1 setting actually works of it is always going to use the umask > directoryPermissions is not repected when I deploy a POM > > > Key: WAGON-156 > URL: http://jira.codehaus.org/browse/WAGON-156 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Debian Linux unstable, Sun JDK 1.5.0_06 >Reporter: Trustin Lee >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > Attachments: wagon-permission-patch.diff > > > It seems like 'directoryPermissions' doesn't work at all though > 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also > changed my umask to 002, but it didn't help at all. > If you have committership in the Apache Directory Project (Brett? :), then > you can try it by yourself: > > svn co https://svn.apache.org/repos/asf/directory/trunks/ directory > cd directory > mvn --non-recursive deploy > > This is my ~/.m2/settings.xml > > > > > > apache.snapshots > trustin > /home/trustin/.ssh/id_rsa > 0775 > 0664 > > > > -- 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: (MAVENUPLOAD-2080) jsch 0.1.38
jsch 0.1.38 --- Key: MAVENUPLOAD-2080 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2080 Project: Maven Upload Requests Issue Type: Wish Reporter: Brett Porter Assignee: Brett Porter -- 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] Closed: (MAVENUPLOAD-2080) jsch 0.1.38
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MAVENUPLOAD-2080. - Resolution: Fixed > jsch 0.1.38 > --- > > Key: MAVENUPLOAD-2080 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2080 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Brett Porter >Assignee: Brett Porter > -- 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-215) sftp is much slower than scp for equivalent requests
sftp is much slower than scp for equivalent requests Key: WAGON-215 URL: http://jira.codehaus.org/browse/WAGON-215 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Reporter: Brett Porter Fix For: 1.0 even though it doesn't fork any processes, sftp is much slower than scp for equivalent requests in my environment (45 seconds vs 2 mins 15 seconds for a snapshot upload). Consider profiling the process to see what consumes the time. -- 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-215) sftp is much slower than scp for equivalent requests
[ http://jira.codehaus.org/browse/WAGON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-215: --- Fix Version/s: 1.0 > sftp is much slower than scp for equivalent requests > > > Key: WAGON-215 > URL: http://jira.codehaus.org/browse/WAGON-215 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter > Fix For: 1.0 > > > even though it doesn't fork any processes, sftp is much slower than scp for > equivalent requests in my environment (45 seconds vs 2 mins 15 seconds for a > snapshot upload). > Consider profiling the process to see what consumes the time. -- 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-216) upgrade to jsch 0.1.38
upgrade to jsch 0.1.38 -- Key: WAGON-216 URL: http://jira.codehaus.org/browse/WAGON-216 Project: Maven Wagon Issue Type: Improvement Components: wagon-ssh Affects Versions: 1.0-beta-2 Reporter: Brett Porter Fix For: 1.0-beta-3 -- 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] Closed: (WAGON-216) upgrade to jsch 0.1.38
[ http://jira.codehaus.org/browse/WAGON-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-216. -- Assignee: Brett Porter Resolution: Fixed Fix Version/s: 1.0-beta-3 > upgrade to jsch 0.1.38 > -- > > Key: WAGON-216 > URL: http://jira.codehaus.org/browse/WAGON-216 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ssh >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > -- 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] Closed: (WAGON-156) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/WAGON-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-156. -- Resolution: Fixed added the -p flag to scp > directoryPermissions is not repected when I deploy a POM > > > Key: WAGON-156 > URL: http://jira.codehaus.org/browse/WAGON-156 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Debian Linux unstable, Sun JDK 1.5.0_06 >Reporter: Trustin Lee >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > Attachments: wagon-permission-patch.diff > > > It seems like 'directoryPermissions' doesn't work at all though > 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also > changed my umask to 002, but it didn't help at all. > If you have committership in the Apache Directory Project (Brett? :), then > you can try it by yourself: > > svn co https://svn.apache.org/repos/asf/directory/trunks/ directory > cd directory > mvn --non-recursive deploy > > This is my ~/.m2/settings.xml > > > > > > apache.snapshots > trustin > /home/trustin/.ssh/id_rsa > 0775 > 0664 > > > > -- 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] Closed: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-171. -- Assignee: Brett Porter Resolution: Fixed fixed so the permissions are not set unless you ask them to be in wagon. However, Maven still passes in default settings - I'll open a new issue to remove that in the future. I've also added a configuration option, which if left empty will block the Maven defaults. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- 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: (MNG-3600) remove default settings of 664 / 775 for permissions
remove default settings of 664 / 775 for permissions Key: MNG-3600 URL: http://jira.codehaus.org/browse/MNG-3600 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.9 Reporter: Brett Porter setting this makes it impossible to have "no setting", that is, to trust the umask on the server. This also means that if files on the server are not owned by the user, deploy fails because the mode can't be set. wagon 1.0-beta-3 has fixed a number of long standing issues with file permission setting using scp that were part of the impetus for this change, though it proved ineffectual in the end. -- 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] Moved: (MSITE-330) Wagon nukes the permission bits of uploaded files.
[ http://jira.codehaus.org/browse/MSITE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved WAGON-71 to MSITE-330: - Fix Version/s: (was: 1.0-beta-3) Component/s: (was: wagon-ssh) (was: wagon-ssh-external) site:deploy Key: MSITE-330 (was: WAGON-71) Project: Maven 2.x Site Plugin (was: Maven Wagon) > Wagon nukes the permission bits of uploaded files. > -- > > Key: MSITE-330 > URL: http://jira.codehaus.org/browse/MSITE-330 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Reporter: Henning Schmiedehausen > > Uploading a site using wagon might nuke permission bits of e.g. CGI scripts > thus making these unavailable. > For Apache webserver, a CGI script can have the permission bit set and is > then executed. This is e.g. used for the "download.cgi" script on many Apache > project sites. > The wagon uploader (at least ssh and ssh-external) unconditionally change the > permissions of all files to be 664. Which kills the execution bits. Which is > bad (TM). -- 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-330) Wagon nukes the permission bits of uploaded files.
[ http://jira.codehaus.org/browse/MSITE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136404#action_136404 ] Brett Porter commented on MSITE-330: this is a result of chmod -Rf in the site plugin - wagon is doing the right thing. It keeps permissions on existing files copied individually. > Wagon nukes the permission bits of uploaded files. > -- > > Key: MSITE-330 > URL: http://jira.codehaus.org/browse/MSITE-330 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Reporter: Henning Schmiedehausen > > Uploading a site using wagon might nuke permission bits of e.g. CGI scripts > thus making these unavailable. > For Apache webserver, a CGI script can have the permission bit set and is > then executed. This is e.g. used for the "download.cgi" script on many Apache > project sites. > The wagon uploader (at least ssh and ssh-external) unconditionally change the > permissions of all files to be 664. Which kills the execution bits. Which is > bad (TM). -- 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-330) Wagon nukes the permission bits of uploaded files.
[ http://jira.codehaus.org/browse/MSITE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136405#action_136405 ] Brett Porter commented on MSITE-330: in addition, the site plugin really shouldn't execute this - it should rely on the wagon to set them correctly. We can address issues in wagon where putDirectory doesn't set the permissions correctly. Simply removing the lines is probably the fix here. > Wagon nukes the permission bits of uploaded files. > -- > > Key: MSITE-330 > URL: http://jira.codehaus.org/browse/MSITE-330 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Reporter: Henning Schmiedehausen > > Uploading a site using wagon might nuke permission bits of e.g. CGI scripts > thus making these unavailable. > For Apache webserver, a CGI script can have the permission bit set and is > then executed. This is e.g. used for the "download.cgi" script on many Apache > project sites. > The wagon uploader (at least ssh and ssh-external) unconditionally change the > permissions of all files to be 664. Which kills the execution bits. Which is > bad (TM). -- 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] Closed: (WAGON-176) Add support for uploading file with server-side umask setting
[ http://jira.codehaus.org/browse/WAGON-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-176. -- Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 1.x) an alternate solution was put in place in WAGON-173 > Add support for uploading file with server-side umask setting > - > > Key: WAGON-176 > URL: http://jira.codehaus.org/browse/WAGON-176 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ssh >Reporter: Jun Futagawa >Assignee: Brett Porter > Attachments: ScpWagon-server_side_umask.patch > > > Here's a patch for wagon-ssh that uploads a file according to a set value of > umask on the server side. > In our project, the project member uploads the file to the directory that > directory mode is 2775. And, umask 002 is set to all the user accounts. > However, wagon-ssh always up-loads the file by 644 permission when there is > no filePermissions setting in the Maven's setting.xml file. -- 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-151) recursive copy will ignore file permissions
[ http://jira.codehaus.org/browse/WAGON-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136407#action_136407 ] Brett Porter commented on WAGON-151: it might be a good idea to remove zip usage and make all directory operations work with recursive put/get (I believe all have this capability), then add a filter or alternate wagon that will do the zip portion and be configurable to different types, permissions settings, etc. > recursive copy will ignore file permissions > --- > > Key: WAGON-151 > URL: http://jira.codehaus.org/browse/WAGON-151 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Reporter: Brett Porter > Fix For: 1.x > > > it uses zip, so you always get the umask. It has also been pointed out that > zip may not be available. > a) make the executable configurable > b) default to tar, bake in file permissions > c) use chmod -R as a last resort -- 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
