[jira] Commented: (SUREFIRE-449) In multi-module projects, all tests are run for each module in the module tree
[ http://jira.codehaus.org/browse/SUREFIRE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122546 ] Stefan Seidel commented on SUREFIRE-449: Thanks for investigating, Dan. I don't know much about maven plugin dev, but I suspected something like that. Would you agree that this is a serious flaw in maven core? I mean, would it ever make sense to execute a plugin in that way only because it has that @aggregator annotation? I think the same issue (with @aggregator) could be the cause for MJAVADOC-171. I just don't know enough to report this more general bug, but maybe you or someone from the team could? In multi-module projects, all tests are run for each module in the module tree -- Key: SUREFIRE-449 URL: http://jira.codehaus.org/browse/SUREFIRE-449 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.4 Environment: Maven 2.0.8, Linux Reporter: Stefan Seidel Priority: Blocker Fix For: 2.4.2 Attachments: mvnexec.zip In a multi-module project, since version 2.4, all tests of all modules are run once for each module. This is *very* bad with many modules many tests. Attached is a sample project which contains a parent module and two child modules. Each of the child modules contains one JUnit test. mvn clean site runs each test three times (once for the parent and once for each of the two submodules). When changing the surefire-report-plugin to version 2.3, each test is run only once, as it is supposed to -- 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-139) Wrong token replacement (@@ is replaced with [EMAIL PROTECTED])
[ http://jira.codehaus.org/browse/MWAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122558 ] Olivier Lamy commented on MWAR-139: --- Hi, As it's a shared component there isn't dedicated Jira project but there is a component entry (maven-filtering) in MNG. Wrong token replacement (@@ is replaced with [EMAIL PROTECTED]) Key: MWAR-139 URL: http://jira.codehaus.org/browse/MWAR-139 Project: Maven 2.x War Plugin Issue Type: Bug Environment: Linux 2.6 Reporter: Jan Torben Heuer Assignee: Olivier Lamy Priority: Critical Fix For: 2.1-alpha-2 Attachments: mavenbug.tar.gz maven replaces the String @@ in resources with [EMAIL PROTECTED] I enabled filtering for the resources and my variables are correctly replaced. Jan -- 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-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122567
]
Vincent Siveton commented on MJAVADOC-116:
--
Damien, did you call mvn site or mvn javadoc:javadoc?
Could you send us a log with -X?
Impossible to aggregate javadoc if snapshot never built
---
Key: MJAVADOC-116
URL: http://jira.codehaus.org/browse/MJAVADOC-116
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Damien Lecan
Assignee: Vincent Siveton
Fix For: 2.4
Attachments: javadoc-plugin-test-case.zip
In a multi-module projet, I build an aggregated Javadoc for the site.
The project is built with mvn clean deploy site-deploy
When I add a new project, the next build always fails because the javadoc
plugin can't find at least one snapshot for the new added module
In the following example, I added a new module tele.persistance:pers-commons,
which have never been built before.
Maven tries to download it but it can't find it (never build before).
{noformat} [INFO] [site:site]
[WARNING] Unable to load parent project from repository: Could not find the
model file '/continuum-folders/working-directory/116/../pom.xml'.
[INFO] Skipped About report, file index.html already exists for the
English version.
[ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
[ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
[INFO] Generate JavaDocs report.
[INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
from mirror.snapshots
[INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
for updates from mirror.snapshots
[INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
for updates from mirror.snapshots
[INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
checking for updates from mirror.snapshots
Downloading:
http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
[WARNING] Unable to get resource
'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
mirror.snapshots (http://proxy/maven2-snapshots/repository)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=tele.persistance
-DartifactId=pers-commons \
-Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file
Path to dependency:
1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
--
1 required artifact is missing.
for artifact:
tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
mirror.snapshots (http://proxy/maven2-snapshots/repository)
{noformat}
If I make an intermediate install, everything works fine
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3385) PluginManagement does not work for report-plugins
[ http://jira.codehaus.org/browse/MNG-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122571 ] Vincent Siveton commented on MNG-3385: -- I guess reportingreportingManagement//reporting should be better PluginManagement does not work for report-plugins - Key: MNG-3385 URL: http://jira.codehaus.org/browse/MNG-3385 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.8 Reporter: Andreas Höhmann build ... /pluginManagement plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version2.2/version /plugin /plugins /pluginManagement ... /build reporting plugins plugin artifactIdmaven-pmd-plugin/artifactId /plugin /plugins /reporting mvn site ... use pmd-2.4-SNAPSHOT instead of the defined 2.2 ... why? -- 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: (MJAVADOC-174) Fix hyperlink to reference doc for mojo parameter use
[ http://jira.codehaus.org/browse/MJAVADOC-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-174. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 Applied. Thanks! Fix hyperlink to reference doc for mojo parameter use --- Key: MJAVADOC-174 URL: http://jira.codehaus.org/browse/MJAVADOC-174 Project: Maven 2.x Javadoc Plugin Issue Type: Task Affects Versions: 2.3 Reporter: Benjamin Bentmann Assignee: Vincent Siveton Priority: Trivial Fix For: 2.4 Attachments: javadoc-use-option.patch A little typo in the href of the a element. -- 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-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122577
]
Damien Lecan commented on MJAVADOC-116:
---
did you call mvn site or mvn javadoc:javadoc?
mvn -DreleaseProfile=true clean deploy site-deploy
So both site and javadoc:javadoc together.
Log file is coming...
Impossible to aggregate javadoc if snapshot never built
---
Key: MJAVADOC-116
URL: http://jira.codehaus.org/browse/MJAVADOC-116
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Damien Lecan
Assignee: Vincent Siveton
Fix For: 2.4
Attachments: javadoc-plugin-test-case.zip
In a multi-module projet, I build an aggregated Javadoc for the site.
The project is built with mvn clean deploy site-deploy
When I add a new project, the next build always fails because the javadoc
plugin can't find at least one snapshot for the new added module
In the following example, I added a new module tele.persistance:pers-commons,
which have never been built before.
Maven tries to download it but it can't find it (never build before).
{noformat} [INFO] [site:site]
[WARNING] Unable to load parent project from repository: Could not find the
model file '/continuum-folders/working-directory/116/../pom.xml'.
[INFO] Skipped About report, file index.html already exists for the
English version.
[ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
[ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
[INFO] Generate JavaDocs report.
[INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
from mirror.snapshots
[INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
for updates from mirror.snapshots
[INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
for updates from mirror.snapshots
[INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
checking for updates from mirror.snapshots
Downloading:
http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
[WARNING] Unable to get resource
'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
mirror.snapshots (http://proxy/maven2-snapshots/repository)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=tele.persistance
-DartifactId=pers-commons \
-Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file
Path to dependency:
1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
--
1 required artifact is missing.
for artifact:
tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
mirror.snapshots (http://proxy/maven2-snapshots/repository)
{noformat}
If I make an intermediate install, everything works fine
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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_122580 ] Niall Pemberton commented on MCHANGES-78: - This is for a whole new plugin - rather than a changes to the maven-changes-plugin? Because this JIRA project is for the Apache maven project's maven-changes-plugin. If you want to donate it to either to Apache maven or to codehaus (its packaged as codehaus) then you probably either need to file an issue ticket somewhere else or raise/propose it on a mailing list. If its for Apache maven then it also needs to be re-packaged as org.apache.maven, license headers added to the source files and all the francetelecom references removed. 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: (ARCHETYPE-55) Maven archetype plugin ignores system properties
[ http://jira.codehaus.org/browse/ARCHETYPE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122584 ] gonzo commented on ARCHETYPE-55: When will this patch make it into a final release? I hate patching for such things. Or am I getting something wrong here? Maven archetype plugin ignores system properties Key: ARCHETYPE-55 URL: http://jira.codehaus.org/browse/ARCHETYPE-55 Project: Maven Archetype Issue Type: New Feature Components: Plugin Affects Versions: 1.0-alpha-4 Reporter: Ceki Gulcu Priority: Critical Attachments: optional-system-properties-v2.diff, optional-system-properties.diff When it passes a property map to velocity context, the archetype plugin passes the values of the properties basedir, package, packageName, groupId, artifactId, and version ignoring other properties, in particular system properties. In the context of our project, we would like the archetype plugin to substitute the values of system properties during the file generation based on templates. It would take very little effort to add the system properties to the map passed to Velocity context. Moreover, only a single file, namely MavenArchetypeMojo.java in maven-archetype-plugin/src/main/java/org/apache/maven/plugin/archetype/ need to be modified. As far as I understand it, the change can be accomplished with a single line of code: map.putAll(System.getProperties()); Would you consider adding the above line to MavenArchetypeMojo.java? Many thanks in advance, -- 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: (MASSEMBLY-139) Not all information from parent available in plugin?
[
http://jira.codehaus.org/browse/MASSEMBLY-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst Lindoorn closed MASSEMBLY-139.
Resolution: Fixed
Fix Version/s: (was: 2.2)
2.2-beta-1
Fix confirmed, closed report
Not all information from parent available in plugin?
Key: MASSEMBLY-139
URL: http://jira.codehaus.org/browse/MASSEMBLY-139
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Ernst Lindoorn
Fix For: 2.2-beta-1
Attachments: project.zip
In a multimodule project, it seems that not all information of the parent
project is passed (or otherwise available) in the assembly plugin.
Given the attached minimalist setup, I echo the project.parent.name / version
and project.name / version.
During mvn assembly:assembly it seems the project.parent.name variable is not
available, while the version is.
Output:
[echo] Outputting some variables
[echo] `- project.parent: ${project.parent.name} - 1.0-SNAPSHOT
[echo] `- project: Module Name - 0.5-SNAPSHOT
Instead of the expected:
[echo] Outputting some variables
[echo] `- project.parent: Project Name - 1.0-SNAPSHOT
[echo] `- project: Module Name - 0.5-SNAPSHOT
--
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-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Lecan updated MJAVADOC-116:
--
Attachment: log.txt
Log file for mvn -X -DreleaseProfile=true clean deploy site-deploy in
attachement.
Good luck
Impossible to aggregate javadoc if snapshot never built
---
Key: MJAVADOC-116
URL: http://jira.codehaus.org/browse/MJAVADOC-116
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Damien Lecan
Assignee: Vincent Siveton
Fix For: 2.4
Attachments: javadoc-plugin-test-case.zip, log.txt
In a multi-module projet, I build an aggregated Javadoc for the site.
The project is built with mvn clean deploy site-deploy
When I add a new project, the next build always fails because the javadoc
plugin can't find at least one snapshot for the new added module
In the following example, I added a new module tele.persistance:pers-commons,
which have never been built before.
Maven tries to download it but it can't find it (never build before).
{noformat} [INFO] [site:site]
[WARNING] Unable to load parent project from repository: Could not find the
model file '/continuum-folders/working-directory/116/../pom.xml'.
[INFO] Skipped About report, file index.html already exists for the
English version.
[ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
[ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
[INFO] Generate JavaDocs report.
[INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
from mirror.snapshots
[INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
for updates from mirror.snapshots
[INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
for updates from mirror.snapshots
[INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
checking for updates from mirror.snapshots
Downloading:
http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
[WARNING] Unable to get resource
'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
mirror.snapshots (http://proxy/maven2-snapshots/repository)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=tele.persistance
-DartifactId=pers-commons \
-Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file
Path to dependency:
1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
--
1 required artifact is missing.
for artifact:
tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
mirror.snapshots (http://proxy/maven2-snapshots/repository)
{noformat}
If I make an intermediate install, everything works fine
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-414) Don't queue a request to scan a repository that is currently being scanned
[ http://jira.codehaus.org/browse/MRM-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MRM-414. --- Resolution: Fixed Fix Version/s: (was: 1.1) 1.0.1 This has already been fixed. In 1.0.1 if I click Scan Repository Now twice, I see the following in the log: [ActionError] Repository [snapshots] task was already queued. Don't queue a request to scan a repository that is currently being scanned -- Key: MRM-414 URL: http://jira.codehaus.org/browse/MRM-414 Project: Archiva Issue Type: Improvement Components: indexing Affects Versions: 1.0-alpha-1 Reporter: Wendy Smoak Priority: Minor Fix For: 1.0.1 If a repository is currently being scanned when the 'Scan Repository Now' button is clicked, don't queue another request to scan it. Example: INFO | jvm 1| 2007/06/10 21:00:09 | 728900 [SocketListener0-1] INFO com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your request to have repository [central] be indexed has been queued. INFO | jvm 1| 2007/06/10 21:00:09 | 728902 [pool-2-thread-1] INFO org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning - Executing task from queue with job name: repository-job:central INFO | jvm 1| 2007/06/10 21:00:09 | 728928 [pool-2-thread-1] INFO org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Walk Started: [central] file:/opt/central-repository/ INFO | jvm 1| 2007/06/10 21:01:08 | 788035 [SocketListener0-1] INFO com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your request to have repository [central] be indexed has been queued. -- 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-3386) Specific dependencies list makes the embedder to set 'varsionRange' for one of them to 'null'
Specific dependencies list makes the embedder to set 'varsionRange' for one of
them to 'null'
-
Key: MNG-3386
URL: http://jira.codehaus.org/browse/MNG-3386
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.1
Reporter: Anton Makeev
Priority: Minor
For the following project the embedder resolves a transitive dependency of
'ws-commons-util' named 'xml-apis:xml-apis:jar:1.0.b2:compile' and sets its
'versionRange' into null. I dunno wheither it's a bug or intended behaviour,
but changing the order of dependencies or removing 'dom4j' seems to solve the
problem.
{code}
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
groupIdtest/groupId
artifactIdproject/artifactId
version1/version
dependencies
dependency
groupIddom4j/groupId
artifactIddom4j/artifactId
version1.6.1/version
scoperuntime/scope
/dependency
dependency
groupIdorg.apache.ws.commons.util/groupId
artifactIdws-commons-util/artifactId
version1.0.2/version
/dependency
/dependencies
/project
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-98) Add paging capatibility to changes report
Add paging capatibility to changes report - Key: MCHANGES-98 URL: http://jira.codehaus.org/browse/MCHANGES-98 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: changes-report Affects Versions: 2.0-beta-3 Reporter: Benjamin Bentmann The current report generation does not scale well for projects with a large release history because one ends up with a very long HTML page. Preferable would be to introduce a configuration parameter like releasesPerPage that the mojo could use to split up the change log onto several web pages. Usually, such paging should only apply to web content and not something like PDF or other print-related formats. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3354) mvn.bat incorrectly detects OS on Windows NT or XP with Novell login
[ http://jira.codehaus.org/browse/MNG-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3354: Assignee: John Casey mvn.bat incorrectly detects OS on Windows NT or XP with Novell login Key: MNG-3354 URL: http://jira.codehaus.org/browse/MNG-3354 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.8 Reporter: Jaroslaw Bojar Assignee: John Casey Fix For: 2.0.9, 2.1-alpha-1 Attachments: mvn.bat, mvnDebug.bat On Windows NT or XP with Novell Client Login mvn.bat incorrectly selects OS as Win9x, because Novell sets OS environment variable to WINNT instead of Windows_NT. As a result it processes command line arguments as in windows 9x, what is very inconvenient because all arguments with = (equals) sign must be quoted on command line. For example -DdownloadSources=true must be quoted as -DdownloadSources=true. The reason for such behaviour is that mvn.bat checks in several places if %OS%==Windows_NT and this statement yields false on windows with novell login. On winnt with novell login OS is set to WINNT instead of Windows_NT. I attached corrected mvn.bat and mvnDebug.bat that check additionally for %OS%==WINNT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3296) mvn.bat looses error code on windows NT type platforms
[ http://jira.codehaus.org/browse/MNG-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3296. --- Resolution: Fixed applied the fix in the description. Thanks. Incidentally, I don't have a copy of windows here, so if someone could try this and reopen it if it doesn't work, I'd appreciate it! mvn.bat looses error code on windows NT type platforms -- Key: MNG-3296 URL: http://jira.codehaus.org/browse/MNG-3296 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.7 Reporter: Matthias Kerkhoff Assignee: John Casey Fix For: 2.0.9, 2.1-alpha-1 There is a bug in the mvn.bat script that prevents that an error code is properly returned to the caller of the script. The batch script executes the following lines after maven has been invoked if an error occurs: if ERRORLEVEL 1 goto error :error set ERROR_CODE=1 :end if %OS%==Windows_NT goto endNT :endNT @endlocal if exist %HOME%\mavenrc_post.bat call %HOME%\mavenrc_post.bat if %MAVEN_BATCH_PAUSE% == on pause if %MAVEN_TERMINATE_CMD% == on exit %ERROR_CODE% exit /B %ERROR_CODE% The problem is the endlocal statement. Calling endlocal ends the scope in which ERROR_CODE was set to 1. The previous value of ERROR_CODE will be reinstantiated (which is always 0, see line 46). To fix the problem make the ERROR_CODE value known in the outer (global) scope by changing the endlocal statement into @endlocal set ERROR_CODE=%ERROR_CODE% -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2178) incorrect M2_HOME guess in mvn.bat
[ http://jira.codehaus.org/browse/MNG-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-2178. --- Resolution: Fixed I can't actually test this fix, so if someone finds that it's still not working, reopen this. incorrect M2_HOME guess in mvn.bat -- Key: MNG-2178 URL: http://jira.codehaus.org/browse/MNG-2178 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.2 Environment: WXP Reporter: Jörg Henne Assignee: John Casey Fix For: 2.0.9, 2.1-alpha-1 mvn.bat contains the following lines: :chkMHome if not %M2_HOME%== goto valMHome if %OS%==Windows_NT SET M2_HOME=%~dps0\.. if not %M2_HOME%== goto valMHome Guessing M2_HOME=%~dps0\.. leads to complaints later on, since the script expects m2.bat in bin/...: if exist %M2_HOME%\bin\m2.bat goto init Hence, the line should read: if %OS%==Windows_NT SET M2_HOME=%~dps0\..\.. -- 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-3387) Enforce redeployment for deploy phase
Enforce redeployment for deploy phase - Key: MNG-3387 URL: http://jira.codehaus.org/browse/MNG-3387 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.1 Reporter: Martin Buechler Is there a possibility to enforce the redeployment of an artefact during the build? I get the message 'The artifact xxx has already been deployed. Not deploying again.' Yes, it exists but I want to replace it. There is difference in behaviour of the m2eclipse plugin to the current cli versions 2.0.x. see http://www.nabble.com/Enforce-redeployment-during-Build-td14997988s177.html Brian E Fox said there: This was added to 2.1, it won't happen in 2.0.x. A flag to force it needs to be added to the interface and to the deploy plugin, and it should be backported to 2.0. Can you write a jira? Done. -- 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-1926) add org.wickettools.extjs to automatically synced repositories
add org.wickettools.extjs to automatically synced repositories -- Key: MAVENUPLOAD-1926 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1926 Project: maven-upload-requests Issue Type: Task Reporter: Jeremy Fergason Attachments: org.wickettools.extjs.sh Please add the org.wicettools.extjs to the list of automatically synched repositories. Here's proof of domain ownership: NOTICE: Access to .ORG WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to: (a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations. All rights reserved. Public Interest Registry reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. Domain ID:D150589766-LROR Domain Name:WICKETTOOLS.ORG Created On:09-Jan-2008 02:08:47 UTC Expiration Date:09-Jan-2009 02:08:47 UTC Sponsoring Registrar:OnlineNIC Inc. (R64-LROR) Status:TRANSFER PROHIBITED Registrant ID:ONLC-3128647-4 Registrant Name:Jeremy Fergason Registrant Organization:Corwynn Technology Registrant Street1: Registrant Street2: Registrant Street3: Registrant City: Registrant State/Province: Registrant Postal Code: Registrant Country: Registrant Phone: Registrant Phone Ext.: Registrant FAX:+1.5207956998 Registrant FAX Ext.: Registrant Email:[EMAIL PROTECTED] Admin ID:ONLC-3128647-1 Admin Name:Jeremy Fergason Admin Organization:Corwynn Technology Admin Street1: Admin Street2: Admin Street3: Admin City: Admin State/Province: Admin Postal Code: Admin Country: Admin Phone: Admin Phone Ext.: Admin FAX:+1.5207956998 Admin FAX Ext.: Admin Email:[EMAIL PROTECTED] Tech ID:ONLC-3128647-2 Tech Name:Jeremy Fergason Tech Organization:Corwynn Technology Tech Street1: Tech Street2: Tech Street3: Tech City: Tech State/Province: Tech Postal Code: Tech Country:US Tech Phone: Tech Phone Ext.: Tech FAX:+1.5207956998 Tech FAX Ext.: Tech Email:[EMAIL PROTECTED] Name Server:NS1.DNS-DIY.NET Name Server:NS2.DNS-DIY.NET Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1491) Reactor should print out a message if it detects a collision of artifact ids
[ http://jira.codehaus.org/browse/MNG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-1491. --- Assignee: John Casey Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.1-alpha-1 2.0.9 I've checked this both in 2.1-SNAPSHOT (trunk) and in 2.0.9-SNAPSHOT (2.0.x branch) and it fails with an error citing uniqueness problems in both cases. the error in 2.1-snap even tells you which two files produced the problem. Reactor should print out a message if it detects a collision of artifact ids Key: MNG-1491 URL: http://jira.codehaus.org/browse/MNG-1491 Project: Maven 2 Issue Type: Wish Components: Plugins and Lifecycle Reporter: Anuerin Diaz Assignee: John Casey Priority: Trivial Fix For: 2.0.9, 2.1-alpha-1 It might be a good idea to have the Reactor print out a warning message if it detects similar artifact IDs (copy and paste problem) when scanning for the build order at the start of the build. Currently, there are no messages shown in the screen even if -X is used. -- 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-3078) artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository
[ http://jira.codehaus.org/browse/MNG-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122674 ] Ian Springer commented on MNG-3078: --- I'm seeing this same issue w/ Maven 2.0.8 and an artifact with type tgz (rather than tar.gz). Here's a snippet from the mvn output: [INFO] Downloading: http://repository.jboss.org/maven2//org/hyperic/sigar-dist/1.5.0.1/sigar-dist-1.5.0.1.pom 1K downloaded Downloading: http://repository.jboss.org/maven2//org/hyperic/sigar-dist/1.5.0.1/sigar-dist-1.5.0.1.tgz 2659K downloaded Downloading: http://repo1.maven.org/maven2/org/hyperic/sigar-dist/1.5.0.1/sigar-dist-1.5.0.1.tgz [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.hyperic:sigar-dist:tgz:1.5.0.1 ... artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository - Key: MNG-3078 URL: http://jira.codehaus.org/browse/MNG-3078 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Dependencies Affects Versions: 2.0.6, 2.0.7 Reporter: Peter Lynch Priority: Critical Fix For: 2.0.x Using mvn deploy:deploy-file you can successfully upload a 'tar.gz' artifact to a repository. Example without classifier: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat -Dversion=6.0.13 -Dpackaging=tar.gz -DrepositoryId=repo-central -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ -Dfile=apache-tomcat-6.0.13.tar.gz Example with classifier mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat -Dversion=6.0.13 -Dpackaging=tar.gz -Dclassifier=bin -DrepositoryId=repo-central -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ -Dfile=apache-tomcat-6.0.13.tar.gz Once uploaded define a dependency in your pom to it. Example without classifier project packagingpom/packaging ... dependencies ... dependency groupIdorg.apache.tomcat/groupId artifactIdapache-tomcat/artifactId version6.0.13/version typetar.gz/type optionaltrue/optional /dependency ... /dependencies ... /project Example with classifier project packagingpom/packaging ... dependencies ... dependency groupIdorg.apache.tomcat/groupId artifactIdapache-tomcat/artifactId version6.0.13/version typetar.gz/type classifierbin/classifier optionaltrue/optional /dependency ... /dependencies ... /project Now to reproduce the problem you could either do mvn dependency:resolve or mvn assembly:assembly (if the maven assembly plugin is configured with a dependency set that unpacks this dependency for example) The reason I think this is a core bug and not an maven assembly plugin or maven-dependency-plugin bug is because the problem happens in both of these independent plugins. When you run 'mvn dependency:resolve' you'll see that the dependency appears downloaded but then the build fails with : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat \ -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat \ -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.example:core:pom:1.0.0-A1-SNAPSHOT 2) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 -- 1 required artifact is missing. ... ... and even stranger here is the log which proves the dependency was found in the repo and downloaded, but NOT saved to local repository. ... [DEBUG] Trying repository repo-central Downloading: http://repo.example.com:4000/maven-repos/repo-central/org/apache/tomcat/apache-tomcat/6.0.13/apache-tomcat-6.0.13-bin.tar.gz 5826K downloaded [DEBUG] Unable to get resource
[jira] Closed: (MWAR-139) Wrong token replacement (@@ is replaced with [EMAIL PROTECTED])
[ http://jira.codehaus.org/browse/MWAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-139. - Resolution: Fixed fixed in maven-filtering rev 619165. Wrong token replacement (@@ is replaced with [EMAIL PROTECTED]) Key: MWAR-139 URL: http://jira.codehaus.org/browse/MWAR-139 Project: Maven 2.x War Plugin Issue Type: Bug Environment: Linux 2.6 Reporter: Jan Torben Heuer Assignee: Olivier Lamy Priority: Critical Fix For: 2.1-alpha-2 Attachments: mavenbug.tar.gz maven replaces the String @@ in resources with [EMAIL PROTECTED] I enabled filtering for the resources and my variables are correctly replaced. Jan -- 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-3125) XML Schema for maven-metadata.xml
[ http://jira.codehaus.org/browse/MNG-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122683 ] Ian Springer commented on MNG-3125: --- The attached schema doesn't include the snapshot, release, and latest elements, which are described by http://docs.codehaus.org/display/MAVEN/Repository+Metadata and found in quite a few maven-metadata.xml files that I have seen. XML Schema for maven-metadata.xml - Key: MNG-3125 URL: http://jira.codehaus.org/browse/MNG-3125 Project: Maven 2 Issue Type: New Feature Components: Artifacts and Repositories Reporter: Ole Ersoy Priority: Minor Fix For: 2.x Attachments: maven-metadata-v1_0_0.xsd, maven-metadata-v2_0_0.xsd, maven-metadata.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-102) Upgrade maven-archiver dependency to 2.3
[ http://jira.codehaus.org/browse/MWAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MWAR-102: -- Assignee: Olivier Lamy Fix Version/s: 2.1-alpha-2 Summary: Upgrade maven-archiver dependency to 2.3 (was: Upgrade maven-archiver dependency to 2.3-SNAPSHOT) Upgrade maven-archiver dependency to 2.3 Key: MWAR-102 URL: http://jira.codehaus.org/browse/MWAR-102 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Jochen Wiedmann Assignee: Olivier Lamy Fix For: 2.1-alpha-2 Making use of MNG-2854 should increase the plugins performance. -- 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-102) Upgrade maven-archiver dependency to 2.3
[ http://jira.codehaus.org/browse/MWAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122686 ] Olivier Lamy commented on MWAR-102: --- fixed in rev 619184. Upgrade maven-archiver dependency to 2.3 Key: MWAR-102 URL: http://jira.codehaus.org/browse/MWAR-102 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Jochen Wiedmann Assignee: Olivier Lamy Fix For: 2.1-alpha-2 Making use of MNG-2854 should increase the plugins performance. -- 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-102) Upgrade maven-archiver dependency to 2.3
[ http://jira.codehaus.org/browse/MWAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-102. - Resolution: Fixed Upgrade maven-archiver dependency to 2.3 Key: MWAR-102 URL: http://jira.codehaus.org/browse/MWAR-102 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Jochen Wiedmann Assignee: Olivier Lamy Fix For: 2.1-alpha-2 Making use of MNG-2854 should increase the plugins performance. -- 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-1927) Please upload JCROM 1.0
Please upload JCROM 1.0 --- Key: MAVENUPLOAD-1927 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1927 Project: maven-upload-requests Issue Type: Wish Reporter: Olafur Gauti Gudmundsson http://jcrom.googlecode.com/files/jcrom-1.0-bundle.jar http://jcrom.org (forwards to the google-code page for JCROM) http://code.google.com/u/oli.gauti/ I am the project owner, please upload. -- 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-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122690 ] Dennis Lundberg commented on MCHANGES-88: - So if I understand this correctly, we really need a version maven-reporting-impl that uses the same version of doxia as this plugin does. In this case that is 1.0-alpha-9. Until that is available we need to work around this problem. Copy the execute() method from maven-reporting-impl and modify it so that it only uses doxia-methods that are available in 1.0-alpha-9. This has already been done in MPIR, so an alternative is to copy it from there. NoSuchMethodError with maven 2.0.8 when generating changes-report - Key: MCHANGES-88 URL: http://jira.codehaus.org/browse/MCHANGES-88 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.0-beta-3 Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn -version Maven version: 2.0.8 Java version: 1.6.0_03 OS name: linux version: 2.6.18-5-686 arch: i386 Family: unix Reporter: Julien Graglia Attachments: AbstractChangesReport.java, changes.log, changes.zip, error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log I create a simple maven2 project, but when i call mvn -X -e changes:changes-report I get an error (full log in attachment) java.lang.NoSuchMethodError: org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- 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-3346) Move logic inside AbstractProjectInfoReport to maven-reporting-impl
[ http://jira.codehaus.org/browse/MNG-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122692 ] Dennis Lundberg commented on MNG-3346: -- I think that I understand the problem now. Would you mind having a look over at MCHANGES-88 and see if it is this problem that we're hitting there? Move logic inside AbstractProjectInfoReport to maven-reporting-impl --- Key: MNG-3346 URL: http://jira.codehaus.org/browse/MNG-3346 Project: Maven 2 Issue Type: Improvement Components: Plugin API Affects Versions: 2.0.8 Reporter: Vincent Siveton Priority: Blocker Due to doxia:1.0-alpha-9, the following methods need to be a part of maven-reporting-impl: private File getSkinArtifactFile(); public void execute(); So, it should be more easy to create a new report 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-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122695 ] Olivier Lamy commented on MWAR-9: - Do we have to add the same feature as in the jar plugin ? With the flag http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#useDefaultManifestFile WAR plugin should support minimal WARs for inclusion within an EAR -- Key: MWAR-9 URL: http://jira.codehaus.org/browse/MWAR-9 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Mike Perham Assignee: Stephane Nicoll Attachments: AbstractWarMojo.patch I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my deps. This is fine for a default but maven should also support skeleton WARs which will be packaged within an EAR. We have EARs which package 3-4 WARs each and to have the deps duplicated within each WAR means we cannot have shared data (since the classes are loaded within each WAR's classloader, rather than by the parent EAR's classloader). It also means 80MB EARs! :-) It seems like two things need to happen: 1) Add a skeleton flag which prevents copying any dependencies to WEB-INF/lib. 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which lists the relative locations of the dependencies within the parent EAR. Fabrice has basically the same idea written down here. Starting with - for a War... : http://marc.theaimsgroup.com/?l=turbine-maven-userm=112737860024530w=2 -- 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-446) Surefire fails to capture TestNG results when forkMode=always
[
http://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-446:
--
Fix Version/s: (was: 2.4.2)
2.x
This is trickier than it looks... I'm not 100% certain that it even makes
sense to run TestNG with forkMode=always; it isn't necessarily safe to do so
(especially when tests depend on tests in other classes). [This certainly
explains how Benjamin found this bug... ;-)]
Ideally, TestNG would provide its own support for forkMode=always... Short of
that, it's hard to see how we can hack it into Surefire on top of the framework
that's already in place.
Surefire fails to capture TestNG results when forkMode=always
-
Key: SUREFIRE-446
URL: http://jira.codehaus.org/browse/SUREFIRE-446
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.4
Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
Fix For: 2.x
Attachments: testng-fork-mode-it.patch
The interplay between {{surefire.Surefire}} and
{{testng.TestNGDirectoryTestSuite}} does not properly notify the
ReportManager such that it reports 0 executed tests after the end of the day.
IT to reproduce attached.
Also confirmed against 2.5-SNAPSHOT.
--
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-446) Surefire fails to capture TestNG results when forkMode=always
[
http://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122701
]
Benjamin Bentmann commented on SUREFIRE-446:
bq. This certainly explains how Benjamin found this bug... ;-)
What should I say, I am just evil minded ;-)
bq. it isn't necessarily safe to do so
The same is true with running tests in parallel. If your test suite contains
non-thread-safe method calls, well, multi-threaded tests are a bad idea, too.
So, is Surefire going to drop its parameter parallel because an incompotent
user could make the tests errorneously fail? I wouldn't feel quite comfortable
with a build tool that restricts me from doing something just because it
*might* not work although - for a special use-case - it *will* work.
bq. Short of that, it's hard to see how we can hack it into Surefire on top of
the framework that's already in place.
Naively spoken, I would expect that forkMode=always behaves as if
{{TestNGDirectoryTestSuite}} found only a single test class.
Surefire fails to capture TestNG results when forkMode=always
-
Key: SUREFIRE-446
URL: http://jira.codehaus.org/browse/SUREFIRE-446
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.4
Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
Fix For: 2.x
Attachments: testng-fork-mode-it.patch
The interplay between {{surefire.Surefire}} and
{{testng.TestNGDirectoryTestSuite}} does not properly notify the
ReportManager such that it reports 0 executed tests after the end of the day.
IT to reproduce attached.
Also confirmed against 2.5-SNAPSHOT.
--
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-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122702 ] Niall Pemberton commented on MCHANGES-88: - Even when you get a compatible verson of maven-reporting-impl released it is still going to throw an exception though - just it will be a MojoExecutionException saying Reporting mojo's can only be called from ReportDocumentRender rather than a NoSuchMethodError. http://svn.apache.org/repos/asf/maven/shared/trunk/maven-reporting-impl/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java If thats considered correct maven practice and what this plugin will do once you get a maven-reporting-impl release then you may as well just implement an execute method that throws that exception now. But if however the report should work standalone though, then copying MPIR is the solution. NoSuchMethodError with maven 2.0.8 when generating changes-report - Key: MCHANGES-88 URL: http://jira.codehaus.org/browse/MCHANGES-88 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.0-beta-3 Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn -version Maven version: 2.0.8 Java version: 1.6.0_03 OS name: linux version: 2.6.18-5-686 arch: i386 Family: unix Reporter: Julien Graglia Attachments: AbstractChangesReport.java, changes.log, changes.zip, error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log I create a simple maven2 project, but when i call mvn -X -e changes:changes-report I get an error (full log in attachment) java.lang.NoSuchMethodError: org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- 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-449) In multi-module projects, all tests are run for each module in the module tree
[ http://jira.codehaus.org/browse/SUREFIRE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-449. - Resolution: Fixed In multi-module projects, all tests are run for each module in the module tree -- Key: SUREFIRE-449 URL: http://jira.codehaus.org/browse/SUREFIRE-449 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.4 Environment: Maven 2.0.8, Linux Reporter: Stefan Seidel Priority: Blocker Fix For: 2.4.2 Attachments: mvnexec.zip In a multi-module project, since version 2.4, all tests of all modules are run once for each module. This is *very* bad with many modules many tests. Attached is a sample project which contains a parent module and two child modules. Each of the child modules contains one JUnit test. mvn clean site runs each test three times (once for the parent and once for each of the two submodules). When changing the surefire-report-plugin to version 2.3, each test is run only once, as it is supposed to -- 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-3388) DefaultPluginManager needs to catch LinkageError
DefaultPluginManager needs to catch LinkageError Key: MNG-3388 URL: http://jira.codehaus.org/browse/MNG-3388 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.8 Reporter: Vincent Siveton Working on the maven-pdf-plugin, it is hard to understand why we got LinkageError. We need to catch this exception and display the content of realm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3388) DefaultPluginManager needs to catch LinkageError
[ http://jira.codehaus.org/browse/MNG-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-3388. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1-alpha-1 2.0.9 applied in r619234 and in r619237 DefaultPluginManager needs to catch LinkageError Key: MNG-3388 URL: http://jira.codehaus.org/browse/MNG-3388 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.8 Reporter: Vincent Siveton Assignee: Vincent Siveton Fix For: 2.0.9, 2.1-alpha-1 Working on the maven-pdf-plugin, it is hard to understand why we got LinkageError. We need to catch this exception and display the content of realm. -- 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-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122708 ] Vincent Siveton commented on MCHANGES-88: - I fixed recently MNG-3388 so debug shoud be better specially in the realm. The problem seems to come from MavenArtifactFilterManager wich *excludes* doxia-sink-api. We have the same problem in maven-pdf-plugin. NoSuchMethodError with maven 2.0.8 when generating changes-report - Key: MCHANGES-88 URL: http://jira.codehaus.org/browse/MCHANGES-88 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.0-beta-3 Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn -version Maven version: 2.0.8 Java version: 1.6.0_03 OS name: linux version: 2.6.18-5-686 arch: i386 Family: unix Reporter: Julien Graglia Attachments: AbstractChangesReport.java, changes.log, changes.zip, error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log I create a simple maven2 project, but when i call mvn -X -e changes:changes-report I get an error (full log in attachment) java.lang.NoSuchMethodError: org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3273) Point out known pitfalls when developing plugins
[
http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MNG-3273.
Resolution: Fixed
Applied. Thanks!
Point out known pitfalls when developing plugins
Key: MNG-3273
URL: http://jira.codehaus.org/browse/MNG-3273
Project: Maven 2
Issue Type: Improvement
Components: Documentation: Guides
Reporter: Benjamin Bentmann
Assignee: Vincent Siveton
Priority: Minor
Attachments: pitfall-report-output-directory.patch,
pitfalls-resource-bundles.patch, pitfalls-resource-bundles.patch,
pitfalls.patch, plugin-api-logger.patch
Writing a simple Maven plugin is quite easy but getting it wrong is also
quite easy. I am just a novice but have so far noticed two subtle
anti-patterns that plugin developers should avoid. I would expect that the
Maven core team knows some more aspects about mojo programming that plugin
developers should be aware of to fight bugs right from the beginning. All
those pitfalls would fit nicely into [Plugin
Development|http://maven.apache.org/guides/plugin/guide-java-plugin-development.html].
Some examples: It is a bad idea to code something like
{code:java}
public MyMojo {
private Log log = getLog();
public void execute() throws MojoExecutionException {
log.debug(...);
}
}
{code}
Getting the logger this way will retrieve some default logger instead of the
logger that is injected into the mojo (by the plexus container?). This is
easily noticed by the different output styles of the log messages and the
fact that one gets [debug] message without having -X enabled.
Not bad but rather dangerous is something like
{code:java}
public MyMojo {
/**
* This parameter will take a file path (file paths are
platform-dependent...)
* @parameter
*/
private String outputDirectory;
public void execute() throws MojoExecutionException {
File outputDir = new File(outputDirectory).getAbsoluteFile();
outputDir.mkdirs();
}
}
{code}
java.io.File resolves relative paths like target/something that users might
provide in the plugin configuration against the current directory which needs
not be the project base directory. Therefore, path parameters should be
declared of type java.io.File rather than simple strings as Maven seems to
automatically push in properly resolved paths into the mojo. If one really
needs the parameter to be of type String (i.e. to try resource lookup from
class path), the best practice to properly get an absolute path should be
documented.
How to get a plugin ready for reactor builds might also be worth some warning
words. What does one need to know about aggregator-style execution, execution
project, forking ... ?
A further improvement might be links to recommended libraries like
plexus-utils or plexus-components. This would point peoply to existing code
and prevent to error-prone reinvention of the wheel (only a few things on
earth are that simple that people get them reliably right...)
--
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_122711 ] Vincent Siveton commented on MNG-3380: -- Could you send us a patch according [1]. Thanks! [1] http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_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: 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] Closed: (MNG-3378) Sync maven-eclipse-codestyle with maven_checks
[
http://jira.codehaus.org/browse/MNG-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MNG-3378.
Assignee: Vincent Siveton
Resolution: Fixed
Applied. Thanks!
Sync maven-eclipse-codestyle with maven_checks
--
Key: MNG-3378
URL: http://jira.codehaus.org/browse/MNG-3378
Project: Maven 2
Issue Type: Task
Components: IDEs
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: Vincent Siveton
Priority: Trivial
Attachments: maven-eclipse-codestyle.patch
The current codestyle for Eclipse violates the checks configured for
Checkstyle. The maven_checks.xml uses
{noformat}
module name=OperatorWrap/
{noformat}
with the default value nl to have the operator on a new line but the
maven-eclipse-codestyle.xml uses
{noformat}
setting id=org.eclipse.jdt.core.formatter.wrap_before_binary_operator
value=false/
{noformat}
causing the operator to be trailing on the wrapped line.
--
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-3320) Avoid perm gen space out of memory errors
[ http://jira.codehaus.org/browse/MNG-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122713 ] Vincent Siveton commented on MNG-3320: -- Could you send us a patch according [1]. Thanks! [1] http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patch Avoid perm gen space out of memory errors - Key: MNG-3320 URL: http://jira.codehaus.org/browse/MNG-3320 Project: Maven 2 Issue Type: Wish Components: Embedding Affects Versions: 2.0.5 Reporter: Cédric Munger Assignee: Milos Kleint Priority: Minor Fix For: 2.1-alpha-1 Attachments: mavenEmbedder.txt Each maven embedder instance is using his own classworld, the problem is that the creation of multiple maven embedder instances can lead to perm gen space errors, since each embedder classworld is filling the perm gen space memory area with new classes, out of memory errors can occurs quite easily. For some unknown reasons, this memory is never garbaged collected (at least on an MacOSX 1.5.0 JVM). A Shared classworld between all embedder object instances could avoid this potential problem. A modification of the 2.1 embedder API to choose between these 2 modes (own classworld or shared) could be a good thing. -- 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-330) centralise and internationalise error messages
[ http://jira.codehaus.org/browse/MNG-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122714 ] Vincent Siveton commented on MNG-330: - It is a prerequisite to go out 2.1? centralise and internationalise error messages -- Key: MNG-330 URL: http://jira.codehaus.org/browse/MNG-330 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Brett Porter Priority: Critical Fix For: 2.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] Issue Comment Edited: (MNG-330) centralise and internationalise error messages
[ http://jira.codehaus.org/browse/MNG-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122714 ] siveton edited comment on MNG-330 at 2/6/08 9:29 PM: - Is it a prerequisite to go out 2.1? was (Author: siveton): It is a prerequisite to go out 2.1? centralise and internationalise error messages -- Key: MNG-330 URL: http://jira.codehaus.org/browse/MNG-330 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Brett Porter Priority: Critical Fix For: 2.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
