[jira] Updated: (MNG-1753) support improved property based profile activation
[ http://jira.codehaus.org/browse/MNG-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-1753: --- Component/s: Profiles > support improved property based profile activation > -- > > Key: MNG-1753 > URL: http://jira.codehaus.org/browse/MNG-1753 > Project: Maven 2 > Issue Type: New Feature > Components: POM, Profiles >Reporter: John Allen > Fix For: 2.x > > > support better profile activation via > a) multiple property elements in the activation element. > eg:- > > > os.name > > > > os.name > > > > b) regex based property parsing for both name and value elements (dont know > how you'll want to handle the tagging to indicate that something is a regex > property rather than a plain one but for now im using regexName and > regexValue) > eg:- > > > os.name > Windows 2000|Windows XP > > > same for name. -- 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-2276) profile activation by property doesn't work with properties defined in settings.
[ http://jira.codehaus.org/browse/MNG-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-2276: --- Component/s: Profiles > profile activation by property doesn't work with properties defined in > settings. > > > Key: MNG-2276 > URL: http://jira.codehaus.org/browse/MNG-2276 > Project: Maven 2 > Issue Type: Bug > Components: POM, Profiles >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: 2.1 > > > Activating a profile like below doesn't get activated unless the property is > set on the CLI. I need to have the property defined in the settings.xml so > it's always set. > > > prod > > > deploy-ct > > > Further, I noticed that if I set it so that the activation is like: > > > deploy-cttrue > > > The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It > is not active if I use "-Ddeploy-ct=false" but the settings descriptor says > that the existence of the property is only used if value is not set. -- 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: (MANTTASKS-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error
[ http://jira.codehaus.org/browse/MANTTASKS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139834#action_139834 ] Charles Canning commented on MANTTASKS-87: -- As an easy work-around, if you load the parent pom with the module/child pom using the task, you will get the warning, but the build will use the parent pom. Might want to be able to specify it in the task instead of using the task twice. > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error > - > > Key: MANTTASKS-87 > URL: http://jira.codehaus.org/browse/MANTTASKS-87 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.9 > Environment: WindowsXP > Ant version 1.7.0 >Reporter: Jeff Campbell >Assignee: Herve Boutemy >Priority: Blocker > Attachments: CASE.tar.gz > > > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error. > This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to > maven-ant-tasks-2.0.7.jar and still an issue with the latest > maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)). > Just to see if I had done something wrong with the pom.xml file I tried to > run a Maven goal against the pom.xml file. I found that if I run "mvn clean" > from this same directory (where the build.xml and pom.xml file is located), > using Maven-2.0.7, I get a build successfull (it was able to find the parent > pom.xml file... so this seems to be isolated to JUST the maven-ant-task not > being able to find the parent pom.xml) > Sample of the pom.xml file > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > intuit.sbconnect > sbclogin > 1.0.3 > SBCLogin > > > mygroup > CommonPOM > 1.0.2 > > > > > myothergroup > myartifact > 1.0 > > > > Line in Ant build.xml file that causes the error: > > Error that occurs when this line is executed in ant: > Error downloading parent pom: Missing: > -- > 1) mygroup:CommonPOM:pom:1.0.2 > Path to dependency: > 1) unspecified:unspecified:jar:0.0 > 2) mygroup:CommonPOM:pom:1.0.2 > -- > 1 required artifact is missing. > for artifact: > unspecified:unspecified:jar:0.0 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- 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: (MNG-2276) profile activation by property doesn't work with properties defined in settings.
[ http://jira.codehaus.org/browse/MNG-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139833#action_139833 ] Basil James Whitehouse III commented on MNG-2276: - Can someone with privileges please add 'Profiles' to the affected components to make it easier for others to find this issue. > profile activation by property doesn't work with properties defined in > settings. > > > Key: MNG-2276 > URL: http://jira.codehaus.org/browse/MNG-2276 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: 2.1 > > > Activating a profile like below doesn't get activated unless the property is > set on the CLI. I need to have the property defined in the settings.xml so > it's always set. > > > prod > > > deploy-ct > > > Further, I noticed that if I set it so that the activation is like: > > > deploy-cttrue > > > The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It > is not active if I use "-Ddeploy-ct=false" but the settings descriptor says > that the existence of the property is only used if value is not set. -- 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: (MASSEMBLY-333) plugin not correctly interpolating POM variables like ${settings.localRepository}
plugin not correctly interpolating POM variables like
${settings.localRepository}
-
Key: MASSEMBLY-333
URL: http://jira.codehaus.org/browse/MASSEMBLY-333
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: maven 2.0.9
Reporter: Seva Popov
It looks like the issue was fixed only partely:
http://jira.codehaus.org/browse/MASSEMBLY-189
But some variables like ${settings.localRepository} are still not interpolated
in assembly descriptor. Example:
C:\src\tvworks\trunk\tva\mpeg\stream-gen\etv-stream-generator>mvn
assembly:attached
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'assembly'.
[INFO]
[INFO] Building etv-stream-generator
[INFO]task-segment: [assembly:attached] (aggregator-style)
[INFO]
[INFO] [assembly:attached]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to create assembly: Error adding file to archive:
C:\src\tvworks\trunk\tva\mpeg\stream-gen\etv-stream-generator\${settings.localRepository}\com\tvworks\tva\mpeg\common\utils\3.1.0d\nar\lib\x86-Windows-msvc\shared\utils-3.1.0d.dll
isn't a file.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Fri Jun 27 09:55:57 PDT 2008
[INFO] Final Memory: 10M/19M
[INFO]
--
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: (MANTTASKS-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error
[ http://jira.codehaus.org/browse/MANTTASKS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139831#action_139831 ] Charles Canning commented on MANTTASKS-87: -- I am having the same problem. I believe the difference between maven and the ant tasks is that maven starts with the parent pom first and then traverses through the child branches. ASSUMPTION [ The ant tasks have no idea where the parent pom resides and therefore is forced to use the repo. If the parent pom hasn't been installed, it fails. What I think we need is a way to specify or load a parent pom before processing. ] I am trying to solve this now by pre-installing the parent pom or pre-loading. Will let you know if I find a decent work-around. > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error > - > > Key: MANTTASKS-87 > URL: http://jira.codehaus.org/browse/MANTTASKS-87 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.9 > Environment: WindowsXP > Ant version 1.7.0 >Reporter: Jeff Campbell >Assignee: Herve Boutemy >Priority: Blocker > Attachments: CASE.tar.gz > > > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error. > This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to > maven-ant-tasks-2.0.7.jar and still an issue with the latest > maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)). > Just to see if I had done something wrong with the pom.xml file I tried to > run a Maven goal against the pom.xml file. I found that if I run "mvn clean" > from this same directory (where the build.xml and pom.xml file is located), > using Maven-2.0.7, I get a build successfull (it was able to find the parent > pom.xml file... so this seems to be isolated to JUST the maven-ant-task not > being able to find the parent pom.xml) > Sample of the pom.xml file > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > intuit.sbconnect > sbclogin > 1.0.3 > SBCLogin > > > mygroup > CommonPOM > 1.0.2 > > > > > myothergroup > myartifact > 1.0 > > > > Line in Ant build.xml file that causes the error: > > Error that occurs when this line is executed in ant: > Error downloading parent pom: Missing: > -- > 1) mygroup:CommonPOM:pom:1.0.2 > Path to dependency: > 1) unspecified:unspecified:jar:0.0 > 2) mygroup:CommonPOM:pom:1.0.2 > -- > 1 required artifact is missing. > for artifact: > unspecified:unspecified:jar:0.0 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- 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: (MCHANGES-112) Add more than one link template
Add more than one link template --- Key: MCHANGES-112 URL: http://jira.codehaus.org/browse/MCHANGES-112 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: announcement, changes-report Affects Versions: 2.0-beta-3 Reporter: Olivier Lamy In my company there are two bug tracking systems : * functionnal team use HP Qc * dev team use jira The issueLinkTemplate can only be unique. I'd like to have more than one. -- 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-3052) Transitive Dependency not found when repo is not listed
[ http://jira.codehaus.org/browse/MNG-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3052. --- Resolution: Fixed > Transitive Dependency not found when repo is not listed > --- > > Key: MNG-3052 > URL: http://jira.codehaus.org/browse/MNG-3052 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre >Assignee: John Casey >Priority: Critical > Fix For: 2.0.10 > > Attachments: InheritLegacyRepo.zip, mng_3052.zip > > > I have seen the situation where a build fails because a project has a > transitive dependency that only exists in a repository not listed by my > project. An example of this is I have Projects A, B, and C. Where A depends > on B, and B on C. B has been released to remote repo 1, and C has been > released to remote repo 2. Since A just directly depends on B it only lists > remote repo 1 in its POM. However when I try to build project A the build > fail because it can't resolve its transitive dependency C in any of the > dependencies it is checking (repo 1 only). > It is my understanding that for project A I shouldn't have to list the remote > repos to resolve transitive dependencies. I should only have to list the > repos to get to B and Maven then should use the POM of B to resolve C. > Is that not correct? -- 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: (MNG-3052) Transitive Dependency not found when repo is not listed
[ http://jira.codehaus.org/browse/MNG-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139826#action_139826 ] John Casey commented on MNG-3052: - It appears that this problem is NOT expressed unless the dependencies are snapshots (not sure whether they both have to be, but when they both are, the problem happens)...if I change them both to non-snapshot versions, the problem disappears... > Transitive Dependency not found when repo is not listed > --- > > Key: MNG-3052 > URL: http://jira.codehaus.org/browse/MNG-3052 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre >Assignee: John Casey >Priority: Critical > Fix For: 2.0.10 > > Attachments: InheritLegacyRepo.zip, mng_3052.zip > > > I have seen the situation where a build fails because a project has a > transitive dependency that only exists in a repository not listed by my > project. An example of this is I have Projects A, B, and C. Where A depends > on B, and B on C. B has been released to remote repo 1, and C has been > released to remote repo 2. Since A just directly depends on B it only lists > remote repo 1 in its POM. However when I try to build project A the build > fail because it can't resolve its transitive dependency C in any of the > dependencies it is checking (repo 1 only). > It is my understanding that for project A I shouldn't have to list the remote > repos to resolve transitive dependencies. I should only have to list the > repos to get to B and Maven then should use the POM of B to resolve C. > Is that not correct? -- 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: (MNG-3633) Dependency Management Wildcards
[
http://jira.codehaus.org/browse/MNG-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139812#action_139812
]
Basil James Whitehouse III commented on MNG-3633:
-
Or even to be able to wildcard on the groupid:
org.springframework
*
2.4.5
> Dependency Management Wildcards
> ---
>
> Key: MNG-3633
> URL: http://jira.codehaus.org/browse/MNG-3633
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Geoffrey Wiseman
>
> I'd love to have the option of wildcards in dependency management. When
> you're working with a lot of dependencies that share a common version, it's
> really irritating to have to add each one to the dependency management.
> For instance:
> {code:xml}
>
>
>
> org.springframework
> spring-*
> 2.5.4
>
>
>
> {code}
> Instead of:
> {code:xml}
>
> 2.5.4
>
>
>
>
> com.feedroom.feedroom-commons
> common
> 1.2-SNAPSHOT
>
>
> org.springframework
> spring-orm
> ${springVersion}
>
>
> org.springframework
> spring-test
> ${springVersion}
>
>
> org.springframework
> spring-beans
> ${springVersion}
>
>
> org.springframework
> spring-aop
> ${springVersion}
>
>
> org.springframework
> spring-jdbc
> ${springVersion}
>
>
>
> {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] Created: (MNG-3633) Dependency Management Wildcards
Dependency Management Wildcards
---
Key: MNG-3633
URL: http://jira.codehaus.org/browse/MNG-3633
Project: Maven 2
Issue Type: Improvement
Components: Inheritance and Interpolation
Reporter: Geoffrey Wiseman
I'd love to have the option of wildcards in dependency management. When you're
working with a lot of dependencies that share a common version, it's really
irritating to have to add each one to the dependency management.
For instance:
{code:xml}
org.springframework
spring-*
2.5.4
{code}
Instead of:
{code:xml}
2.5.4
com.feedroom.feedroom-commons
common
1.2-SNAPSHOT
org.springframework
spring-orm
${springVersion}
org.springframework
spring-test
${springVersion}
org.springframework
spring-beans
${springVersion}
org.springframework
spring-aop
${springVersion}
org.springframework
spring-jdbc
${springVersion}
{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: (MNG-3052) Transitive Dependency not found when repo is not listed
[ http://jira.codehaus.org/browse/MNG-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139809#action_139809 ] John Casey commented on MNG-3052: - The problem is that the DefaultArtifactCollector is not using the repository list aggregated and associated with each dependency is read via the MavenMetadataSource...instead, it's using the repository list that was used to resolve the declaring POM (the one that listed those dependencies). I've corrected it and verified by hand that it works with the attached test project, but I still need to convert the attached test project into a self-contained integration-test project before I close this issue. > Transitive Dependency not found when repo is not listed > --- > > Key: MNG-3052 > URL: http://jira.codehaus.org/browse/MNG-3052 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre >Assignee: John Casey >Priority: Critical > Fix For: 2.0.10 > > Attachments: InheritLegacyRepo.zip, mng_3052.zip > > > I have seen the situation where a build fails because a project has a > transitive dependency that only exists in a repository not listed by my > project. An example of this is I have Projects A, B, and C. Where A depends > on B, and B on C. B has been released to remote repo 1, and C has been > released to remote repo 2. Since A just directly depends on B it only lists > remote repo 1 in its POM. However when I try to build project A the build > fail because it can't resolve its transitive dependency C in any of the > dependencies it is checking (repo 1 only). > It is my understanding that for project A I shouldn't have to list the remote > repos to resolve transitive dependencies. I should only have to list the > repos to get to B and Maven then should use the POM of B to resolve C. > Is that not correct? -- 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-106) Excludes do not work as described on the Usage page
[
http://jira.codehaus.org/browse/MJAR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139808#action_139808
]
Vincent Ricard commented on MJAR-106:
-
Hi Michael Mattox,
I had the same problem, i used 2.1, since the 2.2 version all is fine for me.
Check your version with mvn help:effective-pom (look at the pluginManagement
section).
Hope this help.
> Excludes do not work as described on the Usage page
> ---
>
> Key: MJAR-106
> URL: http://jira.codehaus.org/browse/MJAR-106
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Mattox
>
> The jar plugin usage page gives an example:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> **/service/*
>
>
>
> {code}
> If I use excludes, such as this:
> {code:xml}
>
>
>
> **/*.properties
>
>
> {code}
> It doesn't work. I get the properties in both my jar and my -tests.jar.
> However, if I add executions to the plugin configuration, like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> jar
>
>
>
>
> **/*.properties
>
>
>
>
>
> {code}
> Then the properties are excluded form my test jar but NOT from my regular
> jar. Here is some debug output:
> {noformat}
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar'
> -->
> [DEBUG] (f) classesDirectory =
> C:\projects\company\projects\pam\workspace\mm-config\target\classes
> [DEBUG] (f) defaultManifestFile =
> C:\projects\company\projects\pam\workspace\mm-config\target\classes\META-INF\MANIFEST.MF
> [DEBUG] (f) finalName = mm-config-1.0-SNAPSHOT
> [DEBUG] (f) forceCreation = false
> [DEBUG] (f) outputDirectory =
> C:\projects\company\projects\pam\workspace\mm-config\target
> [DEBUG] (f) project = MavenProject: company:mm-config:1.0-SNAPSHOT @
> C:\projects\company\projects\pam\workspace\mm-config\pom.xml
> [DEBUG] (f) useDefaultManifestFile = false
> [DEBUG] -- end configuration --
> [INFO] [jar:jar]
> [DEBUG] isUp2date: false (Destination
> C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
> not found.)
> [INFO] Building jar:
> C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
> [DEBUG] adding directory META-INF/
> [DEBUG] adding entry META-INF/MANIFEST.MF
> [DEBUG] adding directory commons/
> [DEBUG] adding entry commons/applicationContext.xml
> [DEBUG] adding entry database.properties
> [DEBUG] adding entry log4j.xml
> [DEBUG] adding entry messages-exceptions-commons.properties
> [DEBUG] adding entry messages-warnings-commons.properties
> [DEBUG] adding entry mm2-rmi.properties
> [DEBUG] adding directory META-INF/maven/
> [DEBUG] adding directory META-INF/maven/company/
> [DEBUG] adding directory META-INF/maven/company/mm-config/
> [DEBUG] adding entry META-INF/maven/company/mm-config/pom.xml
> [DEBUG] adding entry META-INF/maven/company/mm-config/pom.properties
> [DEBUG] company:mm-config:jar:1.0-SNAPSHOT (selected for null)
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar'
> -->
> [DEBUG] (f) classesDirectory =
> C:\projects\company\projects\pam\workspace\mm-config\target\classes
> [DEBUG] (f) defaultManifestFile =
> C:\projects\company\projects\pam\workspace\mm-config\target\classes\META-INF\MANIFEST.MF
> [DEBUG] (f) excludes = [Ljava.lang.String;@24dd07a
> [DEBUG] (f) finalName = mm-config-1.0-SNAPSHOT
> [DEBUG] (f) forceCreation = false
> [DEBUG] (f) outputDirectory =
> C:\projects\company\projects\pam\workspace\mm-config\target
> [DEBUG] (f) project = MavenProject: company:mm-config:1.0-SNAPSHOT @
> C:\projects\company\projects\pam\workspace\mm-config\pom.xml
> [DEBUG] (f) useDefaultManifestFile = false
> [DEBUG] -- end configuration --
> [INFO] [jar:jar {execution: defa
[jira] Work started: (MNG-3052) Transitive Dependency not found when repo is not listed
[ http://jira.codehaus.org/browse/MNG-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3052 started by John Casey. > Transitive Dependency not found when repo is not listed > --- > > Key: MNG-3052 > URL: http://jira.codehaus.org/browse/MNG-3052 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre >Assignee: John Casey >Priority: Critical > Fix For: 2.0.10 > > Attachments: InheritLegacyRepo.zip, mng_3052.zip > > > I have seen the situation where a build fails because a project has a > transitive dependency that only exists in a repository not listed by my > project. An example of this is I have Projects A, B, and C. Where A depends > on B, and B on C. B has been released to remote repo 1, and C has been > released to remote repo 2. Since A just directly depends on B it only lists > remote repo 1 in its POM. However when I try to build project A the build > fail because it can't resolve its transitive dependency C in any of the > dependencies it is checking (repo 1 only). > It is my understanding that for project A I shouldn't have to list the remote > repos to resolve transitive dependencies. I should only have to list the > repos to get to B and Maven then should use the POM of B to resolve C. > Is that not correct? -- 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: (MRESOURCES-29) An escape mechanism for property interpolation is missing.
[
http://jira.codehaus.org/browse/MRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139805#action_139805
]
Felipe Kamakura commented on MRESOURCES-29:
---
Odd...
I've tried here the $${} in Maven 2.0.9 and it didn't work out. I'm using in
Linux.
> An escape mechanism for property interpolation is missing.
> --
>
> Key: MRESOURCES-29
> URL: http://jira.codehaus.org/browse/MRESOURCES-29
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Hendrik Schreiber
>
> It would be great, if there was a mechanism that let's you escape a property
> so that it is not replaced by the filtering machism. E.g. in a log4j.xml
> configuration file you might want to preserve ${user.home}, but replace some
> other property like ${log.dir}. Currently there is no convenient way to
> achieve that.
> Alternatively to escaping, it would be helpful, if one could choose the token
> format. So, if one could say, only honor @token@ and not ${token} (or the
> other way around) one could easily work around the escape problem.
> Workaround for the problem mentioned above:
> replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
> start=${and end=$} in the property 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: (MRESOURCES-29) An escape mechanism for property interpolation is missing.
[
http://jira.codehaus.org/browse/MRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139802#action_139802
]
Hendrik Schreiber commented on MRESOURCES-29:
-
Great.
Is this an old feature documented somewhere, or is this new and needs to be
documented?
> An escape mechanism for property interpolation is missing.
> --
>
> Key: MRESOURCES-29
> URL: http://jira.codehaus.org/browse/MRESOURCES-29
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Hendrik Schreiber
>
> It would be great, if there was a mechanism that let's you escape a property
> so that it is not replaced by the filtering machism. E.g. in a log4j.xml
> configuration file you might want to preserve ${user.home}, but replace some
> other property like ${log.dir}. Currently there is no convenient way to
> achieve that.
> Alternatively to escaping, it would be helpful, if one could choose the token
> format. So, if one could say, only honor @token@ and not ${token} (or the
> other way around) one could easily work around the escape problem.
> Workaround for the problem mentioned above:
> replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
> start=${and end=$} in the property 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: (MSITE-270) site.xml: menus inherited that should not
[ http://jira.codehaus.org/browse/MSITE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139801#action_139801 ] Dennis Lundberg commented on MSITE-270: --- I can confirm that menus get inherited even when they aren't marked as such, with 2.0-beta-6-SNAPSHOT. However using 2.0-beta-7-SNAPSHOT seems to solve the issue. > site.xml: menus inherited that should not > - > > Key: MSITE-270 > URL: http://jira.codehaus.org/browse/MSITE-270 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, site descriptor >Affects Versions: 2.0-beta-6 >Reporter: Jörg Hohwiller > Attachments: site-inherit-bug.zip > > > I have a project with multiple levels of modules. > In the toplevel project I declare a site-descriptor with some general menu's > that have no inherit attribute (I also tried inherit='none') together with > > > > Now a module of the toplevel project that itself has modules declares a > site-descriptor with an additional regular menu that is inherited. > However the site of that module contains the menus from the toplevel project > that are NOT declared to be inherited. -- 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-2124) javaparser-1.0.0-bundle.jar
javaparser-1.0.0-bundle.jar --- Key: MAVENUPLOAD-2124 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2124 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandr Liahushevich Attachments: javaparser-1.0.0-bundle.jar From: Julio Gesser [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 2:38 PM To: Alexandr Liahushevich Subject: Re: Java 1.5 Parser - request to put sources into the maven repository Helo Alexandr, yes, you can put this distribution there, but I think you need to put the license too. best regards, Júlio Vilmar Gesser 2008/6/24 Alexandr Liahushevich <[EMAIL PROTECTED]>: One more question please. We are using Maven technology for our projects. Is it ok for you and your team that we want to put your javaparser_2008-06-19.jar file in the http://repo1.maven.org/maven2/ central maven repository? -- 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-2121) javaparser-1.0.0 and javaparser-1.0.0-sources
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Liahushevich closed MAVENUPLOAD-2121. -- Resolution: Won't Fix > javaparser-1.0.0 and javaparser-1.0.0-sources > - > > Key: MAVENUPLOAD-2121 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2121 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Alexandr Liahushevich > Attachments: javaparser-1.0.0-bundle.jar, > javaparser-1.0.0-sources.jar, javaparser-1.0.0.jar > > > modelVersion - 1.0.0 (I don't use version numbering yet, but I thing > can be this) > groupId - japa.parser.javaparser > artifactId - javaparser > packaging - jar > name - Java 1.5 Parser and AST > version - 1.0.0 > url - http://code.google.com/p/javaparser/ > licenses- LGPL http://www.gnu.org/licenses/lgpl.html > scm url - http://code.google.com/p/javaparser/ > description - A Java 1.5 Parser with AST generation and visitor support. > dependencies - none > From: Julio Gesser [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 2:38 PM > To: Alexandr Liahushevich > Subject: Re: Java 1.5 Parser - request to put sources into the maven > repository > > Helo Alexandr, > yes, you can put this distribution there, but I think you need to put the > license too. > best regards, > Júlio Vilmar Gesser > 2008/6/24 Alexandr Liahushevich <[EMAIL PROTECTED]>: > One more question please. > We are using Maven technology for our projects. > Is it ok for you and your team that we want to put your > javaparser_2008-06-19.jar file in the http://repo1.maven.org/maven2/ central > maven repository? -- 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: (MNG-3632) Clearer javadocs for MojoExecutionException and MojoFailureException
[ http://jira.codehaus.org/browse/MNG-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139800#action_139800 ] David J. M. Karlsen commented on MNG-3632: -- It's explained on the site: http://www.propellors.net/maven/site/guides/development/guide-plugin-documentation.html > Clearer javadocs for MojoExecutionException and MojoFailureException > > > Key: MNG-3632 > URL: http://jira.codehaus.org/browse/MNG-3632 > Project: Maven 2 > Issue Type: Improvement > Components: Plugin API >Affects Versions: 2.0.9 > Environment: N/A >Reporter: David J. M. Karlsen > > State the difference between MojoExecutionException and MojoFailureException > should be clearer in the javadocs (and maybe aslo on the site). > Maybe add a @see between the two as well. -- 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: (MAVENUPLOAD-2121) javaparser-1.0.0 and javaparser-1.0.0-sources
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Liahushevich updated MAVENUPLOAD-2121: --- Attachment: javaparser-1.0.0-bundle.jar pom.xml javaparser-1.0.0.jar javaparser-1.0.0-sources.jar > javaparser-1.0.0 and javaparser-1.0.0-sources > - > > Key: MAVENUPLOAD-2121 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2121 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Alexandr Liahushevich > Attachments: javaparser-1.0.0-bundle.jar, > javaparser-1.0.0-sources.jar, javaparser-1.0.0.jar > > > modelVersion - 1.0.0 (I don't use version numbering yet, but I thing > can be this) > groupId - japa.parser.javaparser > artifactId - javaparser > packaging - jar > name - Java 1.5 Parser and AST > version - 1.0.0 > url - http://code.google.com/p/javaparser/ > licenses- LGPL http://www.gnu.org/licenses/lgpl.html > scm url - http://code.google.com/p/javaparser/ > description - A Java 1.5 Parser with AST generation and visitor support. > dependencies - none > From: Julio Gesser [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 2:38 PM > To: Alexandr Liahushevich > Subject: Re: Java 1.5 Parser - request to put sources into the maven > repository > > Helo Alexandr, > yes, you can put this distribution there, but I think you need to put the > license too. > best regards, > Júlio Vilmar Gesser > 2008/6/24 Alexandr Liahushevich <[EMAIL PROTECTED]>: > One more question please. > We are using Maven technology for our projects. > Is it ok for you and your team that we want to put your > javaparser_2008-06-19.jar file in the http://repo1.maven.org/maven2/ central > maven repository? -- 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: (MNG-1567) improvements to complex mojo configuration
[ http://jira.codehaus.org/browse/MNG-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139795#action_139795 ] Marvin Froeder commented on MNG-1567: - Will be cool if complex parameters use xstream to parse http://xstream.codehaus.org/ With this, is easy to parse any XML to any object. VELO > improvements to complex mojo configuration > -- > > Key: MNG-1567 > URL: http://jira.codehaus.org/browse/MNG-1567 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 2.x > > > currently, you can specify an object in the configuration that allows nesting > multiple levels of config. This is helpful, but it would be good to be able > to validate those portions of the configuration as well as set default > values, and make them extendable by making them fully fledged configured > component requirements. > basically: > - be able to specify expressions and default values within the fields of the > object, not just the top mojo, as long as it is in the same source tree as > the mojo (like extends) > - to be able to put a polymorphic object in there without an implementation > given in the pom. This might require selectors, and so might be best left > until a later version (se elinked issue for a use case) > I haven't tried, but it might already be possible to do this (from > components.xml), and we just need to wire up the tools to handle it. -- 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: (MDOAP-9) Support more DOAP resource like wikis
[ http://jira.codehaus.org/browse/MDOAP-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MDOAP-9. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 All resources defined in http://usefulinc.com/ns/doap are now supported in r672247 using the DoapOptions object. Note: only ArchRepository and BKRepository tags are not supported because these providers are not supported by SCM. > Support more DOAP resource like wikis > - > > Key: MDOAP-9 > URL: http://jira.codehaus.org/browse/MDOAP-9 > Project: Maven 2.x DOAP Plugin > Issue Type: Improvement >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.0 > > -- 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-144) Cannot generate Javadoc on Mac OS X if path contains space characters
[ http://jira.codehaus.org/browse/MJAVADOC-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139789#action_139789 ] Vincent Ricard commented on MJAVADOC-144: - I've also the bug (linux platform, bash shell) with the 2.4 version. I just now tested the 2.5-SNAPSHOT version, and all is fine for the 'bug of the space' :) Thx > Cannot generate Javadoc on Mac OS X if path contains space characters > - > > Key: MJAVADOC-144 > URL: http://jira.codehaus.org/browse/MJAVADOC-144 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" >Reporter: Claes Buckwalter > > Running 'mvn javadoc:javadoc' fails if the path to the current directory > contains a space character. It works with the 2.0 version of the plugin. It > also works if I rename the directory so that it does not contain a space > character. > presley:~/Documents/workarea/Elk API clabu$ mvn -e javadoc:javadoc > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'javadoc'. > [INFO] > > [INFO] Building The Elk Framework > [INFO]task-segment: [javadoc:javadoc] (aggregator-style) > [INFO] > > [INFO] Preparing javadoc:javadoc > [INFO] > > [INFO] Building The Elk Framework > [INFO] > > [INFO] No goals needed for project - skipping > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org/apache/velocity/runtime/defaults/velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [javadoc:javadoc] > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - cannot read options (No such file or directory) > Command line was:"cd /Users/clabu/Documents/workarea/Elk > API/target/site/apidocs && > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc" > @options @packages > [INFO] > > [
[jira] Created: (MPIR-105) Three enhancements to dependency-convergence report
Three enhancements to dependency-convergence report --- Key: MPIR-105 URL: http://jira.codehaus.org/browse/MPIR-105 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependency-convergence Affects Versions: 2.1 Reporter: Espen Wiborg Attachments: dependency-convergence-enhancements.patch The attached patch adds three enhancements to the dependency-convergence report: 1. Optionally include transitive dependencies in report; see MPIR-71 2. Optionally only include dependencies in error state in report (cuts down the clutter, especially when including transitive dependencies) 3. Optionally exclude dependencies from report if they only occur in one of the reactor projects (again, to cut clutter) -- 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: (MDOAP-11) How to handle release date?
[
http://jira.codehaus.org/browse/MDOAP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MDOAP-11:
-
Attachment: MDOAP-11.patch
This patch is a workaround to handle created release date:
* read the repo artifactId page (ie
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-doap-plugin/ )
* apply a regular expression to find the last modified date on each directory
i.e. version
* write the last modified date found in a tag
> How to handle release date?
> ---
>
> Key: MDOAP-11
> URL: http://jira.codehaus.org/browse/MDOAP-11
> Project: Maven 2.x DOAP Plugin
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Vincent Siveton
> Attachments: MDOAP-11.patch
>
>
> Actually, the mojo generates:
> {code:xml}
> ...
>
>
> PROJECT NAME - VERSION
> VERSION
>
> http://repo1.maven.org/maven2/org/apache/maven/...
>
>
> ...
> {code}
> It should be nice to add the release created tag, ie
> {code:xml}
> ...
>
> ...
> 2008-06-27
>
> ...
> {code}
> Actually, the RepositoryMetadata doesn't have any notions of release date for
> a given 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
[jira] Commented: (MSITE-341) 'nonProxyHosts' element is not handled when we deploy a site
[ http://jira.codehaus.org/browse/MSITE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139787#action_139787 ] Vincent Ricard commented on MSITE-341: -- It seems you're right. I only looked for in the opened issues :-/ I'm waiting the beta7 is available on the mirrors to test. If that's ok i'll close this issue. > 'nonProxyHosts' element is not handled when we deploy a site > > > Key: MSITE-341 > URL: http://jira.codehaus.org/browse/MSITE-341 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-6 > Environment: Maven version: 2.0.9 > Java version: 1.5.0_15 > OS name: "linux" >Reporter: Vincent Ricard > > I've a proxy set in my settings.xml file like that: > > true > http > proxy.domain.tld > 3128 > > > > deploy-server.domain.tld > > When i run 'mvn site:deploy' i get this stack trace: > java.lang.ArrayIndexOutOfBoundsException: 2 > at com.jcraft.jsch.Util.toBase64(Unknown Source) > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:177) > 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:291) > 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) > Because the 'nonProxyHosts' element is not used. When i comment my whole > 'proxy' block, all is fine. -- 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: (MDOAP-11) How to handle release date?
How to handle release date?
---
Key: MDOAP-11
URL: http://jira.codehaus.org/browse/MDOAP-11
Project: Maven 2.x DOAP Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Vincent Siveton
Actually, the mojo generates:
{code:xml}
...
PROJECT NAME - VERSION
VERSION
http://repo1.maven.org/maven2/org/apache/maven/...
...
{code}
It should be nice to add the release created tag, ie
{code:xml}
...
...
2008-06-27
...
{code}
Actually, the RepositoryMetadata doesn't have any notions of release date for a
given 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
[jira] Closed: (MDOAP-4) Handle versions
[ http://jira.codehaus.org/browse/MDOAP-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MDOAP-4. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 fixed in r672244 > Handle versions > --- > > Key: MDOAP-4 > URL: http://jira.codehaus.org/browse/MDOAP-4 > Project: Maven 2.x DOAP Plugin > Issue Type: New Feature >Reporter: Dennis Lundberg >Assignee: Vincent Siveton > Fix For: 1.0 > > -- 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: (MRESOURCES-29) An escape mechanism for property interpolation is missing.
[
http://jira.codehaus.org/browse/MRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139763#action_139763
]
Dave O'Flanagan commented on MRESOURCES-29:
---
I've tried $${user.id} in maven 2.0.9 and it works fine. I get ${user.id} in
the output.
> An escape mechanism for property interpolation is missing.
> --
>
> Key: MRESOURCES-29
> URL: http://jira.codehaus.org/browse/MRESOURCES-29
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Hendrik Schreiber
>
> It would be great, if there was a mechanism that let's you escape a property
> so that it is not replaced by the filtering machism. E.g. in a log4j.xml
> configuration file you might want to preserve ${user.home}, but replace some
> other property like ${log.dir}. Currently there is no convenient way to
> achieve that.
> Alternatively to escaping, it would be helpful, if one could choose the token
> format. So, if one could say, only honor @token@ and not ${token} (or the
> other way around) one could easily work around the escape problem.
> Workaround for the problem mentioned above:
> replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
> start=${and end=$} in the property 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: (MSITE-341) 'nonProxyHosts' element is not handled when we deploy a site
[ http://jira.codehaus.org/browse/MSITE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139759#action_139759 ] Dennis Lundberg commented on MSITE-341: --- Sounds like a duplicate of MSITE-211 > 'nonProxyHosts' element is not handled when we deploy a site > > > Key: MSITE-341 > URL: http://jira.codehaus.org/browse/MSITE-341 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-6 > Environment: Maven version: 2.0.9 > Java version: 1.5.0_15 > OS name: "linux" >Reporter: Vincent Ricard > > I've a proxy set in my settings.xml file like that: > > true > http > proxy.domain.tld > 3128 > > > > deploy-server.domain.tld > > When i run 'mvn site:deploy' i get this stack trace: > java.lang.ArrayIndexOutOfBoundsException: 2 > at com.jcraft.jsch.Util.toBase64(Unknown Source) > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:177) > 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:291) > 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) > Because the 'nonProxyHosts' element is not used. When i comment my whole > 'proxy' block, all is fine. -- 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: (MSITE-341) 'nonProxyHosts' element is not handled when we deploy a site
'nonProxyHosts' element is not handled when we deploy a site Key: MSITE-341 URL: http://jira.codehaus.org/browse/MSITE-341 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.0-beta-6 Environment: Maven version: 2.0.9 Java version: 1.5.0_15 OS name: "linux" Reporter: Vincent Ricard I've a proxy set in my settings.xml file like that: true http proxy.domain.tld 3128 deploy-server.domain.tld When i run 'mvn site:deploy' i get this stack trace: java.lang.ArrayIndexOutOfBoundsException: 2 at com.jcraft.jsch.Util.toBase64(Unknown Source) at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:177) 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:291) 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) Because the 'nonProxyHosts' element is not used. When i comment my whole 'proxy' block, all is fine. -- 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-2583) DefaultArtifact: Method getVersionRange returns null also if field version is already set! [SMALL PATCH ATTACHED]
[ http://jira.codehaus.org/browse/MNG-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zeltner closed MNG-2583. --- Resolution: Fixed Fix Version/s: (was: 2.0.10) 2.0.9 > DefaultArtifact: Method getVersionRange returns null also if field version is > already set! [SMALL PATCH ATTACHED] > - > > Key: MNG-2583 > URL: http://jira.codehaus.org/browse/MNG-2583 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0-alpha-1 > Environment: Java5, WinXp >Reporter: Martin Zeltner >Assignee: Jason van Zyl > Fix For: 2.0.9 > > Attachments: patch_maven-artifact_made-getVersionRange-saver.patch > > > In class *org.apache.maven.artifact.DefaultArtifact* method *getVersionRange* > returns *null* altough the version field is already set. In attached patch I > check in method getVersionRange if versionRange is null if field version or > baseVersion is already set and then create the versionRange by using > version/baseVersion. By the way I've replaced HashMap with a LinkedHashMap to > remember the insertion order of meta data. > For those who don't see why this patch is needed can try binding the eclipse > plugin to a phase before the jar plugin is bound. The eclipse plugin uses the > org.apache.maven.artifact.resolver.DefaultArtifactCollector which is invoking > method setVersion of org.apache.maven.artifact.DefaultArtifact which will > erase field version range and cause a NullPointerException in plugin jar that > doesn't check if returned version range is null. > Cheers, > Martin -- 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: (MNG-2583) DefaultArtifact: Method getVersionRange returns null also if field version is already set! [SMALL PATCH ATTACHED]
[ http://jira.codehaus.org/browse/MNG-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139754#action_139754 ] Martin Zeltner commented on MNG-2583: - With Maven 2.0.8 I had to apply this patch but with 2.0.9 it seams to work without. It should be that such small things like this issue is discussed when the issue is created (Oct 06) an not 20 months later! So I have also time to discuss it and I'm still in the context of this bug, thanks. Cheers, Martin > DefaultArtifact: Method getVersionRange returns null also if field version is > already set! [SMALL PATCH ATTACHED] > - > > Key: MNG-2583 > URL: http://jira.codehaus.org/browse/MNG-2583 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0-alpha-1 > Environment: Java5, WinXp >Reporter: Martin Zeltner >Assignee: Jason van Zyl > Fix For: 2.0.9 > > Attachments: patch_maven-artifact_made-getVersionRange-saver.patch > > > In class *org.apache.maven.artifact.DefaultArtifact* method *getVersionRange* > returns *null* altough the version field is already set. In attached patch I > check in method getVersionRange if versionRange is null if field version or > baseVersion is already set and then create the versionRange by using > version/baseVersion. By the way I've replaced HashMap with a LinkedHashMap to > remember the insertion order of meta data. > For those who don't see why this patch is needed can try binding the eclipse > plugin to a phase before the jar plugin is bound. The eclipse plugin uses the > org.apache.maven.artifact.resolver.DefaultArtifactCollector which is invoking > method setVersion of org.apache.maven.artifact.DefaultArtifact which will > erase field version range and cause a NullPointerException in plugin jar that > doesn't check if returned version range is null. > Cheers, > Martin -- 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
