[jira] Commented: (MECLIPSE-132) "Class not found" when run/debug JUnit tests
[ http://jira.codehaus.org/browse/MECLIPSE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144890#action_144890 ] Antony Stubbs commented on MECLIPSE-132: ok, problems back and the work around didn't work this time. I also have an issue with opening files with getResourceAsStream in the other problematic project and think it may be related... > "Class not found" when run/debug JUnit tests > > > Key: MECLIPSE-132 > URL: http://jira.codehaus.org/browse/MECLIPSE-132 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path, M2Eclipse > support > Environment: gentoo linux 2006, kernel 2.6, sun-jdk-1.5.0.06, maven > 2.0.4, eclipse sdk 3.2, myeclipse 5 m2 >Reporter: Diego Ballve > Attachments: maven-sample.zip > > > This is for the behavior described in > http://www.nabble.com/Keep-getting-%22Class-not-found%22-when-running-debugging-JUnit-tests-tf1851758.html#a5442440 > You get "Class not found" when running/debuging JUnit tests. > For me it happened when I was importing another project and its dependencies > (both m2 projects). > Clean compile works fine, problem is with run. > The workaround to get it working is: > In the project containing your tests, edit Java Build Path | Order and > Export: Make sure M2 Dependencies appears BEFORE JRE System Library. > Thanks, > Diego -- 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-116) NPE if installing pom with type pom
[
http://jira.codehaus.org/browse/MANTTASKS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144889#action_144889
]
Antony Stubbs commented on MANTTASKS-116:
-
ok my bad. actually forgot to change the type to 'pom' in the pom.xml.
Can we change the title of the issue to NPE when install target is missing file
and pom type is JAR? ;)
> NPE if installing pom with type pom
> ---
>
> Key: MANTTASKS-116
> URL: http://jira.codehaus.org/browse/MANTTASKS-116
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Reporter: Antony Stubbs
>
> {code}
> maven-repo-install:
> parsing buildfile
> jar:file:/C:/dev/tools/maven-ant-tasks-lib/maven-ant-tasks-2.0.9.jar!/org/apache/maven/artifact/ant/antlib.xml
> with URI =
> jar:file:/C:/dev/tools/maven-ant-tasks-lib/maven-ant-tasks-2.0.9.jar!/org/apache/maven/artifact/ant/antlib.xml
> [artifact:dependencies] Loading Maven settings file:
> C:\dev\tools\maven\conf\settings.xml
> [artifact:dependencies] Maven Ant Tasks version: 2.0.9
> [artifact:dependencies] Using local repository: C:\repository
> [artifact:dependencies] There were no dependencies specified
> [artifact:dependencies] Resolving dependencies...
> [artifact:dependencies] Using remote repositories:
> - id=central, url=http://repo1.maven.org/maven2, releases=enabled,
> snapshots=disabled, proxy=10.106.42.46
> - id=central, url=http://repo1.maven.org/maven2, releases=enabled,
> snapshots=disabled, proxy=10.106.42.46
> org.apache.maven:super-pom:jar:2.0 (selected)
> [artifact:pom] Using remote repositories:
> - id=central, url=http://repo1.maven.org/maven2, releases=enabled,
> snapshots=disabled
> [artifact:install] [INFO] Installing
> C:\dev\enterprise-ws\dist\client-es-2.0.12.jar to
> c:\repository\...\enterprise-ws-client\1.1-SNAPSHOT\enterprise-ws-client-1.1-SNAPSHOT.jar
> [artifact:pom] Using remote repositories:
> - id=central, url=http://repo1.maven.org/maven2, releases=enabled,
> snapshots=disabled
> [echo] installing pom
> BUILD FAILED
> C:\dev\enterprise-ws\build.xml:231: java.lang.NullPointerException
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at org.apache.tools.ant.Target.performTasks(Target.java:385)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at
> org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
> at
> org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423)
> at
> org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137)
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:71)
> at
> org.apache.maven.artifact.ant.InstallTask.doExecute(InstallTask.java:62)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> 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.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
> ... 10 more
> --- Nested Exception ---
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:71)
> at
> org.apache.maven.artifact.ant.InstallTask.doExecute(InstallTask.java:62)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> 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.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.
[jira] Created: (MANTTASKS-116) NPE if installing pom with type pom
NPE if installing pom with type pom
---
Key: MANTTASKS-116
URL: http://jira.codehaus.org/browse/MANTTASKS-116
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Reporter: Antony Stubbs
{code}
maven-repo-install:
parsing buildfile
jar:file:/C:/dev/tools/maven-ant-tasks-lib/maven-ant-tasks-2.0.9.jar!/org/apache/maven/artifact/ant/antlib.xml
with URI =
jar:file:/C:/dev/tools/maven-ant-tasks-lib/maven-ant-tasks-2.0.9.jar!/org/apache/maven/artifact/ant/antlib.xml
[artifact:dependencies] Loading Maven settings file:
C:\dev\tools\maven\conf\settings.xml
[artifact:dependencies] Maven Ant Tasks version: 2.0.9
[artifact:dependencies] Using local repository: C:\repository
[artifact:dependencies] There were no dependencies specified
[artifact:dependencies] Resolving dependencies...
[artifact:dependencies] Using remote repositories:
- id=central, url=http://repo1.maven.org/maven2, releases=enabled,
snapshots=disabled, proxy=10.106.42.46
- id=central, url=http://repo1.maven.org/maven2, releases=enabled,
snapshots=disabled, proxy=10.106.42.46
org.apache.maven:super-pom:jar:2.0 (selected)
[artifact:pom] Using remote repositories:
- id=central, url=http://repo1.maven.org/maven2, releases=enabled,
snapshots=disabled
[artifact:install] [INFO] Installing
C:\dev\enterprise-ws\dist\client-es-2.0.12.jar to
c:\repository\...\enterprise-ws-client\1.1-SNAPSHOT\enterprise-ws-client-1.1-SNAPSHOT.jar
[artifact:pom] Using remote repositories:
- id=central, url=http://repo1.maven.org/maven2, releases=enabled,
snapshots=disabled
[echo] installing pom
BUILD FAILED
C:\dev\enterprise-ws\build.xml:231: java.lang.NullPointerException
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at
org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423)
at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137)
Caused by: java.lang.NullPointerException
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:71)
at
org.apache.maven.artifact.ant.InstallTask.doExecute(InstallTask.java:62)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
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.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
... 10 more
--- Nested Exception ---
java.lang.NullPointerException
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:71)
at
org.apache.maven.artifact.ant.InstallTask.doExecute(InstallTask.java:62)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
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.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at
org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
at org.apache.tools.ant.Project.executeTargets(Project.ja
[jira] Commented: (SUREFIRE-511) Proposal to use java Map for surefire's systemProperties
[ http://jira.codehaus.org/browse/SUREFIRE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144888#action_144888 ] Dan Tran commented on SUREFIRE-511: --- Given no object on the switch, I'd like to go head with commit together with doc and integration in the next few days. I can use it with build-helper 1.2's new reserve port feature. > Proposal to use java Map for surefire's systemProperties > - > > Key: SUREFIRE-511 > URL: http://jira.codehaus.org/browse/SUREFIRE-511 > Project: Maven Surefire > Issue Type: Improvement > Components: plugin >Affects Versions: 2.4.3 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 2.5 > > Attachments: SUREFIRE-511.patch > > > There is a known problem documented at > http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html > where maven properties other than java String are not able to pass into > surefire > This is mainly because systemProperties is mapped to java Properties class. > However if we map it to java Map > the problem solves. > see > http://svn.codehaus.org/mojo/trunk/mojo/build-helper-maven-plugin/src/it/surefire > for details. > So I would like to propose that we deprecate "systemProperties" and introduce > a new one "systemPropertyVariables" to use java Map ( similar to surefire's > environmentVariables" > Thoughts? -- 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-2174) Synchronizing the org.kohsuke repository to central
Synchronizing the org.kohsuke repository to central
---
Key: MAVENUPLOAD-2174
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2174
Project: Maven Upload Requests
Issue Type: Wish
Reporter: Kohsuke Kawaguchi
The CVS entry for the sync:
{noformat}
"org.kohsuke","rsync://wsinterop.sun.com/maven2-kohsuke","rsync","Kohsuke
Kawaguchi","[EMAIL PROTECTED]",,
{noformat}
The proof of the ownership of the domain can be confirmed by visiting
http://www.kohsuke.org/ which shows my 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] Commented: (MINVOKER-51) NPE when packaging is pom
[
http://jira.codehaus.org/browse/MINVOKER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144887#action_144887
]
Benjamin Bentmann commented on MINVOKER-51:
---
To run the ITs, you only need to activate the profile "run-its" like this:
{{mvn clean verify -P run-its}}. I will have a closer look later this day, but
thanks so far!
> NPE when packaging is pom
> -
>
> Key: MINVOKER-51
> URL: http://jira.codehaus.org/browse/MINVOKER-51
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.2.1
> Environment: Linux x86_64, Java 1.6, Maven 2.0.9
>Reporter: Peter Janes
> Attachments: invoker.patch
>
>
> The invoker plugin appears to have the same issue as reported in MAPPASM-13
> when run on a project with packaging = pom:
> INFO]
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:71)
> at
> org.apache.maven.plugin.invoker.InstallMojo.installProjectArtifacts(InstallMojo.java:178)
> at
> org.apache.maven.plugin.invoker.InstallMojo.execute(InstallMojo.java:119)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> [rest of trace snipped]
> I haven't been able to figure out how to include my test case so that it's
> automatically executed, but it's in the patch file: "mvn install" in
> src/it/pom-packaging fails before the patch and passes after.
--
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-132) "Class not found" when run/debug JUnit tests
[ http://jira.codehaus.org/browse/MECLIPSE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144885#action_144885 ] Antony Stubbs commented on MECLIPSE-132: Wow - I was about to stress out when this started happening to me - found this issue as number one google hit for "eclipse maven class not found" and thankfully, the work around of: "In the project containing your tests, edit Java Build Path | Order and Export: Make sure M2 Dependencies appears BEFORE JRE System Library." works! How on earth did you figure out the work around??? I actually changed to order in the _project my junits depended on_, not the project which contained my tests! I didn't try it the other way around. woah that's weird. ok, tried to try it the other way around, and after putting maven dependencies to _last_ again, the problem didn't reoccur! even after a clean! hmmm... Perhaps it's an eclipse bug? I'm on 3.4. > "Class not found" when run/debug JUnit tests > > > Key: MECLIPSE-132 > URL: http://jira.codehaus.org/browse/MECLIPSE-132 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path, M2Eclipse > support > Environment: gentoo linux 2006, kernel 2.6, sun-jdk-1.5.0.06, maven > 2.0.4, eclipse sdk 3.2, myeclipse 5 m2 >Reporter: Diego Ballve > Attachments: maven-sample.zip > > > This is for the behavior described in > http://www.nabble.com/Keep-getting-%22Class-not-found%22-when-running-debugging-JUnit-tests-tf1851758.html#a5442440 > You get "Class not found" when running/debuging JUnit tests. > For me it happened when I was importing another project and its dependencies > (both m2 projects). > Clean compile works fine, problem is with run. > The workaround to get it working is: > In the project containing your tests, edit Java Build Path | Order and > Export: Make sure M2 Dependencies appears BEFORE JRE System Library. > Thanks, > Diego -- 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: (MINVOKER-51) NPE when packaging is pom
NPE when packaging is pom - Key: MINVOKER-51 URL: http://jira.codehaus.org/browse/MINVOKER-51 Project: Maven 2.x Invoker Plugin Issue Type: Bug Affects Versions: 1.2.1 Environment: Linux x86_64, Java 1.6, Maven 2.0.9 Reporter: Peter Janes Attachments: invoker.patch The invoker plugin appears to have the same issue as reported in MAPPASM-13 when run on a project with packaging = pom: INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:71) at org.apache.maven.plugin.invoker.InstallMojo.installProjectArtifacts(InstallMojo.java:178) at org.apache.maven.plugin.invoker.InstallMojo.execute(InstallMojo.java:119) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) [rest of trace snipped] I haven't been able to figure out how to include my test case so that it's automatically executed, but it's in the patch file: "mvn install" in src/it/pom-packaging fails before the patch and passes after. -- 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-3703) ExecutionProject contains relative paths in compileSourceRoots
[ http://jira.codehaus.org/browse/MNG-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3703. --- Resolution: Fixed > ExecutionProject contains relative paths in compileSourceRoots > -- > > Key: MNG-3703 > URL: http://jira.codehaus.org/browse/MNG-3703 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, POM >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.10 > > -- 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-3705) Expression: ${executedProject} doesn't work in reports
[
http://jira.codehaus.org/browse/MNG-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3705.
---
Resolution: Fixed
verification is currently contained in the integration test for MNG-3703
> Expression: ${executedProject} doesn't work in reports
> --
>
> Key: MNG-3705
> URL: http://jira.codehaus.org/browse/MNG-3705
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, Sites & Reporting
>Affects Versions: 2.0.9, 2.0.10
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.0.10
>
>
> Found while investigating MNG-3703
> It seems that $\{executedProject} relies on project.setExecutionProject(..)
> having been called, which is not the case at the time when the report is
> instantiated.
--
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-3705) Expression: ${executedProject} doesn't work in reports
[
http://jira.codehaus.org/browse/MNG-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3705:
Fix Version/s: 2.0.10
> Expression: ${executedProject} doesn't work in reports
> --
>
> Key: MNG-3705
> URL: http://jira.codehaus.org/browse/MNG-3705
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, Sites & Reporting
>Affects Versions: 2.0.9, 2.0.10
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.0.10
>
>
> Found while investigating MNG-3703
> It seems that $\{executedProject} relies on project.setExecutionProject(..)
> having been called, which is not the case at the time when the report is
> instantiated.
--
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-3705) Expression: ${executedProject} doesn't work in reports
Expression: ${executedProject} doesn't work in reports
--
Key: MNG-3705
URL: http://jira.codehaus.org/browse/MNG-3705
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle, Sites & Reporting
Affects Versions: 2.0.9, 2.0.10
Reporter: John Casey
Fix For: 2.0.10
Found while investigating MNG-3703
It seems that $\{executedProject} relies on project.setExecutionProject(..)
having been called, which is not the case at the time when the report is
instantiated.
--
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] Work started: (MNG-3705) Expression: ${executedProject} doesn't work in reports
[
http://jira.codehaus.org/browse/MNG-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-3705 started by John Casey.
> Expression: ${executedProject} doesn't work in reports
> --
>
> Key: MNG-3705
> URL: http://jira.codehaus.org/browse/MNG-3705
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, Sites & Reporting
>Affects Versions: 2.0.9, 2.0.10
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.0.10
>
>
> Found while investigating MNG-3703
> It seems that $\{executedProject} relies on project.setExecutionProject(..)
> having been called, which is not the case at the time when the report is
> instantiated.
--
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] Work started: (MNG-3703) ExecutionProject contains relative paths in compileSourceRoots
[ http://jira.codehaus.org/browse/MNG-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3703 started by John Casey. > ExecutionProject contains relative paths in compileSourceRoots > -- > > Key: MNG-3703 > URL: http://jira.codehaus.org/browse/MNG-3703 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, POM >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.10 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3703) ExecutionProject contains relative paths in compileSourceRoots
[ http://jira.codehaus.org/browse/MNG-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey reopened MNG-3703: - This is still happening for reports that execute a forked lifecycle. The executedProject contains non-concrete values. > ExecutionProject contains relative paths in compileSourceRoots > -- > > Key: MNG-3703 > URL: http://jira.codehaus.org/browse/MNG-3703 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, POM >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.10 > > -- 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-3704) NPE in DefaultLIfecycleExecutor when run from within Hudson builds
[
http://jira.codehaus.org/browse/MNG-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3704.
---
Resolution: Fixed
> NPE in DefaultLIfecycleExecutor when run from within Hudson builds
> --
>
> Key: MNG-3704
> URL: http://jira.codehaus.org/browse/MNG-3704
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.10
>Reporter: John Casey
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.0.10
>
>
> {noformat}
> [INFO] [clean:clean]
> [HUDSON] Archiving /home/j2ee-hudson/.hudson/jobs/CXF/workspace/trunk/pom.xml
> to
> /home/j2ee-hudson/.hudson/jobs/CXF/modules/org.apache.cxf$cxf/builds/2008-08-11_16-49-47/archive/org.apache.cxf/cxf/2.1.2-SNAPSHOT/pom.xml
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.restoreDynamicState(DefaultLifecycleExecutor.java:779)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:636)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:533)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:364)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:325)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:176)
> at
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:42)
> 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:302)
> 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:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at hudson.maven.agent.Main.launch(Main.java:133)
> at hudson.maven.MavenBuilder.call(MavenBuilder.java:135)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:536)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:482)
> at hudson.remoting.UserRequest.perform(UserRequest.java:69)
> at hudson.remoting.UserRequest.perform(UserRequest.java:23)
> at hudson.remoting.Request$2.run(Request.java:206)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144847#action_144847
]
Benjamin Bentmann commented on MJAVADOC-212:
Considering the penalty of the forked lifecycles during the site generation of
*every* module caused by "@aggregator" on the new mojos, I would however assume
that people will sooner than later user {{}} to disable them from
running in child modules.
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
> Attachments: javadoc-aggregation.patch, MJAVADOC-212.patch
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144846#action_144846
]
bentmann edited comment on MJAVADOC-212 at 8/12/08 1:44 PM:
-
Another idea: Currently, the parameter "aggregate" controls the aggregation
behavior of say "javadoc:javadoc". However, this is not reliable, proper
aggregation also requires to collectively fork all projects in the reactor.
This can only be achieved via the "@aggregator" mojo annotation. So I believe
the natural solution is to query the existence of this annotation whereever the
code now checks the "aggregate" parameter. Hence, I added a new method
{{isAggregator()}} that mojos override to report their aggregating behavior.
The existing parameter "aggregate" is kept only for convenience during the site
lifecycle. The implementation of {{canGenerateReport()}} will skip those
reports whose aggregator flag doesn't match the value specified by the user via
"aggregate". This should allow to run either {{JavadocReport}} or
{{AggregateJavadocReport}} without the need for {{}}. The parameter
is ignored when the mojos are invoked via cli or build lifecycle, i.e. "mvn
javadoc:javadoc -Daggregate=true" will no longer produce aggregated output.
Instead, users should call "mvn javadoc:aggregate". That's a break, but I
believe that's the only correct way in terms of proper aggregation.
I haven't tested this yet, it's merely a sketch for discussion.
was (Author: bentmann):
Another idea: Currently, the parameter "aggregate" controls the aggregation
behavior of say "javadoc:javadoc". However, this is not reliable, proper
aggregation also requires to collectively fork all projects in the reactor.
This can only be achieved via the "@aggregator" mojo annotation. So I believe
the natural solution is to query the existence of this annotation whereever the
code now checks the "aggregate" parameter. Hence, I added a new method
{{isAggregator()}} that mojos override to report their aggregating behavior.
The existing parameter "aggregate" is kept only for convenience during the site
lifecycle. The implementation of {{canGenerateReport()}} will skip those
reports whose aggregator flag doesn't match the value specified by the user via
"aggregate". This should allow to run either {{JavadocReport}} or
{{AggregateJavadocReport}} without the need for {{}}.
I haven't tested this yet, it's merely a sketch for discussion.
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
> Attachments: javadoc-aggregation.patch, MJAVADOC-212.patch
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MJAVADOC-212:
---
Attachment: javadoc-aggregation.patch
Another idea: Currently, the parameter "aggregate" controls the aggregation
behavior of say "javadoc:javadoc". However, this is not reliable, proper
aggregation also requires to collectively fork all projects in the reactor.
This can only be achieved via the "@aggregator" mojo annotation. So I believe
the natural solution is to query the existence of this annotation whereever the
code now checks the "aggregate" parameter. Hence, I added a new method
{{isAggregator()}} that mojos override to report their aggregating behavior.
The existing parameter "aggregate" is kept only for convenience during the site
lifecycle. The implementation of {{canGenerateReport()}} will skip those
reports whose aggregator flag doesn't match the value specified by the user via
"aggregate". This should allow to run either {{JavadocReport}} or
{{AggregateJavadocReport}} without the need for {{}}.
I haven't tested this yet, it's merely a sketch for discussion.
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
> Attachments: javadoc-aggregation.patch, MJAVADOC-212.patch
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MJAVADOC-212:
-
Attachment: MJAVADOC-212.patch
Proposed patch.
By default, AggregatorJavadocReport/AggregatorTestJavadocReport will never be
called at least aggregator parameter is specified.
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
> Attachments: MJAVADOC-212.patch
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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-512) Provided Properties no longer visible in Surefire-Tests
[
http://jira.codehaus.org/browse/SUREFIRE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144821#action_144821
]
Benjamin Bentmann commented on SUREFIRE-512:
This change was introduced to fix SUREFIRE-491.
You could try a configuration like the following to achieve your goal
{code:xml}
my.environment
${my.environment}
{code}
i.e. use Surefire's {{systemProperties}} parameter to explicitly pass
properties through to the tests.
> Provided Properties no longer visible in Surefire-Tests
> ---
>
> Key: SUREFIRE-512
> URL: http://jira.codehaus.org/browse/SUREFIRE-512
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: maven 2.0.9, windows xp, surefire-plugin 2.4.3
>Reporter: Jerome Waibel
>
> I have a super pom and several modules with code and tests. I run the super
> pom with some commandline like
> mvn -Dmy.environment=foo test
> which calls all tests in the modules.
> In the tests I refer to the goven property (by using spring's property
> placeholder). Up to surefire 2.4.2 all tests ran fine, since 2.4.3 the
> property isn't visible any more in the tests (${my.environment} is simply
> unknown).
--
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: (SUREFIRE-512) Provided Properties no longer visible in Surefire-Tests
Provided Properties no longer visible in Surefire-Tests
---
Key: SUREFIRE-512
URL: http://jira.codehaus.org/browse/SUREFIRE-512
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4.3
Environment: maven 2.0.9, windows xp, surefire-plugin 2.4.3
Reporter: Jerome Waibel
I have a super pom and several modules with code and tests. I run the super pom
with some commandline like
mvn -Dmy.environment=foo test
which calls all tests in the modules.
In the tests I refer to the goven property (by using spring's property
placeholder). Up to surefire 2.4.2 all tests ran fine, since 2.4.3 the property
isn't visible any more in the tests (${my.environment} is simply unknown).
--
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: (ARCHETYPE-199) Missing archetypes for Struts2
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144812#action_144812 ] Lukasz Lenart commented on ARCHETYPE-199: - When I am using the latest version of this plugin, everything is working ok, mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-3:generate also when I removed the maven-archetype-plugin from my local repo and relaunch the mvn archetype:generate, maven download the latest version of maven-archetype-plugin and once again, everything is ok. I think, the case can be closed. Regards - Lukasz http://www.lenart.org.pl/ > Missing archetypes for Struts2 > -- > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- 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: (ARCHETYPE-199) Missing archetypes for Struts2
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144811#action_144811 ] Wendy Smoak commented on ARCHETYPE-199: --- I'm not sure where the list in the archetype plugin is coming from, but I removed any archetype that was coming from the ASF snapshot repo from the wiki page. http://docs.codehaus.org/display/MAVENUSER/Archetypes+List > Missing archetypes for Struts2 > -- > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- 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: (ARCHETYPE-199) Missing archetypes for Struts2
Missing archetypes for Struts2 -- Key: ARCHETYPE-199 URL: http://jira.codehaus.org/browse/ARCHETYPE-199 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-1 Environment: Maven version: 2.0.9 Java version: 1.6.0_03 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: Lukasz Lenart All archetypes to generate Struts2 application are missing from repo http://people.apache.org/repo/m2-snapshot-repository/ but are still listed when you launch mvn archetype:create I think, they should be temporally removed from list till there be final release. Regards -- Lukasz http://www.lenart.org.pl/ -- 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-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144792#action_144792
]
Vincent Siveton commented on MJAVADOC-212:
--
A solution could be to move the aggregate parameter into
AggregatorJavadocReport/AggregatorTestJavadocReport or to create a new
parameter, like aggregator, only for these mojos.
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144786#action_144786
]
Vincent Siveton commented on MJAVADOC-212:
--
In fact, I noticed some warn like the following:
{noformat}
[INFO] Skipped "JavaDocs" report, file "apidocs/index.html" already exists for
the English version.
{noformat}
So, AggregatorJavadocReport and JavadocReport are both used. It is normal IMHO
since the PluginManager invokes all MavenReport.
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144785#action_144785
]
Vincent Siveton commented on MJAVADOC-212:
--
To reproduce it, go to plugin-tools or plugin-testing and run:
{noformat}
plugin-tools>mvn clean site:stage -DstagingDirectory=C:\target -X -Ddebug
-Preporting
{noformat}
You will see an empty maven-plugin-tools-api\apidocs\index.html or
maven-plugin-tools-api\testapidocs\index.html
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
[
http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MJAVADOC-212:
-
Fix Version/s: 2.5
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
> aggregator and no reports are generated
> --
>
> Key: MJAVADOC-212
> URL: http://jira.codehaus.org/browse/MJAVADOC-212
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vincent Siveton
>Priority: Critical
> Fix For: 2.5
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
> used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
> if ( aggregate && !project.isExecutionRoot() )
> {
> return;
> }
> {code}
> the report is skipped.
--
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: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in
aggregator and no reports are generated
--
Key: MJAVADOC-212
URL: http://jira.codehaus.org/browse/MJAVADOC-212
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Vincent Siveton
Priority: Critical
Fix For: 2.5
In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are
used by default. Due to the following in the code,
{code:title=AbstractJavadocMojo.java|borderStyle=solid}
if ( aggregate && !project.isExecutionRoot() )
{
return;
}
{code}
the report is skipped.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-133) JavaMojoDescriptorExtractor doesn't handle @requiresReport
[ http://jira.codehaus.org/browse/MPLUGIN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPLUGIN-133. --- Resolution: Fixed fixed in [r684956|http://svn.apache.org/viewvc?rev=684956&view=rev] > JavaMojoDescriptorExtractor doesn't handle @requiresReport > -- > > Key: MPLUGIN-133 > URL: http://jira.codehaus.org/browse/MPLUGIN-133 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Java Plugins >Affects Versions: 2.4.2 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.4.3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-134) Review the support of Mojo's annotations
[ http://jira.codehaus.org/browse/MPLUGIN-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPLUGIN-134. --- Resolution: Fixed Fix Version/s: 2.4.3 > Review the support of Mojo's annotations > > > Key: MPLUGIN-134 > URL: http://jira.codehaus.org/browse/MPLUGIN-134 > Project: Maven 2.x Plugin Tools > Issue Type: Sub-task >Reporter: Vincent Siveton > Fix For: 2.4.3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-133) JavaMojoDescriptorExtractor doesn't handle @requiresReport
[
http://jira.codehaus.org/browse/MPLUGIN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144782#action_144782
]
Vincent Siveton commented on MPLUGIN-133:
-
bq. From your commit, I guess this meant "@requiresReports"
Yes thanks to rename the issue ;)
bq. Final note: This annotation shouldn't be strictly necessary, since the
corresponding flag is automatically set upon detection of a mojo parameter
initialized with the expression "${reports}" (near line 508).
I am aware about it. IMHO the specs [1] specify this annotation, so we need to
be consistent.
[1]
http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations
> JavaMojoDescriptorExtractor doesn't handle @requiresReport
> --
>
> Key: MPLUGIN-133
> URL: http://jira.codehaus.org/browse/MPLUGIN-133
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Java Plugins
>Affects Versions: 2.4.2
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 2.4.3
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-42) checkstyle does not take into account proxy settings from settings.xml
[ http://jira.codehaus.org/browse/MCHECKSTYLE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144776#action_144776 ] Stephen Connolly commented on MCHECKSTYLE-42: - It makes publishing a org.codehaus.mojo plugin project site from behind a proxy very difficult > checkstyle does not take into account proxy settings from settings.xml > -- > > Key: MCHECKSTYLE-42 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-42 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Feniks Nator > > I've been hesitating wether to report it as bug or as improvement, but at the > moment I'd rate it as a bug. > It took me quite some time to figure out why this was going wrong. > In my settings.xml I've defined our company proxysettings. These settings are > used by Maven when connecting to the remote repository. > However when using the checkstyle plugin as part of the site generation I can > not obtain our checkstyle.xml which is available via http. > I found a solution by adding the following parameters on the command line > when continuum launches maven: > -Dhttp.proxyHost=myproxy -Dhttp.proxyPort=80 > Wouldn't it be possible for the maven checkstyle plugin to use the settings > defined in settings.xml, so I've only to define those once? > FYI the error generated: > [INFO] Generate "Dependencies" report. > [INFO] Generate "Issue Tracking" report. > [INFO] Generate "Project License" report. > [INFO] Generate "Mailing Lists" report. > [INFO] Generate "Source Repository" report. > [INFO] Generate "Project Team" report. > [INFO] Generate "Maven Surefire Report" report. > [INFO] Generate "Checkstyle" report. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error during report generation > Embedded error: Unable to find configuration file location. > http://spirou.mycompany.be/javadev/install/checkstyle/mycompany-checkstyle-1.5.xml > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error during report > generation > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during > report generation > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:389) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.reporting.MavenReportException: Unable to find > configuration file location. > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.getConfigFile(CheckstyleReport.java:879) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:466) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:802) > at o
[jira] Commented: (MPLUGIN-133) JavaMojoDescriptorExtractor doesn't handle @requiresReport
[
http://jira.codehaus.org/browse/MPLUGIN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144773#action_144773
]
Benjamin Bentmann commented on MPLUGIN-133:
---
Final note: This annotation shouldn't be strictly necessary, since the
corresponding flag is automatically set upon detection of a mojo parameter
initialized with the expression "${reports}" (near line 508).
> JavaMojoDescriptorExtractor doesn't handle @requiresReport
> --
>
> Key: MPLUGIN-133
> URL: http://jira.codehaus.org/browse/MPLUGIN-133
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Java Plugins
>Affects Versions: 2.4.2
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 2.4.3
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPLUGIN-133) JavaMojoDescriptorExtractor doesn't handle @requiresReport
[ http://jira.codehaus.org/browse/MPLUGIN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MPLUGIN-133: -- Summary: JavaMojoDescriptorExtractor doesn't handle @requiresReport (was: JavaMojoDescriptorExtractor doesn't handle @requiresProject ) >From your commit, I guess this meant "@requiresReports" ;-) > JavaMojoDescriptorExtractor doesn't handle @requiresReport > -- > > Key: MPLUGIN-133 > URL: http://jira.codehaus.org/browse/MPLUGIN-133 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Java Plugins >Affects Versions: 2.4.2 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.4.3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-133) JavaMojoDescriptorExtractor doesn't handle @requiresProject
[
http://jira.codehaus.org/browse/MPLUGIN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144768#action_144768
]
Benjamin Bentmann commented on MPLUGIN-133:
---
You're sure? Near line 301 it says
{code:java}
// Project flag
boolean value =
getBooleanTagValue( javaClass, JavaMojoAnnotation.REQUIRES_PROJECT,
mojoDescriptor.isProjectRequired() );
mojoDescriptor.setProjectRequired( value );
{code}
> JavaMojoDescriptorExtractor doesn't handle @requiresProject
>
>
> Key: MPLUGIN-133
> URL: http://jira.codehaus.org/browse/MPLUGIN-133
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Java Plugins
>Affects Versions: 2.4.2
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 2.4.3
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-327) Using filtered within dependencySet unpackOptions
[
http://jira.codehaus.org/browse/MASSEMBLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144766#action_144766
]
gotama commented on MASSEMBLY-327:
--
In analyzing the Maven Assembly Plugin code base, from what I can see, the
tag (child of ) is not supported.
Please look at AddDependencySetsTask:170:
UnpackOptions opts = dependencySet.getUnpackOptions();
if ( dependencySet.isUnpack() && ( opts != null ) )
{
task.setIncludes( opts.getIncludes() );
task.setExcludes( opts.getExcludes() );
}
It does not appear that Maven Assembly Plugin actually supports the
tag given this piece of code which ignores the option.
Further, the UnpackOptions.java isFiltered() method is not referenced in the
Maven Assembly Plugin code base.
The documentation shows that supports the ,
which contains the option.
If supports , it should support all three
options; includes, excludes AND filtered - not just two of them.
This is partially implemented support for UnpackOptions. When could we see this
completed? Would be appreciated. Thanks.
> Using filtered within dependencySet unpackOptions
> -
>
> Key: MASSEMBLY-327
> URL: http://jira.codehaus.org/browse/MASSEMBLY-327
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Andy Yeung
>
> The files within the unpacked jar did not apply the filters defined.
> pom configuration includes
>
>
>
> src/assemble/filter.properties
>
>
> which contains
>storage.id=abcde
> assembly.xml defines dependency set
>
> /snp-agent1
> true
>
> true
>
> runtime
>
>
> XXX.agent:agent-ear-config
>
>
>
> However, the files within are not filtered.
--
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
