[jira] Created: (CONTINUUM-1649) http://maven.apache.org/continuum/docs/1.1/user_guides/managing_builddef/builddefTemplate.html
http://maven.apache.org/continuum/docs/1.1/user_guides/managing_builddef/builddefTemplate.html -- Key: CONTINUUM-1649 URL: http://jira.codehaus.org/browse/CONTINUUM-1649 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Environment: vmbuild.apache.org/continuum Reporter: SebbASF http://maven.apache.org/continuum/docs/1.1/user_guides/managing_builddef/builddefTemplate.html refers to defining build templates. As it is under the User Guide section of the web-site, this implies that it is available to ordinary users. However, this does not seem to be the case on vmbuild.apache.org - there is no Build Definitions Templates menu item as far as I can see. This probably means that it is an Admin task - in which case the documentation should be moved to the appropriate section. -- 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-332) mvn-eclipse-cache.properties is never filled
[ http://jira.codehaus.org/browse/MECLIPSE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122724 ] Dominique Jean-Prost commented on MECLIPSE-332: --- I also meet this problem. I use archiva 1.0 with maven. Maybe it can help. mvn-eclipse-cache.properties is never filled Key: MECLIPSE-332 URL: http://jira.codehaus.org/browse/MECLIPSE-332 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Wouter de Vaal See summary, the file is writen, but no data is in it, resulting in very long builds each time the eclipse update is needed. -- 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: (DOXIA-125) Twiki module uses different HTML markup conventions to the other modules (e.g. apt)
[ http://jira.codehaus.org/browse/DOXIA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-125. --- Assignee: Lukas Theussl Resolution: Cannot Reproduce Fix Version/s: (was: 1.0-beta-1) Please open another issue with a more specific description of the problem. Twiki module uses different HTML markup conventions to the other modules (e.g. apt) --- Key: DOXIA-125 URL: http://jira.codehaus.org/browse/DOXIA-125 Project: Maven Doxia Issue Type: Improvement Components: Module - Twiki Affects Versions: 1.0-alpha-9 Reporter: Dave Syer Assignee: Lukas Theussl Attachments: site-test.zip There are some inconsistencies between the way that the HTML is rendered from twiki and the other doxia formats - e.g. it uses div class=section instead of h2 - so you need a different css to get the same result. -- 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: (MDEP-143) incomplete literal/length tree when analyzing
incomplete literal/length tree when analyzing - Key: MDEP-143 URL: http://jira.codehaus.org/browse/MDEP-143 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0 Reporter: Baptiste MATHUS Assignee: Brian Fox Priority: Blocker Attachments: analyze-crash.txt Starting analyze from a project directory, it crashes with this message : incomplete literal/length tree. It seems like some zip is corrupted, I guess this is a jar that may have this problem, but I can't figure which one it is. I guess maven-dependency-plugin should at least try to catch this exception to log which jar it was trying to analyze. This would help identify the corrupted jar in the local maven repository and try to correct/update it. Thanks a lot. -- 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: (MRM-686) 'Unable to find project model' when artifactId contains property placeholders e.g. ${project.parent.artifactId}
'Unable to find project model' when artifactId contains property placeholders
e.g. ${project.parent.artifactId}
---
Key: MRM-686
URL: http://jira.codehaus.org/browse/MRM-686
Project: Archiva
Issue Type: Bug
Components: browser
Affects Versions: 1.0
Reporter: Geert Pante
We frequently use property placeholders in our poms to have generic POM
templates,
e.g.
project
parent
groupIdbe.javaserver.tst/groupId
artifactIdeCommonOrderHandling/artifactId
version2.8-SNAPSHOT/version
/parent
artifactId${project.parent.artifactId}-module-sTst8128/artifactId
/project
283836 [SocketListener0-0] WARN
org.apache.maven.archiva.consumers.DatabaseUnprocessedArtifactConsumer:update-db-project
- File eCommonOrderHandling-module-sTst8128-1.5-20080131.102935-1.pom has an
invalid project model
[groupId:be.javaserver.tst|artifactId:${project.parent.artifactId}-module-sTst8128|version:1.5
-20080131.102935-1|packaging:jar]: The model artifactId
[${project.parent.artifactId}-module-sTst8128] does not match the artifactId
portion of the filename:
eCommonOrderHandling-module-sTst8128
284107 [SocketListener0-0] WARN
org.apache.maven.archiva.consumers.DatabaseUnprocessedArtifactConsumer:update-db-project
- Invalid or corrupt pom.
Project model not added to database -
be.javaserver.tst:${project.parent.artifactId}-module-sTst8128:1.5-20080131.102935-1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-323) Release plugin (prepare goal) doesn't update more than one snapshot dependencies
Release plugin (prepare goal) doesn't update more than one snapshot dependencies
Key: MRELEASE-323
URL: http://jira.codehaus.org/browse/MRELEASE-323
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-7
Environment: Any
Reporter: Alessandro Zucchi
Priority: Blocker
Attachments: patch.txt
I have a project so structured:
au au-business
|
| au-sistema
Dependencies in au are:
...
dependencyManagement
dependencies
dependency
groupIdcom.zucchetti.qweb.au/groupId
artifactIdau-business/artifactId
version${project.version}/version
/dependency
!-- external dependencies--
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdsistema/artifactId
version03.00.02-SNAPSHOT/version
/dependency
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdbusiness/artifactId
version03.00.02-SNAPSHOT/version
/dependency
/dependencies
/dependencyManagement
...
Dependencies in au-business are:
...
dependencies
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdbusiness/artifactId
/dependency
/dependencies
...
Dependencies in au-sistema are:
...
dependencies
dependency
groupIdcom.zucchetti.qweb.au/groupId
artifactIdau-business/artifactId
/dependency
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdsistema/artifactId
/dependency
/dependencies
...
When I make a mvn release:clean release:prepare of au project the plugin,
correctly, ask me to resolve SNAPSHOTs dependencies. (framework-business
framework-sistema)
Unfortunatly at the end of the process only framework-sistema dependency (in au
project) has been modified, while framework-business no.
I've debuged the problem and I found that if I force the two dependencies
(framework-sistema, framework-business) in the parent pom (pom of au) all run
fine (also if the process to resolve SNAPSHOT dependencies get prompted tree
times ... too much I say ...).But I can't do this change in production.
So, I tryed to resolve the problem.
I've attached a patch.
Best regards
Alex
--
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: (DOXIA-210) Snippet macro should include whole file if no id is given
[
http://jira.codehaus.org/browse/DOXIA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-210.
---
Resolution: Fixed
Snippet macro should include whole file if no id is given
-
Key: DOXIA-210
URL: http://jira.codehaus.org/browse/DOXIA-210
Project: Maven Doxia
Issue Type: Improvement
Components: Core, Documentation
Affects Versions: 1.0-alpha-9
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.0-beta-1
Currently the snippet macro requires an id attribute, and snippets are only
included if they are enclosed with the START and END demarcators. However,
neither id nor demarcators are necessary if you want to include an entire
file. I'd suggest to allow the following:
{noformat}
%{snippet|file=path/to/file.txt}
{noformat}
which will include the whole file.txt.
Note also that the documentation at
http://maven.apache.org/doxia/macros/index.html seems misleading, as it says
that the demarcators are only needed if you want to include part of a file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3389) maven freeze
maven freeze Key: MNG-3389 URL: http://jira.codehaus.org/browse/MNG-3389 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Tom Spengler in our envrionment (tested with jdk 1.4.15, maven 2.0.5, maven 2.0.7 on linux) freeze sometimes the maven-build we break them after more the 3 hours the next run works fine with out any changes in the code or pom the kill -3 stacktrace gives -- Full thread dump Java HotSpot(TM) Server VM (1.4.2_15-b02 mixed mode): Signal Dispatcher daemon prio=1 tid=0x080c05b8 nid=0x7bbe runnable [0x..0x] Finalizer daemon prio=1 tid=0x080bc038 nid=0x7bbc in Object.wait() [0xce2c9000..0xce2c9258] at java.lang.Object.wait(Native Method) - waiting on 0xd1eda998 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked 0xd1eda998 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x080bbca8 nid=0x7bbb in Object.wait() [0xce349000..0xce349258] at java.lang.Object.wait(Native Method) - waiting on 0xd1edaa00 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked 0xd1edaa00 (a java.lang.ref.Reference$Lock) main prio=1 tid=0x080581a0 nid=0x7bb7 runnable [0xffa34000..0xffa35038] at java.util.LinkedHashMap.transfer(LinkedHashMap.java:224) at java.util.HashMap.resize(HashMap.java:452) at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:399) at java.util.HashMap.put(HashMap.java:392) at java.util.HashSet.add(HashSet.java:192) at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:378) at org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1558) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:229) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:339) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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)
[jira] Closed: (MCHANGES-78) Build a changes report by parsing svn comments
[ http://jira.codehaus.org/browse/MCHANGES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet closed MCHANGES-78. - Resolution: Won't Fix Build a changes report by parsing svn comments -- Key: MCHANGES-78 URL: http://jira.codehaus.org/browse/MCHANGES-78 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Emmanuel Hugonnet Priority: Minor Attachments: site.tar.gz, svn-changelog-plugin-jdk1.4.tar.gz, svn-changelog-plugin.tar.gz, svnchangelog-plugin-jdk1.4.tar.gz Builds a changes report by parsing svn comments. You can configure this plugin as any reporting plugin. But it has specific configuration parameters : * grammar : this allows you to specify the grammar used to parse the svn logs. Currently it supports two grammars : o MANU which uses @operation:issue; o REMY with [operation:issue] * trackerType : this allows you to specify the issue tracker used. Currently it supports two trackers : o codex o jira * trackerUrlPattern : this allows you to specify a pattern to link an issue to any tracker. -- 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: (MCHANGES-78) Build a changes report by parsing svn comments
[ http://jira.codehaus.org/browse/MCHANGES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122762 ] Emmanuel Hugonnet commented on MCHANGES-78: --- Well, this gives the same report as the changes plugin so that 's why i submitted it there. The first 2 submits were org.apache but since it looks like the community is not interested I was in the process of migrating the code to codehaus when in a last attempt I submittted it. Nobody seems to be interested in what this plugin do but more in how it is packaged. Hope it will have a good life on codehaus Build a changes report by parsing svn comments -- Key: MCHANGES-78 URL: http://jira.codehaus.org/browse/MCHANGES-78 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Emmanuel Hugonnet Priority: Minor Attachments: site.tar.gz, svn-changelog-plugin-jdk1.4.tar.gz, svn-changelog-plugin.tar.gz, svnchangelog-plugin-jdk1.4.tar.gz Builds a changes report by parsing svn comments. You can configure this plugin as any reporting plugin. But it has specific configuration parameters : * grammar : this allows you to specify the grammar used to parse the svn logs. Currently it supports two grammars : o MANU which uses @operation:issue; o REMY with [operation:issue] * trackerType : this allows you to specify the issue tracker used. Currently it supports two trackers : o codex o jira * trackerUrlPattern : this allows you to specify a pattern to link an issue to any tracker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122782 ] luke w patterson commented on MNG-3380: --- Thanks for the info, Vincent. Please let me know if the new patch is better. Just keep in mind that the patch is not elegant at all. Basically, I check to see if ArtifactMetadataSource changes the artifact (due to relocation) when it retrieves ResolutionGroup. If it does change it, I repeat the portion of code that checks for managed versions. That was a quick hack because I couldn't find a place in the logic which was aware of all factors involved. Thanks, Luke MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace
[jira] Updated: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] luke w patterson updated MNG-3380: -- Attachment: MNG-3380-maven-artifact.patch MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace changes, it is about 10 lines different. Thanks, Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122785 ] Wojciech Ciesielski commented on MNG-3380: -- If I understand this issue well then this is exactly the same problem we're having with xerces... groovy 1.0 (from repo1.maven.org) has dependency to xerces:xerces:jar:2.4.0 which has been relocated to xerces:xercesImpl:2.4.0. I do have xerces:xercesImpl:2.6.2 in dependencyManagement of root POM for our set of projects (modules) but when a module (web module) depending on both xerces:xercesImpl and groovy is built, then BOTH xerces libs are bundled: 2.4 (from relocation) and 2.6.2 (from dep. mgmnt.)... MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve
[jira] Created: (MWAR-140) 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown
2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown - Key: MWAR-140 URL: http://jira.codehaus.org/browse/MWAR-140 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Priority: Blocker Attachments: FixForIOExceptionCatchInAbstractWarPackagingTask.patch 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown. I have fix this locally and have attached a simple patch for it. All you have to do is remove the offending catch block. -- 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-452) suitename always = TestSuite even if suitename defined as property
suitename always = TestSuite even if suitename defined as property
--
Key: SUREFIRE-452
URL: http://jira.codehaus.org/browse/SUREFIRE-452
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4.1, 2.4
Environment: Maven version: 2.0.8
Java version: 1.5.0_14
OS name: windows xp version: 5.1 arch: x86 Family: windows
and also on Linux
Reporter: Erez Nahir
Attachments: TestNGDirectoryTestSuite.java
Using surefire and testng with no testng.xml but with cofiguration, the
generated standard output xml always have suite name=TestSuite.
This is an issue while using CruiseControl and JUnitReport to generate a JUnit
report.
Here is the configuration in my pom file:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.1/version
configuration
testFailureIgnoretrue/testFailureIgnore
groupsfast/groups
excludedgroupsbroken/excludedgroups
properties
property
namesuitename/name
value${artifactId}/value
/property
property
nametestname/name
value${artifactId}/value
/property
/properties
/configuration
/plugin
There is an attached patch too.
--
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: (MWAR-140) 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown
[ http://jira.codehaus.org/browse/MWAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-140. - Resolution: Fixed Fix Version/s: 2.1-alpha-2 commited in rev 619555. Thanks ! 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown - Key: MWAR-140 URL: http://jira.codehaus.org/browse/MWAR-140 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Olivier Lamy Priority: Blocker Fix For: 2.1-alpha-2 Attachments: FixForIOExceptionCatchInAbstractWarPackagingTask.patch 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown. I have fix this locally and have attached a simple patch for it. All you have to do is remove the offending catch block. -- 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-1928) Please synchronize HDIV repository (a script has been attached) to the central maven repository.
Please synchronize HDIV repository (a script has been attached) to the central maven repository. Key: MAVENUPLOAD-1928 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1928 Project: maven-upload-requests Issue Type: Task Reporter: Gorka Vicente Attachments: org.hdiv.sh -- 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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122799 ] olamy edited comment on MWAR-141 at 2/7/08 1:24 PM: --- stephane can you fix permissions or deploy a new snapshot ? Thanks. was (Author: olamy): stephan can you fix permissions or deploy a new snapshot ? Thanks. maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122799 ] Olivier Lamy commented on MWAR-141: --- stephan can you fix permissions or deploy a new snapshot ? Thanks. maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Priority: Minor It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Priority: Minor It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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: (NMAVEN-105) NUnit Does not Work with Mono
NUnit Does not Work with Mono - Key: NMAVEN-105 URL: http://jira.codehaus.org/browse/NMAVEN-105 Project: NMaven Issue Type: Bug Reporter: Shane Isbell The compiled 2.4.x version of nunit framework that NMaven is using is not compatible with earlier versions of NUnit. Mono requires 2.2.x version. [INFO] Unhandled Exception: [INFO] System.TypeLoadException: Could not load type 'NUnit.Console.ConsoleUi+EventCollector, nunit-console, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' We will need to compile a 2.2.x version of NUnit.Framework for use with Mono. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122812 ] luke w patterson commented on MNG-3380: --- Wojciech, Is this the scenario you are describing? project modelVersion4.0.0/modelVersion groupIdparent-groupId/groupId artifactIdparent-artifactId/artifactId version1/version packagingpom/packaging dependencyManagement dependencies dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.6.2/version /dependency /dependencies /dependencyManagement /project project parent groupIdparent-groupId/groupId artifactIdparent-artifactId/artifactId version1/version /parent modelVersion4.0.0/modelVersion artifactIdchild-artifactId/artifactId dependencies dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId /dependency dependency groupIdgroovy/groupId artifactIdgroovy/artifactId version1.0/version /dependency /dependencies /project If so, 2.0.8 seemed to handle it correctly: [dependency:tree] parent-groupId:child-artifactId:jar:1 +- xerces:xercesImpl:jar:2.6.2:compile \- groovy:groovy:jar:1.0:compile +- antlr:antlr:jar:2.7.5:compile +- asm:asm:jar:2.2:compile +- (xerces:xercesImpl:jar:2.6.2:compile - version managed from 2.4.0; omitted for duplicate) +- xml-apis:xml-apis:jar:1.0.b2:compile +- commons-cli:commons-cli:jar:1.0:compile | +- (commons-logging:commons-logging:jar:1.0:compile - omitted for conflict with 1.0.4) | \- commons-lang:commons-lang:jar:1.0:compile | \- (junit:junit:jar:3.7:compile - omitted for conflict with 3.8.2) +- ant:ant:jar:1.6.5:compile +- ant:ant-junit:jar:1.6.5:compile +- ant:ant-launcher:jar:1.6.5:compile +- junit:junit:jar:3.8.2:compile +- jmock:jmock:jar:1.1.0:compile | \- (junit:junit:jar:3.8.1:compile - omitted for conflict with 3.8.2) +- jmock:jmock-cglib:jar:1.1.0:compile | +- (jmock:jmock:jar:1.1.0:compile - omitted for duplicate) | \- cglib:cglib-full:jar:2.0:compile +- cglib:cglib-nodep:jar:2.1_3:compile +- asm:asm-util:jar:2.2:compile +- asm:asm-attrs:jar:2.2:compile +- asm:asm-analysis:jar:2.2:compile +- asm:asm-tree:jar:2.2:compile +- bsf:bsf:jar:2.4.0:compile | \- (commons-logging:commons-logging:jar:1.0.4:compile - omitted for conflict with 1.0) +- mx4j:mx4j:jar:3.0.1:compile +- mockobjects:mockobjects-core:jar:0.09:compile +- openejb:openejb-loader:jar:1.0:compile | +- openejb:openejb-core:jar:1.0:compile | | +- (org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0:compile - omitted for duplicate) | | +- (org.apache.geronimo.specs:geronimo-ejb_2.1_spec:jar:1.0:compile - omitted for duplicate) | | +- (org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0:compile - omitted for duplicate) | | +- (org.apache.geronimo.specs:geronimo-servlet_2.4_spec:jar:1.0:compile - omitted for duplicate) | | +- (log4j:log4j:jar:1.2.8:compile - omitted for duplicate) | | +- backport-util-concurrent:backport-util-concurrent:jar:2.0_01_pd:compile | | +- (xerces:xercesImpl:jar:2.6.2:compile - version managed from 2.6.0; omitted for duplicate) | | +- (xml-apis:xml-apis:jar:1.0.b2:compile - omitted for duplicate) | | +- castor:castor:jar:0.9.9.0-pre:compile | | +- oro:oro:jar:2.0.8:compile | | +- (commons-logging:commons-logging:jar:1.0.3:compile - omitted for conflict with 1.0) | | \- idb:idb:jar:3.26:compile | +- org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0:compile | +- org.apache.geronimo.specs:geronimo-ejb_2.1_spec:jar:1.0:compile | +- org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0:compile | +- org.apache.geronimo.specs:geronimo-servlet_2.4_spec:jar:1.0:compile | \- log4j:log4j:jar:1.2.8:compile +- axion:axion:jar:1.0-M3-dev:compile | +- (commons-collections:commons-collections:jar:3.0:compile - omitted for conflict with 3.2) | +- (commons-primitives:commons-primitives:jar:1.0:compile - omitted for duplicate) | +- (commons-logging:commons-logging:jar:1.0:compile - omitted for duplicate) | +- commons-codec:commons-codec:jar:1.2:compile | +- (junit:junit:jar:3.8.1:compile - omitted for conflict with 3.8.2) | \- net.java.dev.javacc:javacc:jar:3.2:compile +- commons-logging:commons-logging:jar:1.0.4:compile +- commons-collections:commons-collections:jar:3.2:compile +- commons-primitives:commons-primitives:jar:1.0:compile +- regexp:regexp:jar:1.3:compile +- javax.servlet:servlet-api:jar:2.4:compile +- javax.servlet:jsp-api:jar:2.0:compile | \- (javax.servlet:servlet-api:jar:2.4:compile - omitted for duplicate) +-
[jira] Commented: (MWAR-140) 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown
[ http://jira.codehaus.org/browse/MWAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122793 ] Allen Servedio commented on MWAR-140: - Just to be a bit more helpful, here is the error I got while trying to build revision 619529: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\svn_home\maven-war-plugin\src\main\java\org\apache\maven\plugin\war\packaging \AbstractWarPackagingTask.java:[265,8] exception java.io.IOException is never th rown in body of corresponding try statement 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown - Key: MWAR-140 URL: http://jira.codehaus.org/browse/MWAR-140 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Olivier Lamy Priority: Blocker Attachments: FixForIOExceptionCatchInAbstractWarPackagingTask.patch 2.1-alpha-2 head is not compiling because AbstractWarPackagingTask is trying to catch an IOException that is no longer thrown. I have fix this locally and have attached a simple patch for it. All you have to do is remove the offending catch block. -- 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: (CONTINUUM-1650) Cannot rollback release if prepare failed before create-backup-poms
Cannot rollback release if prepare failed before create-backup-poms --- Key: CONTINUUM-1650 URL: http://jira.codehaus.org/browse/CONTINUUM-1650 Project: Continuum Issue Type: Bug Components: Release Affects Versions: 1.1 Reporter: Geert Pante If the release prepare step failed before the create-backup-poms, e.g. during check-dependency-snapshots, you cannot rollback the changes: the HTTP request times out, and the error below appears in the log file: BTW, the release:rollback mojo from maven-2.0.4 maven-release-plugin fails as well. 10626479 [pool-5-thread-1] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:rollback-release - Error executing task org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Failed to rollback release at org.apache.maven.continuum.release.executors.RollbackReleaseTaskExecutor.execute(RollbackReleaseTaskExecutor.java:45) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Cannot restore from a missing backup POM: /data01/continuum/work/6/pom.xml.releaseBackup at org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.restorePomBackup(RestoreBackupPomsPhase.java:90) at org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.execute(RestoreBackupPomsPhase.java:69) at org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:248) at org.apache.maven.continuum.release.executors.RollbackReleaseTaskExecutor.execute(RollbackReleaseTaskExecutor.java:40) ... 7 more -- 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: (DOXIA-104) Support use of custom properties in XDOC files
[ http://jira.codehaus.org/browse/DOXIA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-104. --- Assignee: Lukas Theussl Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-1) This should be done with meta elements inside head, see DOXIA-129. Support use of custom properties in XDOC files -- Key: DOXIA-104 URL: http://jira.codehaus.org/browse/DOXIA-104 Project: Maven Doxia Issue Type: Task Components: Module - Xdoc Affects Versions: 1.0-alpha-8 Reporter: Andy Jefferson Assignee: Lukas Theussl Priority: Critical In the JPOX Maven1 use of site we tagged all (XDOC) docs like this document properties titleApplication Identity/title jpoxpagetypePersistence/jpoxpagetype jpoxversion1_2/jpoxversion /properties ... /document since XDOCs werent validated against any DTD etc. Then in site.jsl we could access these properties via j:set var=jpoxpage_param x:expr select=./properties/jpoxpagetype/ /j:set With Maven2 I don't see how I can do this. I define my own skin for JPOX and in site.vm I have $title, $authors but nothing more. Delving into Doxia I see where they were set up. No allowance for users own properties. The requirement for JPOX is that we have a large number of documents, and we tag each doc for particular categories ... which will then appear on the web site as horizontal navigation (the default Maven skin only has the navColumn ... vertical navigation). By being able to tag docs into categories/subcategories etc we can then generate a site that the user selects a horizontal nav category, and then a horizontal nav sub-category, and they see vertical navigation within that subcategory. This was possible with Maven1 due to the above ability. Without an equivalent in Maven2 we cannot switch over. The JPOX docs (from Maven1) are available at http://www.jpox.org/docs/1_2/index.html so you can understand what is being talked about here. If you need any more info let me know. -- 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: (DOXIA-149) Don't break lines in apt generated table cells
[ http://jira.codehaus.org/browse/DOXIA-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-149. --- Assignee: Lukas Theussl Resolution: Duplicate Fix Version/s: (was: 1.0-beta-1) Don't break lines in apt generated table cells -- Key: DOXIA-149 URL: http://jira.codehaus.org/browse/DOXIA-149 Project: Maven Doxia Issue Type: Improvement Components: Documentation, Module - Apt Affects Versions: 1.0-alpha-8 Environment: mvn 2.0.5 Reporter: Jerome Lacoste Assignee: Lukas Theussl Priority: Trivial Attachments: APT-tables.png See attached screenshot. Is there a way to make this table look nicer ? I.e. get rid off the br ? lacostej_ how does one create multiline table cells in APT format ? the parser introduces br elements and that makes the rendering ugly lacostej_ I have a screenshot of the problem available lacostej_ kenney: http://www.flickr.com/photos/[EMAIL PROTECTED]/421928169/ kenneycan you paste the apt for the table? *--+--+ |command line | Java Mojo | *--+--+ | the VM exits as soon as the only | By default daemon threads are joined| | remaining threads are daemon threads | and interrupted once all known non | | | daemon threads have quitted. The join| | | timeout is customisable | | | The user might wish to further cleanup | | | cleanup by stopping the unresponsive | | | threads. | | | The user can disable the full extra | | | thread management (interrupt/join/[stop])| *--+--+ kenneylacostej_: i'd say that the APT engine produced a one-on-one image of the source, quite nice ;) lacostej_ :) kenneyi guess you have to put everything on 1 line to make it render properly kenneytoo bad you can't specify 'align=justify' kenneywhat about \ ? kenneyow crap: Line breaks must not be used inside titles and tables (which are line oriented blocks with implicit line breaks). kenneyand \ is a line break, instead of a continuation as is used everywhere else EODiscussion -- 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-78) Library directory configuration
[
http://jira.codehaus.org/browse/MEAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122792
]
Danilo Eiji Seki commented on MEAR-78:
--
In the current plugin version, the following {{pom.xml}} configuration
{code:xml}
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.mygroup/groupId
artifactIdapplication/artifactId
packagingear/packaging
version1.0-SNAPSHOT/version
dependencies
dependency
groupIdcom.mygroup/groupId
artifactIdejbmodule/artifactId
typeejb/type
version1.0-SNAPSHOT/version
/dependency
/dependencies
build
plugin
artifactIdmaven-ear-plugin/artifactId
configuration
defaultLibBundleDir/MYLIBDIR/defaultLibBundleDir
modules
version5/version
/modules
/configuration
/plugin
/build
/project
{code}
Generates the following {{application.xml}}:
{code:xml}
?xml version=1.0 encoding=UTF-8?
application xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/application_5.xsd;
version=5
module
ejbejbmodule-1.0-SNAPSHOT.jar/ejb
/module
/application
{code}
But notice that the above generated XML does not include a
{{library-directory}} configuration, included in JEE 5. This new configuration
ends the different library directory problem across servers problem.
What I need is that in the case of EAR version 5 and {{defaultLibBundleDir}}
set for the EAR plugin, such value to be included in the {{application.xml}},
generating something like this:
{code:xml}
?xml version=1.0 encoding=UTF-8?
application xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/application_5.xsd;
version=5
module
ejbejbmodule-1.0-SNAPSHOT.jar/ejb
/module
library-directory/MYLIBDIR/library-directory
/application
{code}
Library directory configuration
---
Key: MEAR-78
URL: http://jira.codehaus.org/browse/MEAR-78
Project: Maven 2.x Ear Plugin
Issue Type: New Feature
Reporter: Danilo Eiji Seki
Plugin configuration should include a property to set {{library-directory}}
configuration in generated {{application.xml}}. It may not be necessary to
include this property. Maybe something like if {{defaultLibBundleDir}} is
different from {{lib}}, include configuration.
--
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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Servedio reopened MWAR-141: - Since this is not yet fixed, I am just reopening it to remind you. Thanks for working on this so quickly! maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1-alpha-2 It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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: (MPLUGIN-69) Be consistent about physical/logical formatting tags
Be consistent about physical/logical formatting tags
Key: MPLUGIN-69
URL: http://jira.codehaus.org/browse/MPLUGIN-69
Project: Maven 2.x Plugin Tools
Issue Type: Task
Components: API
Affects Versions: 2.1
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: logical-text-formatting.patch
A mojo description page uses both {{code}} and {{b}} for text formatting,
the first element being a logical tag, the later a physical. As a mere matter
of consistency, it might be wise to not mix these formatting styles, i.e. use
{{tt}} instead of {{code}} or {{strong}} instead of {{b}}.
--
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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122820 ] Stephane Nicoll commented on MWAR-141: -- Well it's weird. The build number is not updated. I wonder what's going on here. maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1-alpha-2 It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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: (MCHANGES-78) Build a changes report by parsing svn comments
[ http://jira.codehaus.org/browse/MCHANGES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122815 ] Dennis Lundberg commented on MCHANGES-78: - The other day, I had a look at the generated site that you attached to this issue. When you first proposed this plugin on the dev-list I couldn't understand how it would work and how it differed from maven-changelog-plugin. I understand that better now. To me it seems that the input and output of your plugin is somewhere in-between maven-changes-plugin and maven-changelog-plugin. However I can't see a good way to integrate it into either one. The changes plugin produces a report based on an issue tracking system. Currently we support changes.xml file and JIRA as issue trackers. Your approach of parsing the commit messages from an SCM doesn't fit well into that. We have a saying where i live. It goes something like this: _Don't cross the river to fetch water_ That pretty much describes how I feel about your plugin. Why would you want to ask the SCM about issues that are already tracked in an issue tracker? It seems like an extra, and unnecessary, step. Just ask the issue tracker directly. You are bound to get better texts to put in the report than you would by parsing SCM messages. Build a changes report by parsing svn comments -- Key: MCHANGES-78 URL: http://jira.codehaus.org/browse/MCHANGES-78 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Emmanuel Hugonnet Priority: Minor Attachments: site.tar.gz, svn-changelog-plugin-jdk1.4.tar.gz, svn-changelog-plugin.tar.gz, svnchangelog-plugin-jdk1.4.tar.gz Builds a changes report by parsing svn comments. You can configure this plugin as any reporting plugin. But it has specific configuration parameters : * grammar : this allows you to specify the grammar used to parse the svn logs. Currently it supports two grammars : o MANU which uses @operation:issue; o REMY with [operation:issue] * trackerType : this allows you to specify the issue tracker used. Currently it supports two trackers : o codex o jira * trackerUrlPattern : this allows you to specify a pattern to link an issue to any tracker. -- 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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-141. Resolution: Fixed Fix Version/s: 2.1-alpha-2 Yep, done. maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1-alpha-2 It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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-171) Modules in multi-module projects are built too often
[ http://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MJAVADOC-171: -- Attachment: mjavadoc171.patch FYI, I can't get maven-javadoc-plugin to mvn install from trunk (I get test failures), but the 2.3 tag builds just fine; when I remove the @aggregator tag from the mojo, it seems to work perfectly. I hypothesize that @aggregator is seriously broken, at least for reporting plugins (or perhaps just plugins that need to @execute forked lifecycles like this one), and at least in this case, it seems to be harmful and unnecessary. http://www.nabble.com/%40aggregator-mojo-annotation-td15302246s177.html Modules in multi-module projects are built too often -- Key: MJAVADOC-171 URL: http://jira.codehaus.org/browse/MJAVADOC-171 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Maven 2.0.8, Linux Reporter: Stefan Seidel Priority: Critical Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip In a multi-module project, all modules are built twice for each module. This leads to huge performance problems when many modules are in a project. In the attached sample project, the xmlbeans plugin is executed 27 times for a project with one parent module and two submodules. 18 of these executions can be attributed to the javadoc plugin. With version 2.2, only 3 invocations (once for each project) are caused by the javadoc plugin. -- 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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122824 ] Allen Servedio commented on MWAR-141: - It looks like both the timestamp and build number did not update, though the file itself does look like it changed... maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1-alpha-2 It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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-137) javadoc:javadoc always runs as aggregator
[ http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122843 ] Dan Fabulich commented on MJAVADOC-137: --- I'm pretty sure MNG-2184 is to blame here; it seems clear that reporting plugins that use forked lifecycles should not use @aggregator. At least in this case, it seems to be harmful and unnecessary. FYI, I can't get maven-javadoc-plugin to mvn install from trunk (I get test failures), but the 2.3 tag builds just fine; when I remove the @aggregator tag from the mojo, it seems to work perfectly. http://www.nabble.com/%40aggregator-mojo-annotation-td15302246s177.html javadoc:javadoc always runs as aggregator --- Key: MJAVADOC-137 URL: http://jira.codehaus.org/browse/MJAVADOC-137 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Peter Hendriks Priority: Critical Fix For: 2.4 In version 2.2, javadoc aggregation was configurable using the configuration property aggregate. In version 2.3, all javadoc goals got the @aggregator attribute added to its mojos (through a change in org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now always run aggregated regardless of the configuration setting. This breaks our build as we require non-aggregated javadoc execution in our multi-module poms. Please fix this so this is once again configurable and backwards compatible with previous versions of the javadoc plug-in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122845 ] derik commented on MNG-2551: Anybody find it curious that the file length is also the length of a linux directory? Just seems interesting that it would be that number. 4096 pom metadata file gets truncated during install into local repository - Key: MNG-2551 URL: http://jira.codehaus.org/browse/MNG-2551 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Environment: Win XP, JDK 1.4 Reporter: Sharmarke Aden Fix For: Reviewed Pending Version Assignment Attachments: pom.xml, shared-1.9.0.pom When I attempt to install my project artifact to my local repository it seems that sometimes an incomplete/truncated .pom is deployed to my local repository. It's kind of weird because sometimes it happens and sometimes it doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and the truncated pom meta data artifact deployed to my local repository. One thing I found that's odd is that the size of the truncated pom generated is consistently 4096 bytes. p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2184) Possible problem with @aggregator and forked lifecycles
[
http://jira.codehaus.org/browse/MNG-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122850
]
John Casey commented on MNG-2184:
-
See revId: 619720 on trunk...does this do enough to prevent bound-aggregator
weirdness?
Possible problem with @aggregator and forked lifecycles
---
Key: MNG-2184
URL: http://jira.codehaus.org/browse/MNG-2184
Project: Maven 2
Issue Type: Bug
Components: Design, Patterns Best Practices, Plugins and Lifecycle
Affects Versions: 2.0.3
Environment: Revision 974 of Cargo
(https://svn.codehaus.org/cargo/cargo/trunk/core/api/)
Reporter: Vincent Massol
Assignee: John Casey
Priority: Blocker
Fix For: 2.1
Attachments: cargo.log
In the Clover plugin the report mojo is an aggregator
(http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java).
It also spawns a forked lifecycle:
{code}
* @execute phase=test lifecycle=clover
* @aggregator
{code}
When I run this clover report on the Cargo API module, which contains
children modules, all the modules are executed several times as shown in the
attached logs. They should be executed only once. The @aggregator is supposed
to execute only once and it executes several times.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2184) Possible problem with @aggregator and forked lifecycles
[
http://jira.codehaus.org/browse/MNG-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122851
]
John Casey commented on MNG-2184:
-
619720 improves the logic of skipping vs. warning of deprecation (deprecated to
bind aggregator mojos to the lifecycle now), to prevent printing a warning
message when the mojo will be skipped.
Possible problem with @aggregator and forked lifecycles
---
Key: MNG-2184
URL: http://jira.codehaus.org/browse/MNG-2184
Project: Maven 2
Issue Type: Bug
Components: Design, Patterns Best Practices, Plugins and Lifecycle
Affects Versions: 2.0.3
Environment: Revision 974 of Cargo
(https://svn.codehaus.org/cargo/cargo/trunk/core/api/)
Reporter: Vincent Massol
Assignee: John Casey
Priority: Blocker
Fix For: 2.1
Attachments: cargo.log
In the Clover plugin the report mojo is an aggregator
(http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java).
It also spawns a forked lifecycle:
{code}
* @execute phase=test lifecycle=clover
* @aggregator
{code}
When I run this clover report on the Cargo API module, which contains
children modules, all the modules are executed several times as shown in the
attached logs. They should be executed only once. The @aggregator is supposed
to execute only once and it executes several times.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2184) Possible problem with @aggregator and forked lifecycles
[
http://jira.codehaus.org/browse/MNG-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122853
]
John Casey commented on MNG-2184:
-
thinking about this more, if an aggregator mojo is bound simultaneously to two
module poms in the same reactor, where should it execute? If it's bound to a
pom at all, then merely the root location of the reactor may change whether the
aggregator runs or not, using the logic from revId: 619721.
I'm commenting that code out until I can think about this more, and come up
with something. I really think the safest solution may be to prohibit
aggregators in the lifecycle at all.
Possible problem with @aggregator and forked lifecycles
---
Key: MNG-2184
URL: http://jira.codehaus.org/browse/MNG-2184
Project: Maven 2
Issue Type: Bug
Components: Design, Patterns Best Practices, Plugins and Lifecycle
Affects Versions: 2.0.3
Environment: Revision 974 of Cargo
(https://svn.codehaus.org/cargo/cargo/trunk/core/api/)
Reporter: Vincent Massol
Assignee: John Casey
Priority: Blocker
Fix For: 2.1
Attachments: cargo.log
In the Clover plugin the report mojo is an aggregator
(http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java).
It also spawns a forked lifecycle:
{code}
* @execute phase=test lifecycle=clover
* @aggregator
{code}
When I run this clover report on the Cargo API module, which contains
children modules, all the modules are executed several times as shown in the
attached logs. They should be executed only once. The @aggregator is supposed
to execute only once and it executes several times.
--
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-452) suitename always = TestSuite even if suitename defined as property
[
http://jira.codehaus.org/browse/SUREFIRE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122859
]
Dan Fabulich commented on SUREFIRE-452:
---
I reproduce the problem, but I find that the integration test
TestNgSuiteXmlTest fails when I apply this patch:
{noformat}
org.apache.maven.surefire.booter.SurefireExecutionException:
org.apache.maven.surefire.testng.TestNGXmlTestSuite; nested exception is
java.lang.ClassCastException:
org.apache.maven.surefire.testng.TestNGXmlTestSuite
java.lang.ClassCastException:
org.apache.maven.surefire.testng.TestNGXmlTestSuite
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.startTestSuite(TestNGDirectoryTestSuite.java:166)
at
org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:91)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
{noformat}
suitename always = TestSuite even if suitename defined as property
--
Key: SUREFIRE-452
URL: http://jira.codehaus.org/browse/SUREFIRE-452
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4, 2.4.1
Environment: Maven version: 2.0.8
Java version: 1.5.0_14
OS name: windows xp version: 5.1 arch: x86 Family: windows
and also on Linux
Reporter: Erez Nahir
Attachments: TestNGDirectoryTestSuite.java
Using surefire and testng with no testng.xml but with cofiguration, the
generated standard output xml always have suite name=TestSuite.
This is an issue while using CruiseControl and JUnitReport to generate a
JUnit report.
Here is the configuration in my pom file:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.1/version
configuration
testFailureIgnoretrue/testFailureIgnore
groupsfast/groups
excludedgroupsbroken/excludedgroups
properties
property
namesuitename/name
value${artifactId}/value
/property
property
nametestname/name
value${artifactId}/value
/property
/properties
/configuration
/plugin
There is an attached patch too.
--
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-452) suitename always = TestSuite even if suitename defined as property
[
http://jira.codehaus.org/browse/SUREFIRE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-452:
--
Fix Version/s: 2.x
Targeting for 2.x (this won't block 2.4.2 coming out) but if you can provide
another patch that passes the tests, I'll probably accept it.
suitename always = TestSuite even if suitename defined as property
--
Key: SUREFIRE-452
URL: http://jira.codehaus.org/browse/SUREFIRE-452
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4, 2.4.1
Environment: Maven version: 2.0.8
Java version: 1.5.0_14
OS name: windows xp version: 5.1 arch: x86 Family: windows
and also on Linux
Reporter: Erez Nahir
Fix For: 2.x
Attachments: TestNGDirectoryTestSuite.java
Using surefire and testng with no testng.xml but with cofiguration, the
generated standard output xml always have suite name=TestSuite.
This is an issue while using CruiseControl and JUnitReport to generate a
JUnit report.
Here is the configuration in my pom file:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.1/version
configuration
testFailureIgnoretrue/testFailureIgnore
groupsfast/groups
excludedgroupsbroken/excludedgroups
properties
property
namesuitename/name
value${artifactId}/value
/property
property
nametestname/name
value${artifactId}/value
/property
/properties
/configuration
/plugin
There is an attached patch too.
--
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: (SUREFIRE-451) ManifestJarWriter should use java.util.jar.Manifest
[ http://jira.codehaus.org/browse/SUREFIRE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-451. - Resolution: Fixed Fix Version/s: (was: 2.x) 2.4.2 Fixed in revision 619732, because some users reported getting Failed to load Main-Class manifest attribute errors until they extracted the manifest, re-processed it and re-packed it. http://www.nabble.com/-ANN--Maven-Surefire-Plugin-2.4.1-for-Maven-2-Released-td15307389s177.html ManifestJarWriter should use java.util.jar.Manifest --- Key: SUREFIRE-451 URL: http://jira.codehaus.org/browse/SUREFIRE-451 Project: Maven Surefire Issue Type: Improvement Components: process forking Reporter: Dan Fabulich Fix For: 2.4.2 ManifestJarWriter manages writing the manifest by hand, including wrapping lines, etc. etc. This code was copied from plexus-archiver when we stopped depending on plexus-archiver. But AFAIK there's no reason to do that by hand; java.util.jar.Manifest can take care of all of that for us. Still, it's creepy that they did all of that work, so maybe there was a good reason for it...? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-453) unable to run spring/jpa/dao test with derby starting with surefire 2.4.x
unable to run spring/jpa/dao test with derby starting with surefire 2.4.x - Key: SUREFIRE-453 URL: http://jira.codehaus.org/browse/SUREFIRE-453 Project: Maven Surefire Issue Type: Bug Components: plugin Affects Versions: 2.4 Reporter: Dan Tran Attachments: mytest-sources.jar here is the description reported on user list This may not be a blocking bug but It is a regresion since 2.4 where my Spring JpaDao with embedded Derby test fails . Other databases are fine. The exception is producable with 2.5-SNAPSHOT ( build from source ), 2.4.1-SNAPSHOT( at apache snapshot repo). surefire 2.3 and 2.3.1 are fine. Any one else encounter this issue? -D --- Test set: com.iplocks.user.dao.UserDaoJpaTest --- Tests run: 7, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 14.111 sec FAILURE! testNamedConstraint(com.iplocks.user.dao.UserDaoJpaTest) Time elapsed: 0.281 sec ERROR! javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute query at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:630) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:75) at com.iplocks.jpa.GenericNameDaoJpa.getByName(GenericNameDaoJpa.java:54) at com.iplocks.user.dao.UserDaoJpaTest.createUser(UserDaoJpaTest.java:35) at com.iplocks.user.dao.UserDaoJpaTest.createDefaultUser(UserDaoJpaTest.java:56) at com.iplocks.user.dao.UserDaoJpaTest.testNamedConstraint(UserDaoJpaTest.java:77) Caused by: org.hibernate.exception.GenericJDBCException: could not execute query at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.loader.Loader.doList(Loader.java:2223) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:66) ... 38 more Caused by: java.sql.SQLException: Cannot create an instance of generated class org.apache.derby.exe.ac12564092x0117xc31cx8752x0020b5f01. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Please run mvn test using the attached maven project. to run with different db, change resources.properties accordingly -- 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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122874 ] Stephane Nicoll commented on MWAR-141: -- right. I don't know what's happening. maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1-alpha-2 It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2184) Possible problem with @aggregator and forked lifecycles
[
http://jira.codehaus.org/browse/MNG-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122875
]
Brian Fox commented on MNG-2184:
We need to support aggregators in the lifecycle, i'm convinced of that, but
they should only run at the root of the execution, just like its done from the
cli.
Possible problem with @aggregator and forked lifecycles
---
Key: MNG-2184
URL: http://jira.codehaus.org/browse/MNG-2184
Project: Maven 2
Issue Type: Bug
Components: Design, Patterns Best Practices, Plugins and Lifecycle
Affects Versions: 2.0.3
Environment: Revision 974 of Cargo
(https://svn.codehaus.org/cargo/cargo/trunk/core/api/)
Reporter: Vincent Massol
Assignee: John Casey
Priority: Blocker
Fix For: 2.1
Attachments: cargo.log
In the Clover plugin the report mojo is an aggregator
(http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java).
It also spawns a forked lifecycle:
{code}
* @execute phase=test lifecycle=clover
* @aggregator
{code}
When I run this clover report on the Cargo API module, which contains
children modules, all the modules are executed several times as shown in the
attached logs. They should be executed only once. The @aggregator is supposed
to execute only once and it executes several times.
--
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: (MWAR-141) maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2
[ http://jira.codehaus.org/browse/MWAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-141. Resolution: Fixed Done. Hope it's ok now. maven-metadata.xml is not being updated with latest snapshots for 2.1-alpha-2 - Key: MWAR-141 URL: http://jira.codehaus.org/browse/MWAR-141 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Allen Servedio Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1-alpha-2 It appears that the http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-metadata.xml file is not getting updated upon each snapshot release. For systems (like Artifactory) that depend on the data in this file, they are not pulling down the latest snapshot. It should be referencing this snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-war-plugin/2.1-alpha-2-SNAPSHOT/maven-war-plugin-2.1-alpha-2-20080207.184539-4.jar So, it should look something like this: metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1-alpha-2-SNAPSHOT/version versioning snapshot timestamp20080207.184539/timestamp buildNumber4/buildNumber /snapshot lastUpdated20080207184539/lastUpdated /versioning /metadata -- 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: (MCHANGES-78) Build a changes report by parsing svn comments
[ http://jira.codehaus.org/browse/MCHANGES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122877 ] Emmanuel Hugonnet commented on MCHANGES-78: --- Thank you Dennis, this is a constructive remark :o) I agree with you that why I contacted both teams. The changes.xml is maintained by hand and I think that is far easier as a developer to add more comments to my scm commit than to edit afterwards an xml file to add an entry and then commit it. If your opinion is Just ask the issue tracker directly then why does the changes plugin exist ? Isn't it its goal to provide such a report ? (By the way I notice that most of the teams use JIRA report when they release a new version and not the changes-plugin). I agree, an improvement would be to fetch the issue comments in the tracker ( version 2.0 ? ) . I accept your opinion, even if I have 3 teams using it here ;o) (maybe because we don't have JIRA). But why people asked for modifications (like jdk version, scm-api,package, ...) instead of just stating the fact that they don't think it's a good idea ? Build a changes report by parsing svn comments -- Key: MCHANGES-78 URL: http://jira.codehaus.org/browse/MCHANGES-78 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Emmanuel Hugonnet Priority: Minor Attachments: site.tar.gz, svn-changelog-plugin-jdk1.4.tar.gz, svn-changelog-plugin.tar.gz, svnchangelog-plugin-jdk1.4.tar.gz Builds a changes report by parsing svn comments. You can configure this plugin as any reporting plugin. But it has specific configuration parameters : * grammar : this allows you to specify the grammar used to parse the svn logs. Currently it supports two grammars : o MANU which uses @operation:issue; o REMY with [operation:issue] * trackerType : this allows you to specify the issue tracker used. Currently it supports two trackers : o codex o jira * trackerUrlPattern : this allows you to specify a pattern to link an issue to any tracker. -- 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
