[jira] Created: (MNGSITE-23) Make the description of the dependency scope table more clear
Make the description of the dependency scope table more clear - Key: MNGSITE-23 URL: http://jira.codehaus.org/browse/MNGSITE-23 Project: Maven Project Web Site Issue Type: Improvement Reporter: Tim Kettler The description of the table it is not perfectly clear in explaining what exactly the table shows. The attached patch tries to improve that. -- 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: (MNGSITE-23) Make the description of the dependency scope table more clear
[ http://jira.codehaus.org/browse/MNGSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kettler updated MNGSITE-23: --- Attachment: MNGSITE-23.patch Make the description of the dependency scope table more clear - Key: MNGSITE-23 URL: http://jira.codehaus.org/browse/MNGSITE-23 Project: Maven Project Web Site Issue Type: Improvement Reporter: Tim Kettler Attachments: MNGSITE-23.patch The description of the table it is not perfectly clear in explaining what exactly the table shows. The attached patch tries to improve that. -- 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: (MNG-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-2254: --- Attachment: (was: MNG-2254_components.diff) the encoding parameter in xml declaration of POM is ignored Key: MNG-2254 URL: http://jira.codehaus.org/browse/MNG-2254 Project: Maven 2 Issue Type: Bug Components: POM::Encoding Reporter: Naoki Nose Assignee: Jason van Zyl Fix For: 2.0.8 Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, modello-plugin-xpp3.diff DefaultMavenProjectBuilder reads POM in system default character encoding, and the encoding parameter in xml declartion is ignored. to fix this problem, We should - fix modello-plugin-xpp3 to use the xml parser which is able to handle the encoding parameter properly - regenerate maven-model using fixed modello-plugin-xpp3 - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- 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: (MNG-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-2254: --- Attachment: MNG-2254_components.diff the encoding parameter in xml declaration of POM is ignored Key: MNG-2254 URL: http://jira.codehaus.org/browse/MNG-2254 Project: Maven 2 Issue Type: Bug Components: POM::Encoding Reporter: Naoki Nose Assignee: Jason van Zyl Fix For: 2.0.8 Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, modello-plugin-xpp3.diff DefaultMavenProjectBuilder reads POM in system default character encoding, and the encoding parameter in xml declartion is ignored. to fix this problem, We should - fix modello-plugin-xpp3 to use the xml parser which is able to handle the encoding parameter properly - regenerate maven-model using fixed modello-plugin-xpp3 - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- 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: (MNGSITE-23) Make the description of the dependency scope table more clear
[ http://jira.codehaus.org/browse/MNGSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNGSITE-23. Resolution: Fixed applied and deployed. Thanks for the patch. Make the description of the dependency scope table more clear - Key: MNGSITE-23 URL: http://jira.codehaus.org/browse/MNGSITE-23 Project: Maven Project Web Site Issue Type: Improvement Reporter: Tim Kettler Assignee: Brian Fox Attachments: MNGSITE-23.patch The description of the table it is not perfectly clear in explaining what exactly the table shows. The attached patch tries to improve that. -- 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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[
http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105686
]
Geoffrey De Smet commented on MIDEA-102:
same here: win xp + idea 6 + maven 2.0.7 + maven-idea-plugin 2.1 (and 2.0 too I
believe) = wrong iml paths in the ipr of a multimodule project.
CLONE -still broken - Module filepath is generated incorrectly
--
Key: MIDEA-102
URL: http://jira.codehaus.org/browse/MIDEA-102
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: $ mvn -v
Maven version: 2.0.7
Java version: 1.5.0_11
OS name: windows xp version: 5.1 arch: x86
cygwin
Reporter: Joern Huxhorn
Assignee: Dennis Lundberg
Fix For: 2.2
Attachments: maven-idea-plugin-MIDEA-102.patch
I have a multi-module mvn project.
When I do an mvn idea:clean idea:idea, the following ProjectModuleManager
snippet in the top level .ipr is generated:
component name=ProjectModuleManager
modules
!-- module filepath=$$PROJECT_DIR$$/${pom.artifactId}.iml/ --
module filepath=$PROJECT_DIR$/gateway.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml/
/modules
/component
The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
But this path is being appended in a hard-coded fashion after the
$PROJECT_DIR entry.
The symptom in Intellij is the following error message:
Cannot load module: File
C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not
exist
Would you like to remove the module from the project?
The workaround is to delete the extra appended file path from each module
entry in the above mentioned snippet.
--
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: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames
[ http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105694 ] Jerome Lacoste commented on MJAR-49: I believe that Brett's last comment is no longer valid starting from maven 2.0.6. We could bump the plexus utils version to at least 1.4.2 to make sure this is fixed. (there was a regression between I think 1.2 and 1.4.1). Jarsigner fails on windows due to spaces in pathnames - Key: MJAR-49 URL: http://jira.codehaus.org/browse/MJAR-49 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Windows XP Reporter: Jon Tayler Attachments: pathproblem.txt This is a problem uncovered while running the latest (1.0-20060307.100605-1) version of the webstart plugin, which uses the jar plugin to sign jars. During the signing stage maven fails with [debug] jarsigner executable=[C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe] [debug] Signing JAR in-place (overwritting original JAR). [warn] 'C:\Program' is not recognized as an internal or external command, [warn] operable program or batch file. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Result of C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe -verbose -keystore C:\Documents and Settings\jdt\.keystore -storepass ** -keypass ** E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar roe execution is: '1'. [INFO] (full trace is attached). It looks as though the plexus utils classes are tokenizing the path to the jarsigner executable wrongly due to it containing spaces. -- 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: (MJAR-51) handle signing jars which are not project artifacts and not in place signing
[
http://jira.codehaus.org/browse/MJAR-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MJAR-51:
Component/s: sign
handle signing jars which are not project artifacts and not in place signing
--
Key: MJAR-51
URL: http://jira.codehaus.org/browse/MJAR-51
Project: Maven 2.x Jar Plugin
Issue Type: Improvement
Components: sign
Affects Versions: 2.1
Reporter: Scott Cytacki
It seems the SignJarMojo is intended to be used both as a way to sign a jar
artifact, and as a utitlity to sign jars for other plugins in maven.
The jnlp plugin uses it in the latter mode. However currently it can only
sign jars inplace when the jar being signed isn't a artifact of a project.
More specifically if the signedJar field is not null, and the project of the
SingJarMojo is null, then SignJarMojo fails. Changing:
else
{
project.getArtifact().setFile( signedjar );
}
to
else if ( project != null)
{
project.getArtifact().setFile( signedjar );
}
Would fix this.
--
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: (MJAR-67) jar:sign - Jars containing invalid remains of older signatures won't get signed
[ http://jira.codehaus.org/browse/MJAR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MJAR-67: Component/s: sign jar:sign - Jars containing invalid remains of older signatures won't get signed --- Key: MJAR-67 URL: http://jira.codehaus.org/browse/MJAR-67 Project: Maven 2.x Jar Plugin Issue Type: Bug Components: sign Affects Versions: 2.1 Environment: Maven 2.0.4 on Windows XP JDK 1.5.0_08 Reporter: Gottfried Ganßauge Attachments: error.log, jar-plugin.patch, pom.xml I'm trying to ease the burden of applet deployment by integrating every dependency of that applet into the applet's .jar archive. For this purpose I'm using the unpack goal of the dependency plugin (see attached POM). For a particular case I had to integrate an already signed applet. There is no way I can get the integrated jar signed using jar:sign - I always get an error from jarsigner (see attached error.log). The problem seems to be that jarsigner is called with -verify - although I'm explicitely turning it of in plugin configuration. When calling jarsigned from the command line without -verify it runs to completion. When running it with -verify from the command line the same error occurs as in the maven build. -- 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: (MJAR-37) HttpJarSignClient - New goal httpsign which will sign jar files by submitting them to a signing service via HTTP Post
[ http://jira.codehaus.org/browse/MJAR-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MJAR-37: Component/s: sign HttpJarSignClient - New goal httpsign which will sign jar files by submitting them to a signing service via HTTP Post --- Key: MJAR-37 URL: http://jira.codehaus.org/browse/MJAR-37 Project: Maven 2.x Jar Plugin Issue Type: Improvement Components: sign Reporter: David Boden Attachments: jar-plugin-newfiles.zip, jarplugin.diff The patch and new files attached to this issue are newer and make the contributions in MJAR-35 obsolete. There is a test pom.xml that you can do a mvn install on to see the new goal working. -- 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: (MJAR-67) jar:sign - Jars containing invalid remains of older signatures won't get signed
[ http://jira.codehaus.org/browse/MJAR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105697 ] Jerome Lacoste commented on MJAR-67: The problem seems to be that jarsigner is called with -verify - although I'm explicitely turning it of in plugin configuration. I have a feeling that the attached patch is not enough right way to fix the issue, The exception should be thrown by default and a user flag should be there to allow bypassing the failed check. Also the log message should be warn instead of info. Patch coming. Finally you could also try to remove signatures (try the webstart:unsign mojo) Another solution was for JarSignVerifyMojo to not throw an exception when errorWhenNotSigned is true, which I didn't like much, jar:sign - Jars containing invalid remains of older signatures won't get signed --- Key: MJAR-67 URL: http://jira.codehaus.org/browse/MJAR-67 Project: Maven 2.x Jar Plugin Issue Type: Bug Components: sign Affects Versions: 2.1 Environment: Maven 2.0.4 on Windows XP JDK 1.5.0_08 Reporter: Gottfried Ganßauge Attachments: error.log, jar-plugin.patch, pom.xml I'm trying to ease the burden of applet deployment by integrating every dependency of that applet into the applet's .jar archive. For this purpose I'm using the unpack goal of the dependency plugin (see attached POM). For a particular case I had to integrate an already signed applet. There is no way I can get the integrated jar signed using jar:sign - I always get an error from jarsigner (see attached error.log). The problem seems to be that jarsigner is called with -verify - although I'm explicitely turning it of in plugin configuration. When calling jarsigned from the command line without -verify it runs to completion. When running it with -verify from the command line the same error occurs as in the maven build. -- 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: (MJAR-67) jar:sign - Jars containing invalid remains of older signatures won't get signed
[ http://jira.codehaus.org/browse/MJAR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerome Lacoste updated MJAR-67: --- Attachment: MJAR-67.diff Force the user to add a flag to bypass this issue. Failures cause by signing an already signed jar should not go unnoticed. So the exception is thrown by default and a user flag is added to allow bypassing the failed check. Finally the log message is a warning instead of info. jar:sign - Jars containing invalid remains of older signatures won't get signed --- Key: MJAR-67 URL: http://jira.codehaus.org/browse/MJAR-67 Project: Maven 2.x Jar Plugin Issue Type: Bug Components: sign Affects Versions: 2.1 Environment: Maven 2.0.4 on Windows XP JDK 1.5.0_08 Reporter: Gottfried Ganßauge Attachments: error.log, jar-plugin.patch, MJAR-67.diff, pom.xml I'm trying to ease the burden of applet deployment by integrating every dependency of that applet into the applet's .jar archive. For this purpose I'm using the unpack goal of the dependency plugin (see attached POM). For a particular case I had to integrate an already signed applet. There is no way I can get the integrated jar signed using jar:sign - I always get an error from jarsigner (see attached error.log). The problem seems to be that jarsigner is called with -verify - although I'm explicitely turning it of in plugin configuration. When calling jarsigned from the command line without -verify it runs to completion. When running it with -verify from the command line the same error occurs as in the maven build. -- 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: (MRM-474) Create tests for non-snapshot metadata merging
[ http://jira.codehaus.org/browse/MRM-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-474. -- Resolution: Fixed Code committed in r569760. Create tests for non-snapshot metadata merging -- Key: MRM-474 URL: http://jira.codehaus.org/browse/MRM-474 Project: Archiva Issue Type: Sub-task Components: system Affects Versions: 1.0-beta-1 Reporter: Joakim Erdfelt Assignee: Joakim Erdfelt Fix For: 1.0-beta-2 -- 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: (MRM-475) Create tests for snapshot metadata merging
[ http://jira.codehaus.org/browse/MRM-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-475. -- Resolution: Fixed Code committed in r569760. Create tests for snapshot metadata merging -- Key: MRM-475 URL: http://jira.codehaus.org/browse/MRM-475 Project: Archiva Issue Type: Sub-task Components: system Affects Versions: 1.0-beta-1 Reporter: Joakim Erdfelt Assignee: Joakim Erdfelt Fix For: 1.0-beta-2 -- 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: (MRM-474) Create tests for non-snapshot metadata merging
[ http://jira.codehaus.org/browse/MRM-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-474: --- Affects Version/s: 1.0-beta-1 Component/s: system Create tests for non-snapshot metadata merging -- Key: MRM-474 URL: http://jira.codehaus.org/browse/MRM-474 Project: Archiva Issue Type: Sub-task Components: system Affects Versions: 1.0-beta-1 Reporter: Joakim Erdfelt Assignee: Joakim Erdfelt Fix For: 1.0-beta-2 -- 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: (MRM-463) Metadata merging doesn't work.
[ http://jira.codehaus.org/browse/MRM-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105707 ] Joakim Erdfelt commented on MRM-463: Baseline components for metadata merging i feel are stable and have adequate unit tests. See revision 569760. The Proxy changes and new Consumers I'm still working on. They will be committed within the next 24 to 48 hours. Metadata merging doesn't work. -- Key: MRM-463 URL: http://jira.codehaus.org/browse/MRM-463 Project: Archiva Issue Type: Bug Components: remote proxy Affects Versions: 1.0-beta-1 Reporter: Joakim Erdfelt Assignee: Joakim Erdfelt Priority: Blocker Fix For: 1.0-beta-2 When dealing with metadata.xml files and proxying the merging of metadata is not performed correctly. Often ending up with a metadata.xml file with no versions specified. Tasks 1) Re-enabled metadata tests in the archiva-proxy module. 2) Fix the proxy code (and possibly the tests) to ensure metadata.xml files are merged correctly. 3) Create tests for 1 managed to multiple remote repos all with metadata.xml for the same groupId:artifactId 4) Create tests for versionless and versioned metadata.xml files. Note: Consider using the VersionComparator to obtain a unique list of sorted (by version) -- 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
