[jira] Commented: (MEV-662) Invalid Geronimo signatures in central
[ http://jira.codehaus.org/browse/MEV-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223719#action_223719 ] Anders Hammar commented on MEV-662: --- More invalid signatures (the genesis-1.1 release): org.apache.geronimo.genesis:genesis:pom:1.1 org.apache.geronimo.genesis.config:*:pom:1.1 org.apache.geronimo.genesis.plugins:*:pom:1.1 > Invalid Geronimo signatures in central > -- > > Key: MEV-662 > URL: http://jira.codehaus.org/browse/MEV-662 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Anders Hammar > > I've found a few more invalid signatures in central: > org.apache.geronimo.genesis:genesis:pom:1.2 - This one has been reported in > GERONIMO-5309 as well. > org.apache.geronimo.specs:geronimo-j2ee-management_1.0_spec:pom:1.1 > org.apache.geronimo.specs:geronimo-ejb_2.1_spec:pom:1.1 > org.apache.geronimo.specs:geronimo-j2ee-deployment_1.1_spec:pom:1.1 > org.apache.geronimo.specs:geronimo-ejb_3.0_spec:pom:1.0 > I found these when trying to download dependencies through Nexus Pro > signature procurement. I would suspect that there are more invalid signatures > within the org.apache.geronimo space. > Not sure what should be done - should these signatures be removed? As it's > the poms, it should be possible for the Geronimo project to check against svn > and re-sign, but the comments in GERONIMO-5309 makes me suspect they don't > want to do 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: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223731#action_223731 ] Paul Hammant commented on MAVENUPLOAD-2738: --- OK, I've updated the tck pom. See http://atinject.googlecode.com/svn/trunk/tck-pom.xml I'm inspired by my recent success with release/gpg to sonatype (Github rather that googlecode) exemplified here :- http://github.com/paul-hammant/mockpico/blob/master/pom.xml Question to the Mavenistas: will the release:prepare/perform stuff work with a pom file not called pom.xml OR does it have the same bug as http://jira.codehaus.org/browse/MREPOSITORY-22 (the -f directive is ignored). If yes, I can temporarily overwrite the pom.xml file in svn with the tck one, do the release, then revert the change in svn (even though that's kinda dirty workaround) > JSR330 @Inject TCK (official release) 1 > --- > > Key: MAVENUPLOAD-2738 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Paul Hammant >Assignee: Juven Xu > > I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page > for that project. > paul / codehaus == PaulHammant / GoogleCode. -- 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: (MECLIPSE-636) MECLIPSE-156 wasn't resolved
[ http://jira.codehaus.org/browse/MECLIPSE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223750#action_223750 ] Ramiro Pereira de Magalhães commented on MECLIPSE-636: -- Hey, guys, I uploaded a patch that has a fix for this issue and the a test case that shows the problem is solved, but it has not been applied yet. Am I missing something? Is there anything else I can do to help you solve this issue? > MECLIPSE-156 wasn't resolved > > > Key: MECLIPSE-636 > URL: http://jira.codehaus.org/browse/MECLIPSE-636 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.7 >Reporter: Ramiro Pereira de Magalhães > Attachments: MECLIPSE-636-withTests.patch, patch-MECLIPSE-636.patch > > > Task MECLIPSE-156 wasn't correctly implemented and the proposed feature > (namely, that the plugin should support setting file encoding) does not work. > I think that only one of the proposed patches there were implemented (on > IdeUtils.java) while the other (on EclipseUtils.java) one wasn'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] Commented: (MANTRUN-140) project.build.outputDirectory property is invalid
[
http://jira.codehaus.org/browse/MANTRUN-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223760#action_223760
]
Dutrieux Olivier commented on MANTRUN-140:
--
A workaround is to add a property in your task like this :
{code:java}
<.../>
{code}
or
{code:xml}
<.../>
{code}
> project.build.outputDirectory property is invalid
> -
>
> Key: MANTRUN-140
> URL: http://jira.codehaus.org/browse/MANTRUN-140
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_18
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergey Pulyaev
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.5
>
> Attachments: try-1.3.zip, try-1.4.zip
>
>
> While running version 1.3 of plugin -
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> but version 1.4 return invalid info:
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> Seems like testOutputDirectory is not defined at all, and outputDirectory is
> set to value of testOutputDirectory
> See attached projects for test cases and logs
--
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] Issue Comment Edited: (MANTRUN-140) project.build.outputDirectory property is invalid
[
http://jira.codehaus.org/browse/MANTRUN-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223760#action_223760
]
Dutrieux Olivier edited comment on MANTRUN-140 at 6/2/10 9:02 AM:
--
A workaround is to add a property in your task like this :
{code:xml}
<.../>
{code}
or
{code:xml}
<.../>
{code}
was (Author: dutrieux):
A workaround is to add a property in your task like this :
{code:java}
<.../>
{code}
or
{code:xml}
<.../>
{code}
> project.build.outputDirectory property is invalid
> -
>
> Key: MANTRUN-140
> URL: http://jira.codehaus.org/browse/MANTRUN-140
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_18
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergey Pulyaev
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.5
>
> Attachments: try-1.3.zip, try-1.4.zip
>
>
> While running version 1.3 of plugin -
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> but version 1.4 return invalid info:
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> Seems like testOutputDirectory is not defined at all, and outputDirectory is
> set to value of testOutputDirectory
> See attached projects for test cases and logs
--
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] Issue Comment Edited: (MANTRUN-140) project.build.outputDirectory property is invalid
[
http://jira.codehaus.org/browse/MANTRUN-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223760#action_223760
]
Dutrieux Olivier edited comment on MANTRUN-140 at 6/2/10 9:02 AM:
--
A workaround is to add a property in your task like this :
{code:java}
<.../>
{code}
or
{code:xml}
<.../>
{code}
was (Author: dutrieux):
A workaround is to add a property in your task like this :
{code:java}
<.../>
{code}
or
{code:xml}
<.../>
{code}
> project.build.outputDirectory property is invalid
> -
>
> Key: MANTRUN-140
> URL: http://jira.codehaus.org/browse/MANTRUN-140
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_18
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergey Pulyaev
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.5
>
> Attachments: try-1.3.zip, try-1.4.zip
>
>
> While running version 1.3 of plugin -
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> but version 1.4 return invalid info:
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> Seems like testOutputDirectory is not defined at all, and outputDirectory is
> set to value of testOutputDirectory
> See attached projects for test cases and logs
--
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] Issue Comment Edited: (MANTRUN-140) project.build.outputDirectory property is invalid
[
http://jira.codehaus.org/browse/MANTRUN-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223760#action_223760
]
Dutrieux Olivier edited comment on MANTRUN-140 at 6/2/10 9:03 AM:
--
A workaround is to add a property in your task like this :
{code:xml}
<.../>
{code}
or
{code:xml}
<.../>
{code}
was (Author: dutrieux):
A workaround is to add a property in your task like this :
{code:xml}
<.../>
{code}
or
{code:xml}
<.../>
{code}
> project.build.outputDirectory property is invalid
> -
>
> Key: MANTRUN-140
> URL: http://jira.codehaus.org/browse/MANTRUN-140
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_18
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergey Pulyaev
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.5
>
> Attachments: try-1.3.zip, try-1.4.zip
>
>
> While running version 1.3 of plugin -
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> but version 1.4 return invalid info:
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> Seems like testOutputDirectory is not defined at all, and outputDirectory is
> set to value of testOutputDirectory
> See attached projects for test cases and logs
--
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: (MANTRUN-140) project.build.outputDirectory property is invalid
[
http://jira.codehaus.org/browse/MANTRUN-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223761#action_223761
]
Paul Gier commented on MANTRUN-140:
---
It looks like this only affects external Ant build files. If the property is
in-line in the POM, Maven translates it before the antrun plugin starts running.
> project.build.outputDirectory property is invalid
> -
>
> Key: MANTRUN-140
> URL: http://jira.codehaus.org/browse/MANTRUN-140
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_18
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergey Pulyaev
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.5
>
> Attachments: try-1.3.zip, try-1.4.zip
>
>
> While running version 1.3 of plugin -
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> but version 1.4 return invalid info:
> [INFO] Executing tasks
> [echo] project.build.outputDirectory
> =D:\work_pc2ws\try\target\test-classes
> [echo] project.build.directory/project.build.finalName
> =D:\work_pc2ws\try\target/test
> [echo] project.build.testOutputDirectory
> =${project.build.testOutputDirectory}
> Seems like testOutputDirectory is not defined at all, and outputDirectory is
> set to value of testOutputDirectory
> See attached projects for test cases and logs
--
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: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223763#action_223763 ] Juven Xu commented on MAVENUPLOAD-2738: --- I don't think you can use an alternative pom to do release but why you want to overwrite pom.xml with another projects' pom? I don't get it > JSR330 @Inject TCK (official release) 1 > --- > > Key: MAVENUPLOAD-2738 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Paul Hammant >Assignee: Juven Xu > > I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page > for that project. > paul / codehaus == PaulHammant / GoogleCode. -- 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: (DOXIA-394) Transitive dependency to old commons-logging through HttpClient causes problems
Transitive dependency to old commons-logging through HttpClient causes problems --- Key: DOXIA-394 URL: http://jira.codehaus.org/browse/DOXIA-394 Project: Maven Doxia Issue Type: Bug Components: Maven plugin Affects Versions: 1.1.3 Reporter: isabel drost The issue (and resulting trouble) is described in more detail over in the MSITE issue tracker: http://jira.codehaus.org/browse/MSITE-459 Excluding the dependency entirely solved the problem for me. See attached diff for the changes I made. -- 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: (DOXIA-394) Transitive dependency to old commons-logging through HttpClient causes problems
[ http://jira.codehaus.org/browse/DOXIA-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] isabel drost updated DOXIA-394: --- Attachment: DOXIA-394.diff The changes that fixed the mvn site:deploy goal for me. > Transitive dependency to old commons-logging through HttpClient causes > problems > --- > > Key: DOXIA-394 > URL: http://jira.codehaus.org/browse/DOXIA-394 > Project: Maven Doxia > Issue Type: Bug > Components: Maven plugin >Affects Versions: 1.1.3 >Reporter: isabel drost > Attachments: DOXIA-394.diff > > > The issue (and resulting trouble) is described in more detail over in the > MSITE issue tracker: http://jira.codehaus.org/browse/MSITE-459 > Excluding the dependency entirely solved the problem for me. See attached > diff for the changes I made. -- 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: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223795#action_223795 ] Paul Hammant commented on MAVENUPLOAD-2738: --- Bob Lee (the lead for JSR330) will never in his remaining years on this planet ever use Maven. Those of us that like Maven, will have to live with non-module organization of the source for the @Inject project. That means two pom files that are in the same directory :- http://atinject.googlecode.com/svn/trunk/ > I don't think you can use an alternative pom to do release I will try. If it does not work, I will raise an issue on codehaus for the release plugin > but why you want to overwrite pom.xml with another projects' pom? I don't get > it This is my workaround if the alternate-pom side of the release plugin has that issue. > JSR330 @Inject TCK (official release) 1 > --- > > Key: MAVENUPLOAD-2738 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Paul Hammant >Assignee: Juven Xu > > I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page > for that project. > paul / codehaus == PaulHammant / GoogleCode. -- 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-484) Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format
Support adding and overriding report plugins in new maven-site-plugin 3.x
reportPlugins configuration format
Key: MSITE-484
URL: http://jira.codehaus.org/browse/MSITE-484
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance
Affects Versions: 3.0-alpha-1
Environment: 3.0-beta-1-SNAPSHOT
Reporter: Michael Pilquist
Attachments: site-cfg-inheritance.zip
When using the new configuration format for reportPlugins, it appears that
there's no way to:
- Add a report plugin to a submodule
- Override the configuration of a report plugin in a submodule
Using the old section, both of these use cases were supported. For
large, multi-module builds, it is problematic having to respecify all reporting
plugins in any submodule pom that needs to either add an additional reporting
plugin or change the configuration of a reporting plugin.
Attached is a sample project that has a parent POM configured with
project-info-reports and javadoc plugin and a submodule configured with jxr
plugin and javadoc plugin. The relevant output is here:
{code}
[INFO]
[INFO] Building parent 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent ---
[INFO] Deleting file set: /Users/mpilquist/Downloads/site-parent-issue/target
(included: [**], excluded: [])
[INFO]
[INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @ parent
---
[INFO] configuring reportPlugin
org.apache.maven.plugins:maven-project-info-reports-plugin:2.2
[INFO] configuring reportPlugin
org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
...
[INFO]
[INFO] Building parent-usage-test 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent-usage-test ---
[INFO]
[INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @
parent-usage-test ---
[INFO] configuring reportPlugin org.apache.maven.plugins:maven-jxr-plugin:2.1
[INFO] configuring reportPlugin
org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
{code}
Looking at the maven-site-plugin code, it appears the the reportPlugins
parameter is just a regular array parameter. AFAIK, there's no way to merge
list configuration items. Other plugins have worked around this by defining
additional mojo parameters (e.g., maven-eclipse-plugin and buildCommands /
additionalBuildCommands --
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html). This
isn't the most flexible option though as it only solves 1 level inheritance.
--
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-568) Release plugin (in perform phase) ignore -f directive (non-default pom.xml file)
Release plugin (in perform phase) ignore -f directive (non-default pom.xml file) Key: MRELEASE-568 URL: http://jira.codehaus.org/browse/MRELEASE-568 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Paul Hammant mvn -f alternate-pom.xml release:perform [ time passes ] [INFO] Working directory: /scm/oss/atinject/target [INFO] Executing goals 'deploy'... [INFO] Executing: /bin/sh -c cd /scm/oss/atinject/target/checkout && /Installed/apache-maven-2.2.1/bin/mvn deploy --no-plugin-updates -DperformRelease=true -f pom.xml -- 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: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223802#action_223802 ] Paul Hammant commented on MAVENUPLOAD-2738: --- As suspected, the alternate-pom bug in the release plugin exists :- http://jira.codehaus.org/browse/MRELEASE-568 I will try the second approach I outlined. > JSR330 @Inject TCK (official release) 1 > --- > > Key: MAVENUPLOAD-2738 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Paul Hammant >Assignee: Juven Xu > > I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page > for that project. > paul / codehaus == PaulHammant / GoogleCode. -- 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-4698) Infinite loop on processing-resources with m2eclipse
Infinite loop on processing-resources with m2eclipse Key: MNG-4698 URL: http://jira.codehaus.org/browse/MNG-4698 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0-beta-2 Environment: Eclipse 3.5.2 M2Eclipse 0.10.0 with external mvn Maven 3 (current svn) Reporter: George Lindholm Every once in a while when I update a project, the maven plugin goes into an infinite loop building the workspace. I have to manually stop the build. The only thing I see on the console is: 02/06/10 12:19:08 PDT PM: Maven Builder: AUTO_BUILD requireFullBuild 02/06/10 12:19:09 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered resources. 02/06/10 12:19:09 PDT PM: [INFO] Copying 0 resource 02/06/10 12:19:09 PDT PM: [INFO] Nothing to compile - all classes are up to date 02/06/10 12:19:09 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered resources. 02/06/10 12:19:09 PDT PM: [INFO] Copying 0 resource 02/06/10 12:19:09 PDT PM: [INFO] Compiling 1 source file to E:\java\workspace\ks-web\ks-standalone\target\classes 02/06/10 12:19:11 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered resources. 02/06/10 12:19:11 PDT PM: [INFO] Copying 0 resource 02/06/10 12:19:11 PDT PM: [INFO] Nothing to compile - all classes are up to date 02/06/10 12:19:13 PDT PM: Maven Builder: AUTO_BUILD requireFullBuild 02/06/10 12:19:13 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered resources. 02/06/10 12:19:13 PDT PM: [INFO] Copying 0 resource 02/06/10 12:19:13 PDT PM: [INFO] Nothing to compile - all classes are up to date 02/06/10 12:19:14 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered resources. 02/06/10 12:19:14 PDT PM: [INFO] Copying 0 resource 02/06/10 12:19:14 PDT PM: [INFO] Compiling 1 source file to E:\java\workspace\ks-web\ks-standalone\target\classes 02/06/10 12:19:15 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered resources. 02/06/10 12:19:15 PDT PM: [INFO] Copying 0 resource 02/06/10 12:19:15 PDT PM: [INFO] Nothing to compile - all classes are up to date over and over and over I have no idea on how to get a better idea as what is going on -- 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-4698) Infinite loop on processing-resources with m2eclipse
[ http://jira.codehaus.org/browse/MNG-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4698. -- Resolution: Not A Bug Assignee: Benjamin Bentmann Please report this at https://issues.sonatype.org/browse/MNGECLIPSE instead. > Infinite loop on processing-resources with m2eclipse > > > Key: MNG-4698 > URL: http://jira.codehaus.org/browse/MNG-4698 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-2 > Environment: Eclipse 3.5.2 > M2Eclipse 0.10.0 with external mvn > Maven 3 (current svn) >Reporter: George Lindholm >Assignee: Benjamin Bentmann > > Every once in a while when I update a project, the maven plugin goes into an > infinite loop > building the workspace. I have to manually stop the build. > The only thing I see on the console is: > 02/06/10 12:19:08 PDT PM: Maven Builder: AUTO_BUILD requireFullBuild > 02/06/10 12:19:09 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered > resources. > 02/06/10 12:19:09 PDT PM: [INFO] Copying 0 resource > 02/06/10 12:19:09 PDT PM: [INFO] Nothing to compile - all classes are up to > date > 02/06/10 12:19:09 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered > resources. > 02/06/10 12:19:09 PDT PM: [INFO] Copying 0 resource > 02/06/10 12:19:09 PDT PM: [INFO] Compiling 1 source file to > E:\java\workspace\ks-web\ks-standalone\target\classes > 02/06/10 12:19:11 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered > resources. > 02/06/10 12:19:11 PDT PM: [INFO] Copying 0 resource > 02/06/10 12:19:11 PDT PM: [INFO] Nothing to compile - all classes are up to > date > 02/06/10 12:19:13 PDT PM: Maven Builder: AUTO_BUILD requireFullBuild > 02/06/10 12:19:13 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered > resources. > 02/06/10 12:19:13 PDT PM: [INFO] Copying 0 resource > 02/06/10 12:19:13 PDT PM: [INFO] Nothing to compile - all classes are up to > date > 02/06/10 12:19:14 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered > resources. > 02/06/10 12:19:14 PDT PM: [INFO] Copying 0 resource > 02/06/10 12:19:14 PDT PM: [INFO] Compiling 1 source file to > E:\java\workspace\ks-web\ks-standalone\target\classes > 02/06/10 12:19:15 PDT PM: [INFO] Using 'UTF-8' encoding to copy filtered > resources. > 02/06/10 12:19:15 PDT PM: [INFO] Copying 0 resource > 02/06/10 12:19:15 PDT PM: [INFO] Nothing to compile - all classes are up to > date > over and over and over > I have no idea on how to get a better idea as what is going on -- 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: (SUREFIRE-616) surefire-report doesn't create target/site/css
[ http://jira.codehaus.org/browse/SUREFIRE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223829#action_223829 ] Freddy Daoud commented on SUREFIRE-616: --- Having the same issue with org.apache.maven.plugins, maven-surefire-plugin, version 2.5 and org.testng, testng, version 5.12.1. > surefire-report doesn't create target/site/css > -- > > Key: SUREFIRE-616 > URL: http://jira.codehaus.org/browse/SUREFIRE-616 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin > Environment: Maven 2.2.1, Java 1.6.0_17, OS/X 10.6.3 >Reporter: Marco Brandizi > > I've just try " mvn surefire-report:report-only" and I get what said in the > subject. It creates site surefire-report.html, but not the css/*.css files > that are imported by such html. The result is quite ugly to see. -- 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: (MANTRUN-141) Merge the AbstractAntMojo with the AntRunMojo
[ http://jira.codehaus.org/browse/MANTRUN-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-141: -- Fix Version/s: 1.5 Assignee: Paul Gier > Merge the AbstractAntMojo with the AntRunMojo > - > > Key: MANTRUN-141 > URL: http://jira.codehaus.org/browse/MANTRUN-141 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 1.5 > > > I believe the AbstractAntMojo is not usable by itself right now. So I think > it makes sense to merge it into the AntRunMojo to make the code a bit simpler. -- 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: (MANTRUN-141) Merge the AbstractAntMojo with the AntRunMojo
Merge the AbstractAntMojo with the AntRunMojo - Key: MANTRUN-141 URL: http://jira.codehaus.org/browse/MANTRUN-141 Project: Maven 2.x Antrun Plugin Issue Type: Improvement Reporter: Paul Gier Priority: Minor I believe the AbstractAntMojo is not usable by itself right now. So I think it makes sense to merge it into the AntRunMojo to make the code a bit simpler. -- 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: (MANTRUN-142) Refactor the tasks parameter to simplify integration with Ant
[ http://jira.codehaus.org/browse/MANTRUN-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-142: -- Fix Version/s: 1.5 Assignee: Paul Gier > Refactor the tasks parameter to simplify integration with Ant > - > > Key: MANTRUN-142 > URL: http://jira.codehaus.org/browse/MANTRUN-142 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.5 > > > The "tasks" parameter should be renamed to "target" since this would better > reflect what it represents. > Also the way the internal Ant target is created could be refactored to > simplify the integration with Ant. -- 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: (MANTRUN-142) Refactor the tasks parameter to simplify integration with Ant
Refactor the tasks parameter to simplify integration with Ant - Key: MANTRUN-142 URL: http://jira.codehaus.org/browse/MANTRUN-142 Project: Maven 2.x Antrun Plugin Issue Type: Improvement Reporter: Paul Gier The "tasks" parameter should be renamed to "target" since this would better reflect what it represents. Also the way the internal Ant target is created could be refactored to simplify the integration with Ant. -- 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-485) Add a DateBuilt field to the Build Information section of the Project Summary page
Add a DateBuilt field to the Build Information section of the Project Summary page -- Key: MSITE-485 URL: http://jira.codehaus.org/browse/MSITE-485 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: William Ferguson One of the biggest problems (IMHO) when looking at project documentation is the inability to readily determine the age of a component or the age age of the documentation. Such information is often sued to make a decision on how relevant a new component might be. The Project Summary page generated by the Site plugin contains a Build Information section. This section identifies the GroupId, ArtifactId, Version, and Type. If it also published the DateTime at which a component was built then it solve the problem above. -- 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: (MDEP-106) Unpacking primary artifact from sibling module uses repository rather than reactor
[
http://jira.codehaus.org/browse/MDEP-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223853#action_223853
]
Brian Fox commented on MDEP-106:
It conceivably could be fixed in the plugin to check the reactor, but I'm
unlikely to do it since M3 solves this for us. If someone wants to attach a
patch then I'll take a look
> Unpacking primary artifact from sibling module uses repository rather than
> reactor
> --
>
> Key: MDEP-106
> URL: http://jira.codehaus.org/browse/MDEP-106
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0-alpha-4
>Reporter: Matt Ryall
>Assignee: Brian Fox
>
> Running dependency:unpack referencing a project in the reactor has the
> following output which shows it is scanning for repository artifacts rather
> than the artifact in the reactor:
> {quote}
> [INFO] [dependency:unpack \{execution: unpack-tests}]
> [INFO] Configured Artifact:
> com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
> [INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
> for updates from snapshots
> [INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
> for updates from m1-repo
> Downloading:
> http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
> 9125K downloaded
> [INFO] Expanding:
> /Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar
> into /Users/mryall/src/example/app/app-webapp/target/it-classes
> {quote}
> To explain the scenario: to build reusable acceptance tests, I have the
> following sub-modules of my project:
> - app-core (jar)
> - app-acceptance-tests (jar)
> - app-webapp (war)
> The acceptance tests are packaged this way for further use in testing, and
> also run against the webapp in the integration-test phase. This is where the
> problem arises.
> Running 'mvn clean integration-test' does the following relevant tasks:
> - in the app-acceptance-test module, compiles and packages a JAR of tests
> - in the app-webapp module, uses the dependency:unpack goal to extract the
> tests into target/it-classes in the pre-integration-test phase, and test:test
> to run them in the integration test phase.
> I don't think this is caused by the snapshot version, because the release
> plugin also fails because it is unable to find the 2.6 version when it runs
> 'mvn clean verify'. There, it scans all the repositories for the acceptance
> test artifact before failing with the usual error:
> {quote}
> [INFO] Failed to resolve artifact.
>
> GroupId: com.example.app
> ArtifactId: app-acceptance-test
> Version: 2.6
>
> Reason: Unable to download the artifact from any repository
> {quote}
> Maven details:
> {noformat}
> $ mvn -version
> Maven version: 2.0.7
> Java version: 1.4.2_12
> OS name: "mac os x" version: "10.4.10" arch: "i386"
> {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
