[jira] Commented: (MCOMPILER-66) Compiler swallows messages from annotation processors
[ http://jira.codehaus.org/browse/MCOMPILER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228789#action_228789 ] David Boden commented on MCOMPILER-66: -- Adding true to my compiler plugin results in: * The Kind.NOTE print statements being output as [ERROR] * Without the showWarnings, the statements don't get printed. * The build fails (it succeeds when showWarnings=false), probably because the NOTE messages have been artificially raised to ERROR level and Maven is interpreting this as a build failure? I'm using: maven-compiler-plugin 2.3.1 I'm building this project: http://immutablebean.googlecode.com/svn/ImmutableBeanExample Hopefully you'll be able to check out this project, build it and change the to recreate this error at will. Here's the output I get with showWarnings=true: [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \Users\Dave\workspace\ImmutableBeanExample\src\main\java\org\immutablebean\beantemplates\BeanInterfaceTemplate.java:[14,21] Note: Identified bean property: identifier [ERROR] \Users\Dave\workspace\ImmutableBeanExample\src\main\java\org\immutablebean\beantemplates\BeanInterfaceTemplate.java:[15,18] Note: Identified bean property: version [ERROR] \Users\Dave\workspace\ImmutableBeanExample\src\main\java\org\immutablebean\beantemplates\BeanInterfaceTemplate.java:[16,6] Note: Identified bean property: creationDate [ERROR] \Users\Dave\workspace\ImmutableBeanExample\src\main\java\org\immutablebean\beantemplates\BeanInterfaceTemplate.java:[17,12] Note: Identified bean property: price [ERROR] \Users\Dave\workspace\ImmutableBeanExample\src\main\java\org\immutablebean\beantemplates\BeanInterfaceTemplate.java:[18,12] Note: Identified bean property: quantity > Compiler swallows messages from annotation processors > - > > Key: MCOMPILER-66 > URL: http://jira.codehaus.org/browse/MCOMPILER-66 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2, 2.1 >Reporter: Evan Cowden > Attachments: AnnotationProcessorMessagerBug.zip > > > When using the annotation processor API to print messages through the > javax.annotation.processing.Messager object, only messagesspecified by levels > javax.tools.Diagnostic.Kind.ERROR and > javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the > build to fail). All other messages are swallowed. > Note that while the attached JUnit test case is necessary to help expose the > problem, passing it will not imply that the bug is fixed. The only way to > confirm the fix (that I know of) is to examine console output. -- 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: (MRELEASE-150) Can't add prefix to tags without affecting version
[
http://jira.codehaus.org/browse/MRELEASE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228782#action_228782
]
hanasaki commented on MRELEASE-150:
---
Could this be made more generic allowing for SVN and GIT versions as well?
ex: blahblah-v1.2.0-r756.jar
> Can't add prefix to tags without affecting version
> --
>
> Key: MRELEASE-150
> URL: http://jira.codehaus.org/browse/MRELEASE-150
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-4
>Reporter: Yuri Schimke
>Priority: Minor
> Attachments: release-manager-patch.patch
>
>
> I added the following to my POM
>
> maven-release-plugin
>
> XXX-${artifactId}-${version}
>
>
> However the tag comes out incorrectly.
> [INFO] Full run would be tagging C:\PerforceViews\... with label:
> 'XXX-myproject-0.5.4-SNAPSHOT
> What is the default? ${artifactId}-${version}
> Note: this seems to be missing from the plugin documentation, it only
> mentions releaseLabel, which defaults to tag.
--
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: (MPIR-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228754#action_228754 ] Prashant Bhate commented on MPIR-150: -- Hi, Raised http://jira.codehaus.org/browse/MPIR-199 Cheers, Prashant Bhate > the dependency report ignores mirrors > - > > Key: MPIR-150 > URL: http://jira.codehaus.org/browse/MPIR-150 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1.1 >Reporter: Brian Fox >Assignee: Olivier Lamy > Fix For: 2.2 > > Attachments: MPIR-150.patch > > > The dependencies report takes forever and running debug i can see it's > hitting the same repos over and over and bypassing my repository manager. -- 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: (MPIR-199) ProjectInfoReportUtils.java : Avoid using blocking call [ url.openStream() ] while opening stream from an URL
ProjectInfoReportUtils.java : Avoid using blocking call [ url.openStream() ]
while opening stream from an URL
-
Key: MPIR-199
URL: http://jira.codehaus.org/browse/MPIR-199
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.2, 2.1.2, 2.1.1
Environment: any, with no internet connectivity [=~ intranet , behind
proxy etc.. ]
Reporter: Prashant Bhate
This issue is related to http://jira.codehaus.org/browse/MPIR-150
it would be nice if {{url.openStream();}}
from
{code:title=ProjectInfoReportUtils.java|borderStyle=solid}
InputStream in =null;
try
{
in = url.openStream();
{code}
can be replaced with
{code}
//Define constant TIMEOUT with pre set timeout
InputStream in =null;
try
{
URLConnection conn = url.openConnection();
conn.setConnectTimeout(TIMEOUT);
conn.setReadTimeout(TIMEOUT);
in = conn.getInputStream();
{code}
{{url.openStream();}} is a blocking call that makes caller wait forever and
eventually timeouts at the end
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2793) Please upload JCommander 1.0 to the Maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric Beust closed MAVENUPLOAD-2793. - Resolution: Fixed > Please upload JCommander 1.0 to the Maven repository > > > Key: MAVENUPLOAD-2793 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2793 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Cedric Beust > > This is version 1.0 of JCommander, which I created. > Can you please add it to the Maven repository? > Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-122) Setting of in pom.xml is ignored. ArtifactId of a WebModule is set as context-root in the application.xml instead.
[
http://jira.codehaus.org/browse/MEAR-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228745#action_228745
]
Tiago Torres commented on MEAR-122:
---
Stephane, I have a question. If I understood correctly, I can't declare a
maven-ear-plugin section inside a custom profile if I already have this section
in the default profile. Does that mean I can never have a web module dependency
in a custom profile in case I already have a maven-ear-plugin declared in my
default profile? Is there a workaround for this problem?
Thanks,
Tiago
> Setting of in pom.xml is ignored. ArtifactId of a WebModule is
> set as context-root in the application.xml instead.
>
>
> Key: MEAR-122
> URL: http://jira.codehaus.org/browse/MEAR-122
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Environment: Maven 2.0.10
> Windows XP SP3
>Reporter: Armin Wrobel
>Assignee: Stephane Nicoll
> Fix For: 2.4.1
>
> Attachments: ecase.zip, output.log, pom.xml, pom.xml
>
>
> I set in my POM the desired context root of a web module which is to be
> bundled in a EAR file.
> The setting is simply ignored when building the EAR file.
> Instead the artifactId of the web module is used.
> This is the webModule with the ignored contextRoot:
>
> ch.hrms.ecase
> ecase-web
> /ecase
>
> Following is a larger snippet of the POM:
>
> casex-ext
>
>
> ch.hrms.ecase
> ecase-ws
> ${applicationVersion}
> wsr
>
>
> ch.hrms.ecase
> ecase-sunet-ws
> ${applicationVersion}
> war
>
>
> ch.hrms.ecase
> ecase-pdf
> ${applicationVersion}
> sar
>
>
> ch.hrms.ecase
> ecase-web
> ${applicationVersion}
> war
>
>
> ch.hrms.ecase
> rootCtx
> ${applicationVersion}
> war
>
>
>
>
>
> org.apache.maven.plugins
> maven-ear-plugin
>
> eCaseSwica - external
> ecase-swica-ext
>
> eCase for Swica - deployment for external JBoss server
>
>
>
> ch.hrms.ecase
> ecase-ws
>
>
> ch.hrms.ecase
> ecase-sunet-ws
> /sunet/ws/casedata
>
>
> ch.hrms.ecase
> ecase-pdf
>
>
> ch.hrms.ecase
> ecase-web
> /ecase
>
>
> ch.hrms.ecase
> rootCtx
>
>
>
>
>
> org.codehaus.mojo
> jboss-maven-plugin
> 1.4
>
> 8180
> ${JBoss_Ext_Home}
> ecase-ear/target/ecase-swica-ext.ear
>
>
>
>
>
--
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: (MANTTASKS-175) Dependencies ignoring user defined repo location and reverting to central
[
http://jira.codehaus.org/browse/MANTTASKS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-175:
Description:
I have a very simple dependencies declaration:
{code:xml}
{code}
I have 2 mirrors set up:
{code:xml}
all_mirror
Nexus All
http://maven-proxy.mycompany.com/content/groups/all
*,!central
central_mirror
Nexus Releases
http://maven-proxy.mycompany.com/content/groups/public
central
{code}
When I instruct Maven to retreive the dependency it gets the pom file
correctly, which contains a 2nd dependency, which is retrieved. These are both
retrieved from the correct repo. But the 2nd pom then defines another
dependency. But this 3rd dependency is searched for at central, where it doesnt
exist (all artifacts are internal libraries).
{noformat}
Downloading: com/mycompany/myartifact1/version1/artifact1-version1.pom from
repository central_mirror at http://mycompany.com/content/groups/public
Transferring 4K from central_mirror
Downloading: com/mycompany/myartifact2/version2/artifact2-version2.pom from
repository central_mirror at http://mycompany.com/content/groups/public
Transferring 24K from central_mirror
Downloading: com/mycompany/myartifact3/version3/artifact3-version3.pom from
repository central at http://repo1.maven.org/maven2
Error transferring file: Connection timed out: connect
{noformat}
So the first 2 are resolved and d/loaded fine, but the 3rd suddenly reverts to
looking in central, when it is present and correct in the central_mirror repo.
was:
I have a very simple dependencies declaration:
I have 2 mirrors set up:
all_mirror
Nexus All
http://maven-proxy.mycompany.com/content/groups/all
*,!central
central_mirror
Nexus Releases
http://maven-proxy.mycompany.com/content/groups/public
central
When I instruct Maven to retreive the dependency it gets the pom file
correctly, which contains a 2nd dependency, which is retrieved. These are both
retrieved from the correct repo. But the 2nd pom then defines another
dependency. But this 3rd dependency is searched for at central, where it doesnt
exist (all artifacts are internal libraries).
Downloading: com/mycompany/myartifact1/version1/artifact1-version1.pom from
repository central_mirror at http://mycompany.com/content/groups/public
Transferring 4K from central_mirror
Downloading: com/mycompany/myartifact2/version2/artifact2-version2.pom from
repository central_mirror at http://mycompany.com/content/groups/public
Transferring 24K from central_mirror
Downloading: com/mycompany/myartifact3/version3/artifact3-version3.pom from
repository central at http://repo1.maven.org/maven2
Error transferring file: Connection timed out: connect
So the first 2 are resolved and d/loaded fine, but the 3rd suddenly reverts to
looking in central, when it is present and correct in the central_mirror repo.
> Dependencies ignoring user defined repo location and reverting to central
> -
>
> Key: MANTTASKS-175
> URL: http://jira.codehaus.org/browse/MANTTASKS-175
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.0
> Environment: Windows XP
>Reporter: Paul WIlliams
>
> I have a very simple dependencies declaration:
> {code:xml} settingsFile="${app.mavenSettings}">
> version="2.0.0"/>
> {code}
> I have 2 mirrors set up:
> {code:xml}
>
> all_mirror
> Nexus All
> http://maven-proxy.mycompany.com/content/groups/all
> *,!central
>
>
> central_mirror
> Nexus Releases
>
> http://maven-proxy.mycompany.com/content/groups/public
> central
>
> {code}
> When I instruct Maven to retreive the dependency it gets the pom file
> correctly, which contains a 2nd dependency, which is retrieved. These are
> both retrieved from the correct repo. But the 2nd pom then defines another
> dependency. But this 3rd dependency is searched for at central, where it
> doesnt exist (all artifacts are internal libraries).
> {noformat}
> Downloading: com/mycompany/myartifact1/version1/artifact1-version1.pom from
> repository central_mirror at http://mycompany.com/content/groups/public
> Transferring 4K from central_mirror
> Downloading: com/mycompany/myartifact2/versi
[jira] Updated: (MANTTASKS-192) NPE when using remoteRepository with refid which has not been defined
[
http://jira.codehaus.org/browse/MANTTASKS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-192:
Description:
{code:xml}
{code}
causes the following NPE:
{noformat}java.lang.NullPointerException
at
org.apache.maven.artifact.ant.RemoteRepository.getUrl(RemoteRepository.java:43)
at
org.apache.maven.artifact.ant.AbstractArtifactWithRepositoryTask.addConfiguredRemoteRepository(AbstractArtifactWithRepositoryTask.java:139)
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.apache.tools.ant.IntrospectionHelper$AddNestedCreator.istore(IntrospectionHelper.java:1469)
at
org.apache.tools.ant.IntrospectionHelper$AddNestedCreator.store(IntrospectionHelper.java:1463)
at
org.apache.tools.ant.IntrospectionHelper$Creator.store(IntrospectionHelper.java:1370)
at
org.apache.tools.ant.UnknownElement.handleChild(UnknownElement.java:582)
at
org.apache.tools.ant.UnknownElement.handleChildren(UnknownElement.java:349)
at
org.apache.tools.ant.UnknownElement.configure(UnknownElement.java:201)
at
org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
at org.apache.tools.ant.Task.perform(Task.java:347)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
{noformat}
was:
{code:xml}
{code}
causes the following NPE:
{noformat}java.lang.NullPointerException
at
org.apache.maven.artifact.ant.RemoteRepository.getUrl(RemoteRepository.java:43)
at
org.apache.maven.artifact.ant.AbstractArtifactWithRepositoryTask.addConfiguredRemoteRepository(AbstractArtifa
ctWithRepositoryTask.java:139)
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.apache.tools.ant.IntrospectionHelper$AddNestedCreator.istore(IntrospectionHelper.java:1469)
at
org.apache.tools.ant.IntrospectionHelper$AddNestedCreator.store(IntrospectionHelper.java:1463)
at
org.apache.tools.ant.IntrospectionHelper$Creator.store(IntrospectionHelper.java:1370)
at
org.apache.tools.ant.UnknownElement.handleChild(UnknownElement.java:582)
at
org.apache.tools.ant.UnknownElement.handleChildren(UnknownElement.java:349)
at
org.apache.tools.ant.UnknownElement.configure(UnknownElement.java:201)
at
org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
at org.apache.tools.ant.Task.perform(Task.java:347)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
{noformat}
> NPE when using remoteRepository with refid which has not been defined
> -
>
> Key: MANTTASKS-192
> URL: http://jira.codehaus.org/browse/MANTTASKS-192
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.0
>Reporter: SebbASF
>
> {code:xml}
>
> version="1.1.1"/>
> {code}
> causes the following NPE:
> {noformat}java.lang.NullPointerException
>
[jira] Updated: (MANTTASKS-189) NPE when using scope="system"
[
http://jira.codehaus.org/browse/MANTTASKS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-189:
Description:
Using scope="system":
{code:xml}
{code}
causes NPE:
{noformat}java.lang.NullPointerException
at java.io.File.(File.java:222)
at
org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:445)
at
org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTask.java:186)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:721)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
{noformat}
was:
Using scope="system":
causes NPE:
java.lang.NullPointerException
at java.io.File.(File.java:222)
at
org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:445)
at
org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTask.java:186)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:721)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> NPE when using scope="system"
> -
>
> Key: MANTTASKS-189
> URL: http://jira.codehaus.org/browse/MANTTASKS-189
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.0
>Reporter: SebbASF
>
> Using scope="system":
> {code:xml}
> version="1.1.1" scope="system"/>
> {code}
> causes NPE:
> {noformat}java.lang.NullPointerException
> at java.io.File.(File.java:222)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:445)
> at
> org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTask.java:186)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:721)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at
> org.apache.tools.ant.Project.executeSortedTargets
[jira] Updated: (MANTTASKS-192) NPE when using remoteRepository with refid which has not been defined
[
http://jira.codehaus.org/browse/MANTTASKS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-192:
Description:
{code:xml}
{code}
causes the following NPE:
{noformat}java.lang.NullPointerException
at
org.apache.maven.artifact.ant.RemoteRepository.getUrl(RemoteRepository.java:43)
at
org.apache.maven.artifact.ant.AbstractArtifactWithRepositoryTask.addConfiguredRemoteRepository(AbstractArtifa
ctWithRepositoryTask.java:139)
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.apache.tools.ant.IntrospectionHelper$AddNestedCreator.istore(IntrospectionHelper.java:1469)
at
org.apache.tools.ant.IntrospectionHelper$AddNestedCreator.store(IntrospectionHelper.java:1463)
at
org.apache.tools.ant.IntrospectionHelper$Creator.store(IntrospectionHelper.java:1370)
at
org.apache.tools.ant.UnknownElement.handleChild(UnknownElement.java:582)
at
org.apache.tools.ant.UnknownElement.handleChildren(UnknownElement.java:349)
at
org.apache.tools.ant.UnknownElement.configure(UnknownElement.java:201)
at
org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
at org.apache.tools.ant.Task.perform(Task.java:347)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
{noformat}
was:
causes the following NPE:
java.lang.NullPointerException
at
org.apache.maven.artifact.ant.RemoteRepository.getUrl(RemoteRepository.java:43)
at
org.apache.maven.artifact.ant.AbstractArtifactWithRepositoryTask.addConfiguredRemoteRepository(AbstractArtifa
ctWithRepositoryTask.java:139)
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.apache.tools.ant.IntrospectionHelper$AddNestedCreator.istore(IntrospectionHelper.java:1469)
at
org.apache.tools.ant.IntrospectionHelper$AddNestedCreator.store(IntrospectionHelper.java:1463)
at
org.apache.tools.ant.IntrospectionHelper$Creator.store(IntrospectionHelper.java:1370)
at
org.apache.tools.ant.UnknownElement.handleChild(UnknownElement.java:582)
at
org.apache.tools.ant.UnknownElement.handleChildren(UnknownElement.java:349)
at
org.apache.tools.ant.UnknownElement.configure(UnknownElement.java:201)
at
org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
at org.apache.tools.ant.Task.perform(Task.java:347)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> NPE when using remoteRepository with refid which has not been defined
> -
>
> Key: MANTTASKS-192
> URL: http://jira.codehaus.org/browse/MANTTASKS-192
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.0
>Reporter: SebbASF
>
> {code:xml}
>
> version="1.1.1"/>
> {code}
> causes the following NPE:
> {noformat}java.lang.NullPointerException
> at
> org.apache.maven.arti
[jira] Updated: (MANTTASKS-187) maven ant tasks 2.1.0 pom task no longer extrapolates properties
[
http://jira.codehaus.org/browse/MANTTASKS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-187:
Fix Version/s: 2.1.1
Assignee: Herve Boutemy
> maven ant tasks 2.1.0 pom task no longer extrapolates properties
> -
>
> Key: MANTTASKS-187
> URL: http://jira.codehaus.org/browse/MANTTASKS-187
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
>Reporter: Andreas Kohn
>Assignee: Herve Boutemy
> Fix For: 2.1.1
>
>
> Seems to be a regression from 2.0.9, maybe caused by MANTTASKS-153 (?)
> The build.xml:
> {noformat}
>
>
>resource="org/apache/maven/artifact/ant/antlib.xml"/>
>
>
> ${p.build.finalName}
>
>
> {noformat}
> The pom.xml loaded by the build.xml:
> {noformat}
>
> 4.0.0
> com.example
> test
> 1.0-SNAPSHOT
>
> {noformat}
> Running with maven-ant-tasks 2.0.9 gives:
> {noformat}
> $ CLASSPATH=$CLASSPATH:$PWD/maven-ant-tasks-2.0.9.jar ANT_HOME=
> ~/modules/apache-ant-1.7.1/bin/ant
> Buildfile: build.xml
> test:
> [echo] test-1.0-SNAPSHOT
> BUILD SUCCESSFUL
> Total time: 0 seconds
> {noformat}
> Running with maven-ant-tasks 2.1.0 gives:
> {noformat}
> $ CLASSPATH=$CLASSPATH:$PWD/maven-ant-tasks-2.1.0.jar ANT_HOME=
> ~/modules/apache-ant-1.7.1/bin/ant
> Buildfile: build.xml
> test:
> [echo] ${project.artifactId}-${project.version}
> BUILD SUCCESSFUL
> Total time: 1 second
> {noformat}
> This is distilled down from the Apache lucene common-build.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: (MANTTASKS-183) Property not evaluated in pom/project/parent/version
[
http://jira.codehaus.org/browse/MANTTASKS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228737#action_228737
]
Herve Boutemy commented on MANTTASKS-183:
-
there is a good chance that this problem is caused by MANTTASKS-179
MANTTASKS-179 has just been fixed: can you try and report if it fixes this
issue too?
> Property not evaluated in pom/project/parent/version
>
>
> Key: MANTTASKS-183
> URL: http://jira.codehaus.org/browse/MANTTASKS-183
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
> Environment: Ant 1.7.1
>Reporter: Marcin Wisnicki
>
> I'm trying to define parent version in pom by property:
> {code:xml|title=hamcrest-integration.pom}
> http://maven.apache.org/POM/4.0.0";>
> 4.0.0
>
> org.hamcrest
> hamcrest-parent
> ${hamcrest.version}
>
> org.hamcrest
> hamcrest-integration
> ${hamcrest.version}
>
> {code}
> And using something like following in build.xml:
> {code:xml|title=build.xml}
>
>
> {code}
> Unfortunately generated pom (via writepom/install/deploy) has
> {{project.version}} resolved, but {{project.parent.version}} remains
> unresolved.
--
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: (MANTTASKS-173) Value of project.build.finalName is not resolved
[
http://jira.codehaus.org/browse/MANTTASKS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-173.
---
Resolution: Duplicate
Fix Version/s: 2.1.1
Assignee: Herve Boutemy
this is a duplicate of MANTTASKS-179
> Value of project.build.finalName is not resolved
>
>
> Key: MANTTASKS-173
> URL: http://jira.codehaus.org/browse/MANTTASKS-173
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
> Environment: Windows
>Reporter: Claudio Di Vita
>Assignee: Herve Boutemy
> Fix For: 2.1.1
>
>
> If Iuse the pom task in this way:
>
> the value of project.build.finalName is not resolved. If I access to property
> maven.project.build.finalName I only get
> ${project.artifactId}-${project.version}, instead I expect the real value
> (for example, myArtifact-1.0).
> In Maven Ant Tasks 2.0.10 this problem wasn't present.
--
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: (MANTTASKS-179) Variables nested in pom.xml are not being interpolated
[
http://jira.codehaus.org/browse/MANTTASKS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-179:
Summary: Variables nested in pom.xml are not being interpolated (was:
Variables nested in pom.xml are not being resolved)
> Variables nested in pom.xml are not being interpolated
> --
>
> Key: MANTTASKS-179
> URL: http://jira.codehaus.org/browse/MANTTASKS-179
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
>Reporter: Joe Stano
>Assignee: Herve Boutemy
> Fix For: 2.1.1
>
>
> My build project parses a project's pom.xml to expose the data to various ant
> tasks. After parsing the pom.xml, the ant tasks use the normal variable
> syntax such as ${project.build.directory} to dig into the pom's contents.
> The value of this specific element in my project is "${basedir}/target". In
> 2.0.10, the resulting value of this lookup will be fully resolved to the
> project's directory. With 2.1.0, the value resolves to the literal
> "${basedir}/target" and the build fails.
> 2.1.0 failure with a ${project.build.directory} value of "${basedir}\target":
> java.io.FileNotFoundException:
> c:\Projects\ProjectName\${basedir}\target\version.jsp (The system cannot find
> the path specified)
--
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: (MANTTASKS-179) Variables nested in pom.xml are not being resolved
[
http://jira.codehaus.org/browse/MANTTASKS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-179.
---
Resolution: Fixed
Fix Version/s: 2.1.1
Assignee: Herve Boutemy
fixed in [r964525|http://svn.apache.org/viewvc?view=revision&revision=964525]
this bug was introduced when upgrading Maven core dependency from 2.0.x to
2.2.x: interpolation is not automatic any more, it has to be called explicitely
> Variables nested in pom.xml are not being resolved
> --
>
> Key: MANTTASKS-179
> URL: http://jira.codehaus.org/browse/MANTTASKS-179
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
>Reporter: Joe Stano
>Assignee: Herve Boutemy
> Fix For: 2.1.1
>
>
> My build project parses a project's pom.xml to expose the data to various ant
> tasks. After parsing the pom.xml, the ant tasks use the normal variable
> syntax such as ${project.build.directory} to dig into the pom's contents.
> The value of this specific element in my project is "${basedir}/target". In
> 2.0.10, the resulting value of this lookup will be fully resolved to the
> project's directory. With 2.1.0, the value resolves to the literal
> "${basedir}/target" and the build fails.
> 2.1.0 failure with a ${project.build.directory} value of "${basedir}\target":
> java.io.FileNotFoundException:
> c:\Projects\ProjectName\${basedir}\target\version.jsp (The system cannot find
> the path specified)
--
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: (MRELEASE-159) Support a pattern to generate the release tag
[ http://jira.codehaus.org/browse/MRELEASE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228731#action_228731 ] Jeff Skjonsby commented on MRELEASE-159: I've added another patch with unit tests that adds substitution for [groupId], [artifactId] and [version] Example: releases/[version] > Support a pattern to generate the release tag > - > > Key: MRELEASE-159 > URL: http://jira.codehaus.org/browse/MRELEASE-159 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Joerg Schaible > Attachments: MRELEASE-159-PATCH-update.diff.gz, > MRELEASE-159-PATCH.diff.gz, release-manager-patch.patch > > > The release-plugin uses currently the pattern "-" to > create the version tag. A configuration element would be fine to support > different requirements for release tags (in our case "v_", since > with svn the module is already part of the path). -- 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: (MRELEASE-159) Support a pattern to generate the release tag
[ http://jira.codehaus.org/browse/MRELEASE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Skjonsby updated MRELEASE-159: --- Attachment: release-manager-patch.patch > Support a pattern to generate the release tag > - > > Key: MRELEASE-159 > URL: http://jira.codehaus.org/browse/MRELEASE-159 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Joerg Schaible > Attachments: MRELEASE-159-PATCH-update.diff.gz, > MRELEASE-159-PATCH.diff.gz, release-manager-patch.patch > > > The release-plugin uses currently the pattern "-" to > create the version tag. A configuration element would be fine to support > different requirements for release tags (in our case "v_", since > with svn the module is already part of the path). -- 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: (MRELEASE-150) Can't add prefix to tags without affecting version
[
http://jira.codehaus.org/browse/MRELEASE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Skjonsby updated MRELEASE-150:
---
Attachment: release-manager-patch.patch
Here's a patch with unit tests that adds simple substitution for [groupId],
[artifactId], and [version] in the release label.
> Can't add prefix to tags without affecting version
> --
>
> Key: MRELEASE-150
> URL: http://jira.codehaus.org/browse/MRELEASE-150
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-4
>Reporter: Yuri Schimke
>Priority: Minor
> Attachments: release-manager-patch.patch
>
>
> I added the following to my POM
>
> maven-release-plugin
>
> XXX-${artifactId}-${version}
>
>
> However the tag comes out incorrectly.
> [INFO] Full run would be tagging C:\PerforceViews\... with label:
> 'XXX-myproject-0.5.4-SNAPSHOT
> What is the default? ${artifactId}-${version}
> Note: this seems to be missing from the plugin documentation, it only
> mentions releaseLabel, which defaults to tag.
--
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: (MANTTASKS-187) maven ant tasks 2.1.0 pom task no longer extrapolates properties
[
http://jira.codehaus.org/browse/MANTTASKS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-187.
---
Resolution: Duplicate
this is a duplicate of MANTTASKS-179
> maven ant tasks 2.1.0 pom task no longer extrapolates properties
> -
>
> Key: MANTTASKS-187
> URL: http://jira.codehaus.org/browse/MANTTASKS-187
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: pom task
>Affects Versions: 2.1.0
>Reporter: Andreas Kohn
>
> Seems to be a regression from 2.0.9, maybe caused by MANTTASKS-153 (?)
> The build.xml:
> {noformat}
>
>
>resource="org/apache/maven/artifact/ant/antlib.xml"/>
>
>
> ${p.build.finalName}
>
>
> {noformat}
> The pom.xml loaded by the build.xml:
> {noformat}
>
> 4.0.0
> com.example
> test
> 1.0-SNAPSHOT
>
> {noformat}
> Running with maven-ant-tasks 2.0.9 gives:
> {noformat}
> $ CLASSPATH=$CLASSPATH:$PWD/maven-ant-tasks-2.0.9.jar ANT_HOME=
> ~/modules/apache-ant-1.7.1/bin/ant
> Buildfile: build.xml
> test:
> [echo] test-1.0-SNAPSHOT
> BUILD SUCCESSFUL
> Total time: 0 seconds
> {noformat}
> Running with maven-ant-tasks 2.1.0 gives:
> {noformat}
> $ CLASSPATH=$CLASSPATH:$PWD/maven-ant-tasks-2.1.0.jar ANT_HOME=
> ~/modules/apache-ant-1.7.1/bin/ant
> Buildfile: build.xml
> test:
> [echo] ${project.artifactId}-${project.version}
> BUILD SUCCESSFUL
> Total time: 1 second
> {noformat}
> This is distilled down from the Apache lucene common-build.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] Created: (MENFORCER-101) Enforcer does not allow to restrict based on SNAPSHOT version as version comparison uses artifact.getVersion() instead of artifact.getBaseVersion()
Enforcer does not allow to restrict based on SNAPSHOT version as version
comparison uses artifact.getVersion() instead of artifact.getBaseVersion()
---
Key: MENFORCER-101
URL: http://jira.codehaus.org/browse/MENFORCER-101
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-beta-1
Environment: Any
Reporter: Prashant Bhate
When following restriction is given to banned dependency rule, comparison fails
as it compare with actual snapshot version in the repository (which includes
timestamp 1.0-20100715.155142-18 ) instead of base version ( which has
1.0-SNAPSHOT )
{code:xml}
maven-enforcer-plugin
enforce-snapshot-ver
enforce
true
org.apache.maven.enforcer:enforcer-rules
org.apache.maven.enforcer:enforcer-rules:[1.0-beta-2-SNAPSHOT]
true
..
..
..
org.apache.maven.enforcer
enforcer-rules
1.0-beta-2-SNAPSHOT
{code}
See code snippet below
{code:title=BannedDependencies.java|borderStyle=solid}
try
{
result = AbstractVersionEnforcer.containsVersion(
VersionRange.createFromVersionSpec( pattern[2] ),
new DefaultArtifactVersion( artifact.getVersion() )
);
}
catch ( InvalidVersionSpecificationException e )
{
throw new EnforcerRuleException( "Invalid Version Range: ", e );
}
{code}
replace
{code}
new DefaultArtifactVersion( artifact.getVersion() )
{code}
with
{code}
new DefaultArtifactVersion( artifact.getBaseVersion() )
{code}
will solve this issue
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-268) performance problem in AbstractJavadocMojo.getModulesLinks()
[ http://jira.codehaus.org/browse/MJAVADOC-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228721#action_228721 ] Erik Brakkee commented on MJAVADOC-268: --- I can also confirm it still exists in version 2.7. Reverting back to 2.5 solves the problem, however with only drawback which is that there is no multi-module javadoc available for the overall site. At least my site generation time reduces now from 45 minutes to about 7. > performance problem in AbstractJavadocMojo.getModulesLinks() > > > Key: MJAVADOC-268 > URL: http://jira.codehaus.org/browse/MJAVADOC-268 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200) > Java version: 1.6.0_13 > Java home: /home/mkleint/javatools/jdk1.6.0_13/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.29.6-desktop-2mnb" arch: "i386" Family: "unix" >Reporter: Milos Kleint >Assignee: Vincent Siveton >Priority: Critical > Fix For: 2.6.1 > > Attachments: javadoc.patch > > > The getModulesLinks() method is unacceptably slow under certain conditions: > 1. project's url is defined > 2. one or more projects in reactor do not have any java sources and are not > of "pom" packaging. > For such projects the apidocs/ output folder is never created resulting in > repeated invokation of a forked javadoc goal. It's more severe with high > number of modules in reactor and high number of modules without any java > sources. > as an example checkout "hg clone https://hg.kenai.com/hg/forceten~src"; > The immediate problem is in the apidocsFile.exists() condition that > re-triggers the forked invokation. The attached patch fixes that. However it > looks suspicitions that the method is being called repeatedly for each module > at all. Maybe the aborting condition at the start of the method body is wrong > (I was not able to decypher that) > workaround is to use 2.5 or not to specify the url in pom.xml or set the > detectOfflineLinks parameter to "false". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-479) stage-deploy re-run's all javadoc's for every module
[
http://jira.codehaus.org/browse/MSITE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228720#action_228720
]
Erik Brakkee commented on MSITE-479:
This appears to be already reported and is a problem in the javadoc plugin
see http://jira.codehaus.org/browse/MJAVADOC-268
> stage-deploy re-run's all javadoc's for every module
>
>
> Key: MSITE-479
> URL: http://jira.codehaus.org/browse/MSITE-479
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Andrew Hughes
>
> When running 'mvn clean install site:site' a javadoc's report work's as
> expected...
> When running 'mvn clean install site:site site:stage-deploy
> -DstagingSiteURL=file://c:/temp/site' there is a problem with the javadoc
> report. In a multi module project each time the javadoc's report is run, it
> claims all other modules have not had the javadoc's run yet - and it runs
> them.
> Consequently, if I have the following multi-module layout..
> {noformat}
> ./project
> ./project/module-1
> ./project/module-2
> ./project/module-3
> ./project/module-4
> ./project/module-5
> ./project/module-6
> {noformat}
> For modules 1..6 it will complain that all other modules have not had their
> javadoc goal run and the javadoc plugin will run 6x6=36 times! Note that the
> log's below are for module-6.
> {noformat}
> [INFO]
>
> [INFO] Building module-6
> [INFO]
>
> ...truncated log's...
> [INFO] Generating "JavaDocs" report.
> [WARNING] Source files encoding has not been set, using platform encoding
> Cp1252, i.e. build is platform dependent!
> [ERROR] Error fetching link:
> http://java.sun.com/javase/6/docs/api/package-list. Ignored it.
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'com.acme.project:module-1:jar:0.0.1-SNAPSHOT'. Trying to invoke it...
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'com.acme.project:module-2:jar:0.0.1-SNAPSHOT'. Trying to invoke it...
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'com.acme.project:module-3:jar:0.0.1-SNAPSHOT'. Trying to invoke it...
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'com.acme.project:module-4:jar:0.0.1-SNAPSHOT'. Trying to invoke it...
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'com.acme.project:module-5:jar:0.0.1-SNAPSHOT'. Trying to invoke it...
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'com.acme.project:module-6:jar:0.0.1-SNAPSHOT'. Trying to invoke it...
> {noformat}
> The concern I have is that site:site never complains about this and it's
> output is correct, why would stage-deploy be manipulating the report
> generation?
> Hopefully this is a mis-configuration on my part :)
--
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: (MREACTOR-17) make-scm-remote-changes to make everything that was changed remotely since a certain scm revision
make-scm-remote-changes to make everything that was changed remotely since a certain scm revision - Key: MREACTOR-17 URL: http://jira.codehaus.org/browse/MREACTOR-17 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Affects Versions: 1.0 Reporter: Geert Pante Hi all, I just discovered the make-scm-changes mojo in the reactor plugin (which was not transferred yet in core -> http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode). I think something similar would be very nice: to do a reactor make with the remote changed projects and their dependencies. I would like to use it in a continuous integration build. I have a 100-module project registered as one big Maven build in Hudson. Everytime a single file changes in Subversion, all modules are rebuilt. The make-scm-remote-changes should do an scm:update and then rebuild only the changed projects plus its dependents. -- 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: (MPMD-123) Add a custom ruleset file via command line
Add a custom ruleset file via command line -- Key: MPMD-123 URL: http://jira.codehaus.org/browse/MPMD-123 Project: Maven 2.x PMD Plugin Issue Type: Improvement Components: PMD Environment: All Reporter: Olivier Ribardière I have plenty of maven projects and cannot really change their pom.xml, however my continuous integration tool runs pmd so I need to be able to specify my custom ruleset file (c:/toto/myrulesetfile.xml) directly in the maven command line. Would be great if we could run "mvn pmd:pmd -Dpmd.rulesetfile=c:/toto/myrulesetfile.xml" (Of course if I could change the pom.xml I would have added d:\rulesets\strings.xml ... but I cannot change the pom.xml and via command line it is not possible to set a string[] parameter) -- 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: (SUREFIRE-629) NullPointerException in DemultiplexingRunListener, falsely report of "No tests were executed!"
[
http://jira.codehaus.org/browse/SUREFIRE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aslak Knutsen updated SUREFIRE-629:
---
Attachment: MavenSurefireJUnit47RunnerTestCase.java
Test case exposing Listener assumption bug.
Test case contain full bug description.
> NullPointerException in DemultiplexingRunListener, falsely report of "No
> tests were executed!"
> --
>
> Key: SUREFIRE-629
> URL: http://jira.codehaus.org/browse/SUREFIRE-629
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.5
> Environment: Maven Surefire 2.5
> Surefire JUnit 4.7
>Reporter: Aslak Knutsen
>Priority: Critical
> Attachments: MavenSurefireJUnit47RunnerTestCase.java
>
>
> Assumption:
> The DemultiplexingRunListener assumes a Test will be Started before it Fails
> or Finishes.
> Reality:
> JUnits ParentRunner is responsible for adding the BeforeClass/AfterClass
> statements to the statement execution chain. After BeforeClass is executed, a
> Statement that delegates to the abstract method: runChild(T child,
> RunNotifier notifier) is called. As the JavaDoc explains: "Subclasses are
> responsible for making sure that relevant test events are reported through
> {...@code notifier}". When a @BeforeClass fail, the child that should handle
> the relevant test events(Started, Failed, Finished) is never executed.
> Result:
> When Test Failed event is received in DemultiplexingRunListener without a
> Started event received first, it causes a NullPointException because there is
> no ClassReporter setup for that class yet. When this Exception is thrown from
> the DemultiplexingRunListene, JUnit catches the exception and reports is as a
> Failed test. But to avoid a wild loop, it removes the failing Listener before
> calling Failed test again. Since the DemultiplexingRunListener now is removed
> from the chain it will never receive the RunFinished event and the recorded
> state will never be replayed on the ReportManager.
> The End result:
> ReporterManager falsely believe no Test were run.
--
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-629) NullPointerException in DemultiplexingRunListener, falsely report of "No tests were executed!"
NullPointerException in DemultiplexingRunListener, falsely report of "No tests
were executed!"
--
Key: SUREFIRE-629
URL: http://jira.codehaus.org/browse/SUREFIRE-629
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.5
Environment: Maven Surefire 2.5
Surefire JUnit 4.7
Reporter: Aslak Knutsen
Priority: Critical
Assumption:
The DemultiplexingRunListener assumes a Test will be Started before it Fails or
Finishes.
Reality:
JUnits ParentRunner is responsible for adding the BeforeClass/AfterClass
statements to the statement execution chain. After BeforeClass is executed, a
Statement that delegates to the abstract method: runChild(T child, RunNotifier
notifier) is called. As the JavaDoc explains: "Subclasses are responsible for
making sure that relevant test events are reported through {...@code
notifier}". When a @BeforeClass fail, the child that should handle the relevant
test events(Started, Failed, Finished) is never executed.
Result:
When Test Failed event is received in DemultiplexingRunListener without a
Started event received first, it causes a NullPointException because there is
no ClassReporter setup for that class yet. When this Exception is thrown from
the DemultiplexingRunListene, JUnit catches the exception and reports is as a
Failed test. But to avoid a wild loop, it removes the failing Listener before
calling Failed test again. Since the DemultiplexingRunListener now is removed
from the chain it will never receive the RunFinished event and the recorded
state will never be replayed on the ReportManager.
The End result:
ReporterManager falsely believe no Test were run.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-310) download from Aix directories or files fails
[
http://jira.codehaus.org/browse/WAGON-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228690#action_228690
]
alain dheygere commented on WAGON-310:
--
At the end of my tests: wagon plugin, download goal, DEBUG mode, external
provider (url: sshext://server)
reading log traces
LINUX:
--
- to get list of files/directories, ls command:
ls -la ...
=> list of files including entries that begin with a . (dot)
- to know if it is a file or a directory program puts a slash at the end of the
path, ls command:
ls anyfile/
=> if it is a directory, an error is thrown from the command
Conclusion:
Download succeeds (also using internal ssh provider url: scp://linuxServer)
AIX:
- to get list of files/directories, ls command:
ls -lFA ... (not the same as LINUX ?!)
=> list of files except . (dot) and ..(dot-dot) but also put an * (asterisk) if
the file can be executed etc.
- to know if it is a file or a directory program puts a slash at the end of the
path, ls command:
ls anyfile/
=> if it is a directory, directory name is sent (not the same behaviour than
from LINUX).
Conclusion:
Download fails (also using internal ssh provider url: scp://aixServer).
"ls" command is different between AIX and LINUX
> download from Aix directories or files fails
>
>
> Key: WAGON-310
> URL: http://jira.codehaus.org/browse/WAGON-310
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0-beta-3
> Environment: maven 2.0.11/2.2.1 from Linux to Aix power5
>Reporter: alain dheygere
>
> Downloading of files or directories fails from Aix power5 system.
> When I try to download files from Aix system (using a ssh tunnel, I don't
> think this is the problem), files are copied with wildcard "*" in the Linux
> local server.
> pom.xml:
> ...
>
> org.codehaus.mojo
>wagon-maven-plugin
>
> ssh
>
> ...
>
> download
>
>
> tmp/
> ${project.basedir}/target
> t*
> scp://${target.server.name}:${target.server.port}
>
> ...
> traces:
> -
> [INFO] Executed tasks
> [DEBUG] Configuring mojo
> 'org.codehaus.mojo:wagon-maven-plugin:1.0-beta-3:download' -->
> [DEBUG] (f) caseSensitive = true
> [DEBUG] (f) fromDir = tmp/adheygere
> [DEBUG] (f) includes = t*
> [DEBUG] (f) project = MavenProject: com.amabis.www.Amalib:Aix:2.1 @
> /fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/pom.xml
> [DEBUG] (f) serverId = ssh
> [DEBUG] (f) settings = org.apache.maven.settings.setti...@1c70315
> [DEBUG] (f) skip = false
> [DEBUG] (f) toDir =
> /fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target
> [DEBUG] (f) url = scp://localhost:8182
> [DEBUG] -- end configuration --
> [INFO] [wagon:download {execution: download}]
> Using private key: /home/adheygere/.ssh/id_rsa
> scp://localhost:8182 - Session: Opened
> [INFO] Scanning remote file system: scp://localhost:8182 ...
> Executing command: ls /tmp/adheygere/toto*/
> Executing command: ls /tmp/adheygere/turlututu*/
> [INFO] Downloading scp://localhost:8182/tmp/adheygere/toto* to
> /fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target/toto* ...
> Executing command: scp -p -f /tmp/adheygere/toto*
> Remote file permissions: 0777
> Remote file size: 5
> Remote filename: toto
> attempting to create parent directories for destination: toto*
> Downloading: tmp/adheygere/toto* from scp://localhost:8182
> #
> Transfer finished. 5 bytes copied in 0.157 seconds
> [INFO] Downloading scp://localhost:8182/tmp/adheygere/turlututu* to
> /fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target/turlututu* ...
> Executing command: scp -p -f /tmp/adheygere/turlututu*
> Remote file permissions: 0777
> Remote file size: 10
> Remote filename: turlututu
> attempting to create parent directories for destination: turlututu*
> Downloading: tmp/adheygere/turlututu* from scp://localhost:8182
> #
> Transfer finished. 10 bytes copied in 0.155 seconds
> scp://localhost:8182 - Session: Disconnecting
> scp://localhost:8182 - Session: Disconnected
> -
> In the pom.xml, when using ** file path are wrong
> traces:
>
> [INFO] Executed tasks
> [DEBUG] Configuring mojo
> 'org.codehaus.mojo:wagon-maven-plugin:1.0-beta-3:download' -->
> [DEBUG] (f) caseSensitive = true
> [DEBUG] (f) fromDir = tmp/adheygere/maven/Amalib/Aix/target/classes/
> [DEBUG] (f) includes = **
> [DEBUG] (f) project = MavenProject: com.amabis.www.Amalib:Aix:2.1 @
> /fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/pom
[jira] Commented: (MNG-4731) NPE from AttachedArtifact.getVersion rather than meaningful error
[
http://jira.codehaus.org/browse/MNG-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228684#action_228684
]
Milos Kleint commented on MNG-4731:
---
Benjamin, unfortunately the MavenProjectHelper requires a MavenProject instance
as parameter which I don't have for the artifact in this case so I just copied
the code from MavenProjectHelper at some point in time.
> NPE from AttachedArtifact.getVersion rather than meaningful error
> -
>
> Key: MNG-4731
> URL: http://jira.codehaus.org/browse/MNG-4731
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Errors
>Affects Versions: 2.2.1
> Environment: Ubuntu Lucid, JDK 6u21
>Reporter: Jesse Glick
> Attachments: validateIdentity.diff
>
>
> I am working on a problem with {{nbm:populate-repository}} (from
> {{org.codehaus.mojo:nbm-maven-plugin}}). Maven 2.2.1, when run under certain
> circumstances, fails when running this goal with the following unhelpful
> message:
> {noformat}
> ...
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.project.artifact.AttachedArtifact.getVersion(AttachedArtifact.java:122)
> at
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:141)
> at
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:122)
> at
> org.apache.maven.project.artifact.AttachedArtifact.(AttachedArtifact.java:42)
> at
> org.codehaus.mojo.nbm.PopulateRepositoryMojo.createAttachedArtifact(PopulateRepositoryMojo.java:617)
> at
> org.codehaus.mojo.nbm.PopulateRepositoryMojo.execute(PopulateRepositoryMojo.java:424)
> ...
> {noformat}
> Inspection of the code reveals the immediate cause of the NPE: in
> {{getVersion}}, the {{parent}} field is null. Even though this is a final
> field set in the constructor to a non-null value, it has not yet been set
> when the super constructor is called. This is because {{DefaultArtifact}}
> uses the antipattern of calling an overridable method ({{getVersion}}) from
> its constructor (indirectly via {{validateIdentity}}). The NPE then prevents
> the details of the problem from being reported to the user.
> Ideally this antipattern would be solved, by making {{validateIdentity}}
> public and requiring all creators of a {{DefaultArtifact}} to call it after
> construction. Since this cannot now be done compatibly (e.g.
> {{PopulateRepositoryMojo}} above would need to be modified), the next best
> thing is to assume that {{AttachedArtifact}} is the only subclass, and ensure
> that {{validateIdentity}} is called only once the object has been fully
> constructed. With that change (patch against {{2.2.2-SNAPSHOT}} attached),
> the error message is informative (specifics of this run have been elided) and
> points toward possible problems in the plugin:
> {noformat}
> ...
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] An invalid artifact was detected.
> This artifact might be in your project's POM, or it might have been included
> transitively
> during the resolution process. Here is the information we do have for this
> artifact:
> o GroupID: ...
> o ArtifactID: ...
> o Version: ...
> o Type:<<< MISSING >>>
> [INFO]
>
> [INFO] Trace
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {...:...:...:null}: The type cannot be empty.
> at
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:141)
> at
> org.apache.maven.project.artifact.AttachedArtifact.validateIdentity(AttachedArtifact.java:63)
> at
> org.apache.maven.project.artifact.AttachedArtifact.(AttachedArtifact.java:53)
> at
> org.codehaus.mojo.nbm.PopulateRepositoryMojo.createAttachedArtifact(PopulateRepositoryMojo.java:617)
> at
> org.codehaus.mojo.nbm.PopulateRepositoryMojo.execute(PopulateRepositoryMojo.java:424)
> ...
> {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
