[jira] Commented: (MNG-4667) Maven 2.2.1 XML parser fails to parse a UTF-8 POM that begins with a BOM
[
http://jira.codehaus.org/browse/MNG-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221887#action_221887
]
Benjamin Bentmann commented on MNG-4667:
The need for encoding parameters smells, XML files have an encoding, either
explicitly set via XML declaration or implicitly defaulted to UTF-8, a user
should't have to re-specify that (which just enables the risk to specify the
wrong encoding and mess up the file).
Also, your patch handles BOM stripping at the byte (and not character) level,
so I don't see a reason to involve readers/writers at all, a plain
stream-to-stream copy (e.g. via IOUtils from plexus-utils) should do.
If readers/writers are needed, it's worth looking at
ReaderFactory.newXmlReader() from plexus-utils which handles XML encoding
detection.
Maven 2.2.1 XML parser fails to parse a UTF-8 POM that begins with a BOM
Key: MNG-4667
URL: http://jira.codehaus.org/browse/MNG-4667
Project: Maven 2 3
Issue Type: Bug
Components: POM::Encoding
Affects Versions: 2.2.1
Reporter: Maria Catherine Tan
Attachments: MNG-4667-with-encoding.patch, MNG-4667.patch, pom.xml
I've seen a lot of issues related to this that were closed because they're a
duplicate of MNG-2254 but I think the fix for MNG-2254 doesn't fix this issue.
I'm using maven 2.2.1 and the build failed when the UTF-8 POM begins with a
BOM.
Here's the log when running clean install
{noformat}
Reason: Parse error reading POM. Reason: only whitespace content allowed
before start tag and not \uef (position: START_DOCUMENT seen \uef... @1:1)
for project unknown at /home/marica/quick/pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parse error reading POM.
Reason: only whitespace content allowed before start tag and not \uef
(position: START_DOCUMENT seen \uef... @1:1) for project unknown at
/home/marica/quick/pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error
reading POM. Reason: only whitespace content allowed before start tag and not
\uef (position: START_DOCUMENT seen \uef... @1:1) for project unknown at
/home/marica/quick/pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1610)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1571)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
... 12 more
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: only
whitespace content allowed before start tag and not \uef (position:
START_DOCUMENT seen \uef... @1:1)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1528)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1407)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:3911)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1606)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Closed: (MINSTALL-76) Maven-Install-Plugin installs an attached artifact twice if no primary artifact exists
[
http://jira.codehaus.org/browse/MINSTALL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINSTALL-76.
-
Resolution: Not A Bug
Fix Version/s: 2.3
Assignee: Benjamin Bentmann
bq. [DEBUG] (f) attachedArtifacts =
[com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT,
com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT]
The artifact is attached/created two times, so this is either a bug in the
plugin attaching those artifacts or just a misconfiguraton in the POM.
Maven-Install-Plugin installs an attached artifact twice if no primary
artifact exists
--
Key: MINSTALL-76
URL: http://jira.codehaus.org/browse/MINSTALL-76
Project: Maven 2.x Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.2, 2.3
Reporter: David Williams
Assignee: Benjamin Bentmann
Fix For: 2.3
I've noticed that both the maven install plugin and maven deploy plugin
installs/deploys the attached artifacts twice if the primary artifact does
not exist.
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-install-plugin:2.3:install' --
[DEBUG] (f) artifact =
com.mycompany.banking.project:Process:jar:2.4-SNAPSHOT
[DEBUG] (f) attachedArtifacts =
[com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT,
com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT]
[DEBUG] (f) createChecksum = false
[DEBUG] (f) localRepository = Repository[local|file://C:\Documents and
Settings\John.Doe\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile = C:\Workspaces\project\Process\pom.xml
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [install:install {execution: default-install}]
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing C:\Workspaces\project\Process\pom.xml to C:\Documents and
Settings\John.Doe\.m2\repository\com\mycompany\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT.pom
[INFO] Installing
C:\Workspaces\project\Process\target\Process-2.4-SNAPSHOT-xpdl.jar to
C:\Documents and
Settings\John.Doe\.m2\repository\com\sungard\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT-xpdl.jar
[INFO] Installing
C:\Workspaces\project\Process\target\Process-2.4-SNAPSHOT-xpdl.jar to
C:\Documents and
Settings\John.Doe\.m2\repository\com\sungard\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT-xpdl.jar
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINSTALL-76) Maven-Install-Plugin installs an attached artifact twice if no primary artifact exists
[
http://jira.codehaus.org/browse/MINSTALL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MINSTALL-76:
--
Fix Version/s: (was: 2.3)
Maven-Install-Plugin installs an attached artifact twice if no primary
artifact exists
--
Key: MINSTALL-76
URL: http://jira.codehaus.org/browse/MINSTALL-76
Project: Maven 2.x Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.2, 2.3
Reporter: David Williams
Assignee: Benjamin Bentmann
I've noticed that both the maven install plugin and maven deploy plugin
installs/deploys the attached artifacts twice if the primary artifact does
not exist.
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-install-plugin:2.3:install' --
[DEBUG] (f) artifact =
com.mycompany.banking.project:Process:jar:2.4-SNAPSHOT
[DEBUG] (f) attachedArtifacts =
[com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT,
com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT]
[DEBUG] (f) createChecksum = false
[DEBUG] (f) localRepository = Repository[local|file://C:\Documents and
Settings\John.Doe\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile = C:\Workspaces\project\Process\pom.xml
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [install:install {execution: default-install}]
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing C:\Workspaces\project\Process\pom.xml to C:\Documents and
Settings\John.Doe\.m2\repository\com\mycompany\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT.pom
[INFO] Installing
C:\Workspaces\project\Process\target\Process-2.4-SNAPSHOT-xpdl.jar to
C:\Documents and
Settings\John.Doe\.m2\repository\com\sungard\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT-xpdl.jar
[INFO] Installing
C:\Workspaces\project\Process\target\Process-2.4-SNAPSHOT-xpdl.jar to
C:\Documents and
Settings\John.Doe\.m2\repository\com\sungard\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT-xpdl.jar
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-561) autoVersionSubmodules causes an AssertionError with release:branch
autoVersionSubmodules causes an AssertionError with release:branch -- Key: MRELEASE-561 URL: http://jira.codehaus.org/browse/MRELEASE-561 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: WinXP, maven 2.2.1, Java 5 Reporter: Lucien Weller Attachments: branch-auto-version.patch When I try to run the following command I get an AssertionError because the root projekt is added twice into map: mvn release:branch -DdryRun=true -DbranchName=re3.07.05 -DautoVersionSubmodules=true Attached patch should fix this issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[
http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221900#action_221900
]
A commented on SUREFIRE-576:
Hello,
I've tested the changes today. It seems like the filter is actually including
what user chooses in the exclude elements.
[code]
private Set filterArtifacts( Set artifacts, ArtifactFilter filter )
{
Set filteredArtifacts = new LinkedHashSet();
for ( Iterator iter = artifacts.iterator(); iter.hasNext(); )
{
Artifact artifact = (Artifact) iter.next();
if ( filter.include( artifact ) )
{
filteredArtifacts.add( artifact );
}
}
return filteredArtifacts;
}
[/code]
Perhaps you intended it as if ( ! filter.include( artifact ) )?
Another glitch I'm seeing is that description of the scope excludes element is
misleading. compile+runtime doesn't seem to be recognized as a valid option for
filtering but runtime alone is what works for me. Also I can't make
runtime+system working neither system. I've no why.
Thanks!
Have the abiltiy to remove a dependency from the test classpath (at least
optional ones
---
Key: SUREFIRE-576
URL: http://jira.codehaus.org/browse/SUREFIRE-576
Project: Maven Surefire
Issue Type: New Feature
Components: classloading, Maven Surefire Plugin
Reporter: Hardy Ferentschik
Assignee: Paul Gier
Fix For: 2.6
--
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: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[
http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221900#action_221900
]
A edited comment on SUREFIRE-576 at 5/20/10 4:49 AM:
-
Hello,
I've tested the changes today. It seems like the filter is actually including
what user chooses in the exclude elements.
{code}
private Set filterArtifacts( Set artifacts, ArtifactFilter filter )
{
Set filteredArtifacts = new LinkedHashSet();
for ( Iterator iter = artifacts.iterator(); iter.hasNext(); )
{
Artifact artifact = (Artifact) iter.next();
if ( filter.include( artifact ) )
{
filteredArtifacts.add( artifact );
}
}
return filteredArtifacts;
}
{code}
Perhaps you intended it as if ( ! filter.include( artifact ) )?
Another glitch I'm seeing is that description of the scope excludes element is
misleading. compile+runtime doesn't seem to be recognized as a valid option for
filtering but runtime alone is what works for me. Also I can't make
runtime+system working neither system. I've no why.
Thanks!
was (Author: avalon):
Hello,
I've tested the changes today. It seems like the filter is actually including
what user chooses in the exclude elements.
[code]
private Set filterArtifacts( Set artifacts, ArtifactFilter filter )
{
Set filteredArtifacts = new LinkedHashSet();
for ( Iterator iter = artifacts.iterator(); iter.hasNext(); )
{
Artifact artifact = (Artifact) iter.next();
if ( filter.include( artifact ) )
{
filteredArtifacts.add( artifact );
}
}
return filteredArtifacts;
}
[/code]
Perhaps you intended it as if ( ! filter.include( artifact ) )?
Another glitch I'm seeing is that description of the scope excludes element is
misleading. compile+runtime doesn't seem to be recognized as a valid option for
filtering but runtime alone is what works for me. Also I can't make
runtime+system working neither system. I've no why.
Thanks!
Have the abiltiy to remove a dependency from the test classpath (at least
optional ones
---
Key: SUREFIRE-576
URL: http://jira.codehaus.org/browse/SUREFIRE-576
Project: Maven Surefire
Issue Type: New Feature
Components: classloading, Maven Surefire Plugin
Reporter: Hardy Ferentschik
Assignee: Paul Gier
Fix For: 2.6
--
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-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ http://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221905#action_221905 ] Kristian Rosenvold commented on SUREFIRE-599: - I have tracked this problem to be inside TestListenerInvocationHandler. All is fine inside JunitTestSet.invoke (line 213 in 2.5). Somehow this duplication jappens within the dynamic proxy. Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: http://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- 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: (SUREFIRE-599) Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests
[ http://jira.codehaus.org/browse/SUREFIRE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221905#action_221905 ] Kristian Rosenvold edited comment on SUREFIRE-599 at 5/20/10 6:18 AM: -- I have tracked this problem to be inside TestListenerInvocationHandler. All is fine inside JunitTestSet.invoke (line 213 in 2.5). Somehow this duplication happens within the dynamic proxy. was (Author: krosenvold): I have tracked this problem to be inside TestListenerInvocationHandler. All is fine inside JunitTestSet.invoke (line 213 in 2.5). Somehow this duplication jappens within the dynamic proxy. Logs console output multiple times (no. of times log output = the no. of test being run) for JUnit/XMLUnit tests Key: SUREFIRE-599 URL: http://jira.codehaus.org/browse/SUREFIRE-599 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.5 Environment: Ubuntu 9.04 Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_16 OS name: linux version: 2.6.31-17-generic arch: i386 Family: unix JUnit 3.8.2 Log4j 1.2.14 Reporter: Mahender Didwania I have a test class (named ATest) written by extending the JUnit TestCase class. This class has a few test methods which all call the same method on a class (named A) with different parameters, exactly once each. Now the class A which is being tested logs to console using Apache log4j's ConsoleAppender, at INFO level. In the first test method, a message is logged once (which is how it should be). In the second test method, every log message is repeated once (so gets logged twice instead of once). In the third test method, every log message is logged thrice. ... and so on. Please note that the method in class A is invoked only once by the written source-code in each of the test methods and logs only once. -- 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-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221915#action_221915 ] A commented on SUREFIRE-576: Actually I see the issue better now. For scope ExcludesArtifactFilter is used and for individual artifacts ExcludesArtifactFilter is used so it seems either a new method needs to be created or ExcludesArtifactFilter changed to IncludesArtifactFilter and filterArtifacts() to reflect that. Have the abiltiy to remove a dependency from the test classpath (at least optional ones --- Key: SUREFIRE-576 URL: http://jira.codehaus.org/browse/SUREFIRE-576 Project: Maven Surefire Issue Type: New Feature Components: classloading, Maven Surefire Plugin Reporter: Hardy Ferentschik Assignee: Paul Gier Fix For: 2.6 -- 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: (MINSTALL-76) Maven-Install-Plugin installs an attached artifact twice if no primary artifact exists
[
http://jira.codehaus.org/browse/MINSTALL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221917#action_221917
]
David Williams commented on MINSTALL-76:
Thanks Benjamin. It turns out it was a misconfiguration in the
maven-jar-plugin. I confirmed late last night and was going to close this
ticket today. Thanks, David
Maven-Install-Plugin installs an attached artifact twice if no primary
artifact exists
--
Key: MINSTALL-76
URL: http://jira.codehaus.org/browse/MINSTALL-76
Project: Maven 2.x Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.2, 2.3
Reporter: David Williams
Assignee: Benjamin Bentmann
I've noticed that both the maven install plugin and maven deploy plugin
installs/deploys the attached artifacts twice if the primary artifact does
not exist.
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-install-plugin:2.3:install' --
[DEBUG] (f) artifact =
com.mycompany.banking.project:Process:jar:2.4-SNAPSHOT
[DEBUG] (f) attachedArtifacts =
[com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT,
com.mycompany.banking.project:Process:jar:xpdl:2.4-SNAPSHOT]
[DEBUG] (f) createChecksum = false
[DEBUG] (f) localRepository = Repository[local|file://C:\Documents and
Settings\John.Doe\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile = C:\Workspaces\project\Process\pom.xml
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [install:install {execution: default-install}]
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing C:\Workspaces\project\Process\pom.xml to C:\Documents and
Settings\John.Doe\.m2\repository\com\mycompany\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT.pom
[INFO] Installing
C:\Workspaces\project\Process\target\Process-2.4-SNAPSHOT-xpdl.jar to
C:\Documents and
Settings\John.Doe\.m2\repository\com\sungard\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT-xpdl.jar
[INFO] Installing
C:\Workspaces\project\Process\target\Process-2.4-SNAPSHOT-xpdl.jar to
C:\Documents and
Settings\John.Doe\.m2\repository\com\sungard\banking\project\Process\2.4-SNAPSHOT\Process-2.4-SNAPSHOT-xpdl.jar
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened SUREFIRE-576: Thanks for testing this. You're right my logic was correct for the individual dependency excludes but reversed for the scope excludes. The missing combined scopes is probably because surefire is using an older version of the scope filter, so I'll update this also. Have the abiltiy to remove a dependency from the test classpath (at least optional ones --- Key: SUREFIRE-576 URL: http://jira.codehaus.org/browse/SUREFIRE-576 Project: Maven Surefire Issue Type: New Feature Components: classloading, Maven Surefire Plugin Reporter: Hardy Ferentschik Assignee: Paul Gier Fix For: 2.6 -- 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: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221915#action_221915 ] A edited comment on SUREFIRE-576 at 5/20/10 8:14 AM: - Actually I see the issue better now. For scope ExcludesArtifactFilter is used and for individual artifacts ExcludesArtifactFilter is used so it seems either a new method needs to be created or ExcludesArtifactFilter changed to IncludesArtifactFilter and filterArtifacts() to reflect that. For the second issue with scope names I tried using maven 2.2.1 but still I can't make a system artifact to be excluded. was (Author: avalon): Actually I see the issue better now. For scope ExcludesArtifactFilter is used and for individual artifacts ExcludesArtifactFilter is used so it seems either a new method needs to be created or ExcludesArtifactFilter changed to IncludesArtifactFilter and filterArtifacts() to reflect that. Have the abiltiy to remove a dependency from the test classpath (at least optional ones --- Key: SUREFIRE-576 URL: http://jira.codehaus.org/browse/SUREFIRE-576 Project: Maven Surefire Issue Type: New Feature Components: classloading, Maven Surefire Plugin Reporter: Hardy Ferentschik Assignee: Paul Gier Fix For: 2.6 -- 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-2780) I am DynamicJasper's project leader, please upload.
I am DynamicJasper's project leader, please upload. --- Key: MAVENUPLOAD-2780 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2780 Project: Maven Upload Requests Issue Type: Task Reporter: Juan Manuel Alvarez I am DynamicJasper's project leader, please upload. DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design time. -- 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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221919#action_221919 ] Sebastian Paul commented on MNG-2258: - @Daniel: How did you work around this issue without running jxr twice? I am using Maven 2.2.1 too, and have the same issue. When jxr only runs once in pre-site, the report does not contain a link to the source (Reports section in the navigation area). Only the tag list plugin correctly links to the source... Wrong execution order of plugins in same phase -- Key: MNG-2258 URL: http://jira.codehaus.org/browse/MNG-2258 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.4 Environment: N/A Reporter: David J. M. Karlsen Priority: Blocker Attachments: mavenTest.zip AFAIK plugins should be execute in the same order as they are listed in the POM, when bound to the same phase. This does not happen, the execution order is arbitrary. -- 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-4667) Maven 2.2.1 XML parser fails to parse a UTF-8 POM that begins with a BOM
[
http://jira.codehaus.org/browse/MNG-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221928#action_221928
]
Paul Benedict commented on MNG-4667:
I agree with Benjamin. Because XML already supports an encoding directive, that
should where the solution should lie.
Maven 2.2.1 XML parser fails to parse a UTF-8 POM that begins with a BOM
Key: MNG-4667
URL: http://jira.codehaus.org/browse/MNG-4667
Project: Maven 2 3
Issue Type: Bug
Components: POM::Encoding
Affects Versions: 2.2.1
Reporter: Maria Catherine Tan
Attachments: MNG-4667-with-encoding.patch, MNG-4667.patch, pom.xml
I've seen a lot of issues related to this that were closed because they're a
duplicate of MNG-2254 but I think the fix for MNG-2254 doesn't fix this issue.
I'm using maven 2.2.1 and the build failed when the UTF-8 POM begins with a
BOM.
Here's the log when running clean install
{noformat}
Reason: Parse error reading POM. Reason: only whitespace content allowed
before start tag and not \uef (position: START_DOCUMENT seen \uef... @1:1)
for project unknown at /home/marica/quick/pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parse error reading POM.
Reason: only whitespace content allowed before start tag and not \uef
(position: START_DOCUMENT seen \uef... @1:1) for project unknown at
/home/marica/quick/pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error
reading POM. Reason: only whitespace content allowed before start tag and not
\uef (position: START_DOCUMENT seen \uef... @1:1) for project unknown at
/home/marica/quick/pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1610)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1571)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
... 12 more
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: only
whitespace content allowed before start tag and not \uef (position:
START_DOCUMENT seen \uef... @1:1)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1528)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1407)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:3911)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1606)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-213) resolve dependencyManagement section with option to fail the build
[
http://jira.codehaus.org/browse/MDEP-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221929#action_221929
]
Jim Sellers commented on MDEP-213:
--
As a work around I created a groovy script that will that:
1) take the pom, copy it to the target directory
2) remove the dependencyManagement tags so that the pom just has dependencies
3) run dependency:resolve on that modified pom, failing the build if
dependency:resolve fails.
In the pom:
{noformat}
build
plugins
plugin
groupIdorg.codehaus.groovy.maven/groupId
artifactIdgmaven-plugin/artifactId
executions
execution
phasegenerate-test-sources/phase
goals
goalexecute/goal
/goals
configuration
source${pom.basedir}/src/main/script/resolveDepMgmt.groovy/source
/configuration
/execution
/executions
/plugin
/plugins
/build
{noformat}
The contents of resolveDepMgmt.groovy is:
{noformat}
import org.apache.commons.lang.SystemUtils
log.info('About to run check on the dependency management section...')
// read the pom, remove the dependencyManagement tags
File sourceFile = new File('pom.xml')
String text = sourceFile.text.replaceAll('dependencyManagement',
'').replaceAll('/dependencyManagement', '')
// make the outputDirectory if it does not exist
File outputDir = new File('target')
if (!outputDir.exists())
outputDir.mkdirs()
File ouputFile = new File(outputDir.getAbsolutePath() +
'/pom-only-dependencies.xml')
ouputFile.write(text)
String mvnCommand = mvn dependency:resolve -f + ouputFile.getAbsolutePath()
// because mvn is not an executable program on windows
if (SystemUtils.IS_OS_WINDOWS)
mvnCommand = 'cmd /c ' + mvnCommand
outputCatcher = new StringBuffer()
errorCatcher = new StringBuffer()
proc = mvnCommand.execute()
proc.consumeProcessOutput(outputCatcher, errorCatcher)
proc.waitFor()
// print the output / errors to the screen
println outputCatcher
// have the calling process share the exit value of the maven command if there
was an error
if (0 != proc.exitValue())
fail('failed resolving dependencies')
{noformat}
resolve dependencyManagement section with option to fail the build
--
Key: MDEP-213
URL: http://jira.codehaus.org/browse/MDEP-213
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: resolve
Affects Versions: 2.0
Reporter: Jim Sellers
Assignee: Brian Fox
When using the dependencyManagement section of a pom of type pom to create
a bill of materials, it's currently possible to specify an invalid version.
eg:
{code:xml}
dependencyManagement
dependencies
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
version9.9/version
/dependency
/dependencies
/dependencyManagement
{code}
It would be really useful for these types of pom's to be able to force all
the dependencies to be resolved when running something like install and
have that fail the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-201) Add option to tree goal to generate tree based on dependencyManagement
[ http://jira.codehaus.org/browse/MDEP-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221930#action_221930 ] Jim Sellers commented on MDEP-201: -- I posted our workaround for resolving dependencies from dependencyManagement in MDEP-213. That might be useful for you as well. Add option to tree goal to generate tree based on dependencyManagement -- Key: MDEP-201 URL: http://jira.codehaus.org/browse/MDEP-201 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: tree Reporter: Paul Gier Assignee: Brian Fox I have a parent pom that controls the dependency versions for a multimodule project. I would like to be able to generate a dependency tree from this pom, so that I can see the tree for the entire project, but currently the tree goal only looks at actual dependencies and not those in dependency management. -- 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-4683) Can't find parent poms in multi project build, if on the same level
Can't find parent poms in multi project build, if on the same level --- Key: MNG-4683 URL: http://jira.codehaus.org/browse/MNG-4683 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build, Reactor and workspace Affects Versions: 3.0-beta-1, 3.0-alpha-7, 3.0-alpha-6 Environment: Tested on WinXP sp3, Java 1.6.20 (Sun) Reporter: Mirko Jahn Attachments: mvn2cleanInstall.txt, mvn3cleanInstall.txt, TestCase.zip I created a test project to verify the behavior. Basically, in Maven 3 the build failed due to missing parent poms. However, these poms are part of the actual multi module build. To verify the bug: 1. unzip the project and jump into the root folder to the first pom.xml 2. execute with maven 3: mvn clean install (see file mvn3cleanInstall.txt) == the build will fail 3. execute the same command with maven 2 (I used 2.2.1) (see file mvn2cleanInstall.txt) == you'll see it will work without any problems (warning, because my plugins do not contain any code) 4. execute the same command as done in step 2 again (see file mvn3cleanInstall2.txt) == now it'll build, because it can find the artifacts in the local repo (created by the maven 2 build). It will eventually still fail, but not due to the above mentioned error but the fact, that I didn't include any source code for the plug-ins to keep it as simple as possible) The really nasty thing about this bug is that you might not even notice that there is a bug, as long as you have such an artifact in your repository. Unfortunately then, only the wrong version get's picked up. Of course, as soon as you want to release this will fail. -- 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-4683) Can't find parent poms in multi project build, if on the same level
[ http://jira.codehaus.org/browse/MNG-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Jahn updated MNG-4683: Attachment: mvn3cleanInstall2.txt the last file missing from my explanations of the bug. Can't find parent poms in multi project build, if on the same level --- Key: MNG-4683 URL: http://jira.codehaus.org/browse/MNG-4683 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build, Reactor and workspace Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1 Environment: Tested on WinXP sp3, Java 1.6.20 (Sun) Reporter: Mirko Jahn Attachments: mvn2cleanInstall.txt, mvn3cleanInstall.txt, mvn3cleanInstall2.txt, TestCase.zip I created a test project to verify the behavior. Basically, in Maven 3 the build failed due to missing parent poms. However, these poms are part of the actual multi module build. To verify the bug: 1. unzip the project and jump into the root folder to the first pom.xml 2. execute with maven 3: mvn clean install (see file mvn3cleanInstall.txt) == the build will fail 3. execute the same command with maven 2 (I used 2.2.1) (see file mvn2cleanInstall.txt) == you'll see it will work without any problems (warning, because my plugins do not contain any code) 4. execute the same command as done in step 2 again (see file mvn3cleanInstall2.txt) == now it'll build, because it can find the artifacts in the local repo (created by the maven 2 build). It will eventually still fail, but not due to the above mentioned error but the fact, that I didn't include any source code for the plug-ins to keep it as simple as possible) The really nasty thing about this bug is that you might not even notice that there is a bug, as long as you have such an artifact in your repository. Unfortunately then, only the wrong version get's picked up. Of course, as soon as you want to release this will fail. -- 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: (MCHANGELOG-109) Support SVN merge history
Support SVN merge history - Key: MCHANGELOG-109 URL: http://jira.codehaus.org/browse/MCHANGELOG-109 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Reporter: Sebastian Paul Currently, merged revisions from SVN are not shown in the log. TortoiseSVN or Subversive support this with the Show merged revisions switch. The SVN command line tool provides a switch -g [--use-merge-history] : use/display additional information from merge history. Of course, this requires an SVN server = 1.5. I am wondering if the maven-scm-api supports this at all. If there is a way to support this feature, the plugin should provide a switch to enable 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] Closed: (MNG-4683) Can't find parent poms in multi project build, if on the same level
[
http://jira.codehaus.org/browse/MNG-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4683.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
Your POMs are missing the proper {{relativePath}} specification to the
parent, cf. the [compat
notes|https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ParentPOMResolution].
Can't find parent poms in multi project build, if on the same level
---
Key: MNG-4683
URL: http://jira.codehaus.org/browse/MNG-4683
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build, Reactor and workspace
Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
Environment: Tested on WinXP sp3, Java 1.6.20 (Sun)
Reporter: Mirko Jahn
Assignee: Benjamin Bentmann
Attachments: mvn2cleanInstall.txt, mvn3cleanInstall.txt,
mvn3cleanInstall2.txt, TestCase.zip
I created a test project to verify the behavior. Basically, in Maven 3 the
build failed due to missing parent poms. However, these poms are part of the
actual multi module build.
To verify the bug:
1. unzip the project and jump into the root folder to the first pom.xml
2. execute with maven 3: mvn clean install (see file mvn3cleanInstall.txt)
== the build will fail
3. execute the same command with maven 2 (I used 2.2.1) (see file
mvn2cleanInstall.txt)
== you'll see it will work without any problems (warning, because my plugins
do not contain any code)
4. execute the same command as done in step 2 again (see file
mvn3cleanInstall2.txt)
== now it'll build, because it can find the artifacts in the local repo
(created by the maven 2 build). It will eventually still fail, but not due to
the above mentioned error but the fact, that I didn't include any source code
for the plug-ins to keep it as simple as possible)
The really nasty thing about this bug is that you might not even notice that
there is a bug, as long as you have such an artifact in your repository.
Unfortunately then, only the wrong version get's picked up. Of course, as
soon as you want to release this will fail.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-436) Spaces in scmCommitPrefix cause errors in attempting to release
[
http://jira.codehaus.org/browse/MRELEASE-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221953#action_221953
]
Benson Margulies commented on MRELEASE-436:
---
I don't see how this can be a dup of that. That is closed as not-reproducible.
I can repro this on command with maven 2.1.0 and release 2.0 at an time, just
by simply trying to embed a space in the prefix.
Spaces in scmCommitPrefix cause errors in attempting to release
---
Key: MRELEASE-436
URL: http://jira.codehaus.org/browse/MRELEASE-436
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform, prepare
Affects Versions: 2.0-beta-9
Environment: Maven 2.0.9 JDK 1.5
Reporter: Mykel Alvis
Assignee: Olivier Lamy
$ mvn -B -DscmCommentPrefix=CM-524 release:prepare
---
constituent[0]: file:/opt/maven/lib/maven-2.0.9-uber.jar
---
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at
java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:146)
at java.lang.StringBuffer.setLength(StringBuffer.java:154)
{rest removed}
The space scmCommentPrefix seems to cause this, since
mvn -B -DscmCommentPrefix=CM-524_ release:prepare
works correctly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-462) Assembly contains temporary files ending in *.formatted.
[
http://jira.codehaus.org/browse/MASSEMBLY-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221957#action_221957
]
Grzegorz Slowikowski commented on MASSEMBLY-462:
Filtering is performed even for files with filtering set to false. Files
*.formatted come from ${basedir}/target/archive-tmp subdirs. For me
2.2-beta-4 version works fine.
Assembly contains temporary files ending in *.formatted.
Key: MASSEMBLY-462
URL: http://jira.codehaus.org/browse/MASSEMBLY-462
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
Java version: 1.5.0_17
Java home: /usr/lib/jvm/java-1.5.0-sun-1.5.0.17/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: linux version: 2.6.33-686 arch: i386 Family: unix
Reporter: Christian Schulte
Priority: Critical
Attachments: MASSEMBLY-462.patch
The fix for MASSEMBLY-385 introduced a regression in class
org.apache.maven.plugin.assembly.format.FileFormatter
(http://svn.apache.org/viewvc?view=revisionrevision=806277) leading to
file set definitions without any includes to produce temporary files in the
final assembly ending in *.formatted.
Example file sets to reproduce:
{xml}
fileSet
directorytarget/appassembler/bin/directory
fileMode0555/fileMode
directoryMode0755/directoryMode
outputDirectory/bin/outputDirectory
excludes
exclude*.bat/exclude
/excludes
lineEndingunix/lineEnding
/fileSet
{xml}
{xml}
fileSet
directorysrc/main/assembly/etc/directory
fileMode0444/fileMode
directoryMode0755/directoryMode
outputDirectory/etc/outputDirectory
lineEndingdos/lineEnding
/fileSet
{xml}
The attached patch adds the **/*.formatted pattern to the default excludes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2738) JSR330 @Inject TCK (official release) 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221961#action_221961 ] Christian Ihle commented on MAVENUPLOAD-2738: - I am not a commiter on the project, but I have uploaded a new bundle with the javax.inject-tck pom instead. It's available here: http://repo.usikkert.net/bundle/javax.inject-tck-1-bundle.jar Can you please give it a try? You can verify that the only change is the pom.xml (and the generated manifest). I took the pom.xml from javax.inject-tck-1.jar. JSR330 @Inject TCK (official release) 1 --- Key: MAVENUPLOAD-2738 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2738 Project: Maven Upload Requests Issue Type: Wish Reporter: Paul Hammant Assignee: Juven Xu I'm a commtter, I just uploaded the tck jar to the GoogleCode downloads page for that project. paul / codehaus == PaulHammant / GoogleCode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221967#action_221967
]
Niall Gallagher commented on MNG-3244:
--
My company has a flat SVN structure, with trunk/, tags/ and branches/ folders
in every project. e.g.
.../corporate-pom/trunk/
...pom.xml
./tags/
./branches/
.../project1/trunk/
..pom.xml
/tags/
/branches/
We were hoping to factor out scm, site and nexus urls from all of our projects
into a corporate pom. Due to this bug though, maven is appending artifactid
again after trunk/ in inherited urls, which doesn't make sense for this
structure. So basically this bug will prevent us from factoring out most of the
configuration, and we'll have to copy/paste the same url template into every
pom.
Can we consider fixing this bug for maven 2.x again?
Double slashes are usually canonicalised to single slashes -
http://en.wikipedia.org/wiki/URL_normalization - can we therefore use the
presence of double slash as a marker?
How about not appending the artifactid again, when the url in the parent pom
ends with a double slash '//'?
inherited site url not properly handling parameters
---
Key: MNG-3244
URL: http://jira.codehaus.org/browse/MNG-3244
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation, Sites Reporting
Affects Versions: 2.0.7
Reporter: Jacob Robertson
Assignee: Brian Fox
Fix For: Issues to be reviewed for 3.x
Attachments: fix-inherited-site-url.patch, guide-site.patch,
mng-3244_patch.txt
Here is the test case to reroduce this problem. Take the following two
pom.xml files
?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdfoo/artifactId
namefoo/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
distributionManagement
site
idfoo-site/id
urlfile://C:/Documents and
Settings/foo/.m2/site/${project.artifactId}/url
/site
/distributionManagement
/project
?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdbaz/artifactId
namebaz/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
parent
artifactIdfoo/artifactId
groupIdorg.bar/groupId
version1.0-SNAPSHOT/version
/parent
/project
And run the site-deploy goal on each. What you get under the site directory
is this
- site
/- foo
---/site docs
/- baz
---/- baz (extra directory)
--- ---/site docs
This is the simplest test case. In the case where I have a grandparent
pom, the site directory uses the grandparent/parent as the path to the site,
and doesn't use the actual artifactId of the artifact I'm creating the site
for.
--
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: (MSHARED-154) pomPropertiesFile does not actually permit override
pomPropertiesFile does not actually permit override
---
Key: MSHARED-154
URL: http://jira.codehaus.org/browse/MSHARED-154
Project: Maven Shared Components
Issue Type: Bug
Components: maven-archiver
Affects Versions: maven-archiver-2.4
Environment: RHEL 5.4
Apache Maven 2.2.1 (r801777; 2009-08-06 13:16:01-0600)
Java version: 1.6.0_19
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: linux version: 2.6.18-164.2.1.el5pae arch: i386 Family: unix
Reporter: Dan Nelson
h4. The What
My understanding is that the {{pomPropertiesFile}} configuration element will
allow you to override the default {{pom.properties}} file that is created by
the maven-archiver when {{addMavenDescriptor}} is {{true}}. I wanted to use
this feature to include some [Hudson|https://hudson.dev.java.net/] build data
into the {{pom.properties}} file. We already have utility classes that read
version information from this file, so it wasn't a leap to add some
build-server information to this same file.
From the [Maven Archiver
Reference|http://maven.apache.org/shared/maven-archiver/index.html] page:
{quote}
| pomPropertiesFile | Use this to override the auto generated pom.properties
file (only if addMavenDescriptor is set to true) | File | 2.3 |
{quote}
h4. My Expectations
So my assumption is that I can provide a customized pom.properties file that
will be written/copied to the {{META-INF/maven/ + ${pom.groupId} + / +
${pom.artifactId} + /pom.properties}} file.
h4. The Actual Result
The File I pass to the {{pomPropertiesFile}} element is actually overwritten
with the default pom.properties file format. One could say it is overriding my
override. Maybe I am misunderstanding this configuration element altogether, I
can't see how it can possibly be helpful the way that it is behaving right
now...
h4. Background Information
I am witnessing this behaviour with the apache war plugin:
{code:xml|title=Snippet of my pom.xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-beta-1/version
configuration
archive
addMavenDescriptortrue/addMavenDescriptor
pomPropertiesFileconfigurations/custom-pom.properties/pomPropertiesFile
/archive
/configuration
/plugin
{code}
And here is my customized properties file that I want used to replace the
default pom.properties content:
{code:java|title=Snippet of my custom-pom.properties override file}
version=$\{pom.version\}
groupId=$\{pom.groupId\}
artifactId=$\{pom.artifactId\}
buildTag=${BUILD_TAG}
buildNumber=${BUILD_NUMBER}
buildId=${BUILD_ID}
{code}
I see from my Maven output that {{maven-war-plugin-2.1-beta-1}} uses
{{maven-archiver-2.4}}:
{code:title=Maven output}
...
[DEBUG] Plugin dependencies for:
org.apache.maven.plugins:maven-war-plugin:2.1-beta-1
are:
org.apache.maven:maven-plugin-api:jar:2.0.6:runtime
org.apache.maven:maven-artifact:jar:2.0.6:runtime
org.apache.maven:maven-archiver:jar:2.4:runtime
org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-9:runtime
org.codehaus.plexus:plexus-io:jar:1.0-alpha-1:runtime
com.thoughtworks.xstream:xstream:jar:1.3.1:runtime
org.codehaus.plexus:plexus-utils:jar:1.5.5:runtime
org.apache.maven.shared:maven-filtering:jar:1.0-beta-2:runtime
...
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-war-plugin:2.1-beta-1:war' --
[DEBUG] (s) addMavenDescriptor = false
[DEBUG] (s) pomPropertiesFile =
/SOME_PATH/configurations/custom-pom.properties
...
{code}
h4.
[MavenArchiver#createArchive(...)|http://maven.apache.org/shared/maven-archiver/xref/org/apache/maven/archiver/MavenArchiver.html#493]
I notice that the {{createArchive(...)}} method ALWAYS writes the
standard/default [pom.properties
contents|http://maven.apache.org/shared/maven-archiver/index.html#pom-properties-content]
to the supplied file. That provides no benefit.
If I can offer a suggestion:
# get the pomPropertiesFile configuration property.
#* if the property is not null and the property maps to an existing file
#*# {{archiver.addFile( pomPropertiesFile, META-INF/maven/ + groupId + / +
artifactId + /pom.properties );}}
#* else the file property was null
#*# Create the temporary maven-archiver folder
#*# Create a ref to the maven-archiver/pom.properties file
#*# Call PomPropertiesUtil#createPomProperties
--
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-2781) jt400-7.0-bundle
jt400-7.0-bundle Key: MAVENUPLOAD-2781 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2781 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: javadoc-7.0.zip, jt400-7.0.jar The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes supporting the client/server and internet programming models to a system running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, servlets, and applications to easily access OS/400, i5/OS, and IBM i data and resources. -- 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: (MAVENUPLOAD-2781) jt400-7.0-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Lee updated MAVENUPLOAD-2781: -- Attachment: jt400-7.0-bundle.jar Please delete the previous attachment jt400-7.0.jar and replace it with this attachment. jt400-7.0-bundle Key: MAVENUPLOAD-2781 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2781 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: javadoc-7.0.zip, jt400-7.0-bundle.jar, jt400-7.0.jar The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes supporting the client/server and internet programming models to a system running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, servlets, and applications to easily access OS/400, i5/OS, and IBM i data and resources. -- 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-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221975#action_221975 ] Paul Gier commented on SUREFIRE-576: Another update in [r946778|http://svn.apache.org/viewvc?view=revisionrevision=946778] Have the abiltiy to remove a dependency from the test classpath (at least optional ones --- Key: SUREFIRE-576 URL: http://jira.codehaus.org/browse/SUREFIRE-576 Project: Maven Surefire Issue Type: New Feature Components: classloading, Maven Surefire Plugin Reporter: Hardy Ferentschik Assignee: Paul Gier Fix For: 2.6 -- 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-4567) maven-jetty-plugin throws a ClassNotFoundException
[
http://jira.codehaus.org/browse/MNG-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221976#action_221976
]
Christian Mueller commented on MNG-4567:
The problem still exists with the maven-war-plugin '2.1-beta-1'.
maven-jetty-plugin throws a ClassNotFoundException
--
Key: MNG-4567
URL: http://jira.codehaus.org/browse/MNG-4567
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1
Environment: muellerc$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_17
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x version: 10.6.2 arch: x86_64 Family: mac
maven-jetty-plugin: 6.1.22
Reporter: Christian Mueller
I tried to upgrade from Maven 2.0.9 to 2.2.1, but the maven-jetty-plugin
(6.1.22) throws a ClassNotFoundException by executing mvn jetty:run with
Maven 2.2.1. We use the following project configuration:
[pom.xml|http://svn.apache.org/viewvc/camel/tags/camel-2.2.0/components/camel-web/pom.xml?view=markup]
The comand line output for Maven 2.0.9 is the following:
{code}
muellerc$ mvn jetty:run --debug
...
[DEBUG] Configuring mojo 'org.mortbay.jetty:maven-jetty-plugin:6.1.22:run' --
[DEBUG] (f) classesDirectory =
/Users/muellerc/workspaceApacheGit/camel/components/camel-web/target/classes
[DEBUG] (f) contextPath = /camel-web
[DEBUG] (f) daemon = false
[DEBUG] (f) pluginArtifacts = [org.mortbay.jetty:jetty:jar:6.1.22:runtime,
org.mortbay.jetty:jetty-util:jar:6.1.22:runtime,
org.mortbay.jetty:servlet-api:jar:2.5-20081211:runtime,
org.codehaus.plexus:plexus-utils:jar:1.1:runtime,
org.apache.maven:maven-plugin-tools-api:jar:2.0:runtime,
org.mortbay.jetty:jetty-plus:jar:6.1.22:runtime,
geronimo-spec:geronimo-spec-jta:jar:1.0.1B-rc4:runtime,
org.mortbay.jetty:jetty-naming:jar:6.1.22:runtime,
javax.mail:mail:jar:1.4:runtime,
org.mortbay.jetty:jetty-management:jar:6.1.22:runtime,
org.mortbay.jetty:jsp-2.1-jetty:jar:6.1.22:runtime,
org.eclipse.jdt:core:jar:3.1.1:runtime,
org.mortbay.jetty:jsp-api-2.1-glassfish:jar:9.1.1.B60.25.p2:runtime,
org.mortbay.jetty:jsp-2.1-glassfish:jar:9.1.1.B60.25.p2:runtime,
ant:ant:jar:1.6.5:runtime,
org.mortbay.jetty:jetty-annotations:jar:6.1.22:runtime,
org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.0:runtime,
org.mortbay.jetty:start:jar:6.1.22:runtime,
org.apache.maven:maven-project:jar:2.0.3:runtime,
org.apache.maven:maven-plugin-api:jar:2.0.3:runtime,
org.apache.maven:maven-artifact:jar:2.0.3:runtime]
[DEBUG] (f) project = MavenProject: org.apache.camel:camel-web:2.3-SNAPSHOT
@ /Users/muellerc/workspaceApacheGit/camel/components/camel-web/pom.xml
[DEBUG] (f) reload = automatic
[DEBUG] (f) scanIntervalSeconds = 10
[DEBUG] (s) name = com.sun.management.jmxremote
[DEBUG] (s) systemProperty =
org.mortbay.jetty.plugin.util.systemprope...@2e9a5a48
[DEBUG] (s) systemProperties =
org.mortbay.jetty.plugin.util.systempropert...@179d44df
[DEBUG] (f) testClassesDirectory =
/Users/muellerc/workspaceApacheGit/camel/components/camel-web/target/test-classes
[DEBUG] (f) tmpDirectory =
/Users/muellerc/workspaceApacheGit/camel/components/camel-web/target/work
[DEBUG] (f) useTestClasspath = false
[DEBUG] (s) contextPath = /
[DEBUG] (f) webAppConfig =
org.mortbay.jetty.plugin.jetty6pluginwebappcont...@5f095c81{/,null}
[DEBUG] (f) webAppSourceDirectory =
/Users/muellerc/workspaceApacheGit/camel/components/camel-web/src/main/webapp
[DEBUG] -- end configuration --
[INFO] [jetty:run]
[INFO] Configuring Jetty for project: Camel :: Web
[INFO] Webapp source directory =
/Users/muellerc/workspaceApacheGit/camel/components/camel-web/src/main/webapp
[INFO] Reload Mechanic: automatic
[INFO] Classes =
/Users/muellerc/workspaceApacheGit/camel/components/camel-web/target/classes
[DEBUG] Starting Jetty Server ...
[DEBUG] Property com.sun.management.jmxremote=null was set
[DEBUG] Setting Connector: org.mortbay.jetty.nio.SelectChannelConnector on
port 8080
2010-02-21 22:21:41.835:INFO::Logging to STDERR via org.mortbay.log.StdErrLog
[INFO] Context path = /
[INFO] Tmp directory = determined at runtime
[INFO] Web defaults = org/mortbay/jetty/webapp/webdefault.xml
[INFO] Web overrides = none
[DEBUG] Adding artifact camel-core-2.3-SNAPSHOT.jar for WEB-INF/lib
[DEBUG] Adding artifact commons-logging-api-1.1.jar for WEB-INF/lib
[DEBUG] Adding artifact commons-management-1.0.jar for WEB-INF/lib
[DEBUG] Adding artifact camel-spring-2.3-SNAPSHOT.jar for WEB-INF/lib
[DEBUG] Adding artifact spring-context-2.5.6.jar for WEB-INF/lib
[DEBUG] Adding artifact aopalliance-1.0.jar for WEB-INF/lib
[DEBUG] Adding
[jira] Created: (MAVENUPLOAD-2782) Please upload objectify-led 1.1.0 to Maven repository
Please upload objectify-led 1.1.0 to Maven repository - Key: MAVENUPLOAD-2782 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2782 Project: Maven Upload Requests Issue Type: Wish Reporter: Steve Chaloner I'm a developer in objectify, and want to use the be.objectify groupId - you can find my details at http://www.objectify.be/objectify-led/team-list.html Thanks! - Steve -- 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-4667) Maven 2.2.1 XML parser fails to parse a UTF-8 POM that begins with a BOM
[
http://jira.codehaus.org/browse/MNG-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Catherine Tan updated MNG-4667:
-
Attachment: MNG-4667-updated.patch
I updated the patch to remove the encoding parameters and the readers/writers.
Thanks!
Maven 2.2.1 XML parser fails to parse a UTF-8 POM that begins with a BOM
Key: MNG-4667
URL: http://jira.codehaus.org/browse/MNG-4667
Project: Maven 2 3
Issue Type: Bug
Components: POM::Encoding
Affects Versions: 2.2.1
Reporter: Maria Catherine Tan
Attachments: MNG-4667-updated.patch, MNG-4667-with-encoding.patch,
MNG-4667.patch, pom.xml
I've seen a lot of issues related to this that were closed because they're a
duplicate of MNG-2254 but I think the fix for MNG-2254 doesn't fix this issue.
I'm using maven 2.2.1 and the build failed when the UTF-8 POM begins with a
BOM.
Here's the log when running clean install
{noformat}
Reason: Parse error reading POM. Reason: only whitespace content allowed
before start tag and not \uef (position: START_DOCUMENT seen \uef... @1:1)
for project unknown at /home/marica/quick/pom.xml
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parse error reading POM.
Reason: only whitespace content allowed before start tag and not \uef
(position: START_DOCUMENT seen \uef... @1:1) for project unknown at
/home/marica/quick/pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error
reading POM. Reason: only whitespace content allowed before start tag and not
\uef (position: START_DOCUMENT seen \uef... @1:1) for project unknown at
/home/marica/quick/pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1610)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1571)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
... 12 more
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: only
whitespace content allowed before start tag and not \uef (position:
START_DOCUMENT seen \uef... @1:1)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1528)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1407)
at
hidden.org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105)
at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:3911)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1606)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221986#action_221986 ] James Kato commented on SUREFIRE-377: - Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. When JUnit and TestNG tests are in same project, only one set gets run -- Key: SUREFIRE-377 URL: http://jira.codehaus.org/browse/SUREFIRE-377 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Reporter: Dan Fabulich Fix For: 2.4 Attachments: surefire377.patch, testng-junit-together.zip The attached Maven project has two tests: one JUnit test and one TestNG test. According to the documentation, in this case TestNG should run both tests. Run mvn test. Only the TestNG test will run. If you modify the pom to set the property junit=true, only the JUnit test will run. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4-SNAPSHOT/version configuration properties property namejunit/name valuetrue/value /property /properties /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] Issue Comment Edited: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221986#action_221986 ] James Kato edited comment on SUREFIRE-377 at 5/20/10 7:33 PM: -- Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.3/version configuration testNGArtifactNamenone:none/testNGArtifactName excludes exclude**/integration/*.java/exclude /excludes /configuration executions execution idintegration-test/id goals goaltest/goal /goals phaseintegration-test/phase configuration junitArtifactNamenone:none/junitArtifactName testNGArtifactNameorg.testng:testng/testNGArtifactName suiteXmlFiles suiteXmlFile src/test/resourcestestng.xml /suiteXmlFile /suiteXmlFiles excludes excludenone/exclude /excludes includes include**/integration/*.java/include /includes /configuration /execution /executions /plugin was (Author: kato): Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. When JUnit and TestNG tests are in same project, only one set gets run -- Key: SUREFIRE-377 URL: http://jira.codehaus.org/browse/SUREFIRE-377 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Reporter: Dan Fabulich Fix For: 2.4 Attachments: surefire377.patch, testng-junit-together.zip The attached Maven project has two tests: one JUnit test and one TestNG test. According to the documentation, in this case TestNG should run both tests. Run mvn test. Only the TestNG test will run. If you modify the pom to set the property junit=true, only the JUnit test will run. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4-SNAPSHOT/version configuration properties property namejunit/name valuetrue/value /property /properties /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] Issue Comment Edited: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221986#action_221986 ] James Kato edited comment on SUREFIRE-377 at 5/20/10 7:34 PM: -- Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. code plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.3/version configuration testNGArtifactNamenone:none/testNGArtifactName excludes exclude**/integration/*.java/exclude /excludes /configuration executions execution idintegration-test/id goals goaltest/goal /goals phaseintegration-test/phase configuration junitArtifactNamenone:none/junitArtifactName testNGArtifactNameorg.testng:testng/testNGArtifactName suiteXmlFiles suiteXmlFile src/test/resourcestestng.xml /suiteXmlFile /suiteXmlFiles excludes excludenone/exclude /excludes includes include**/integration/*.java/include /includes /configuration /execution /executions /plugin /code was (Author: kato): Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.3/version configuration testNGArtifactNamenone:none/testNGArtifactName excludes exclude**/integration/*.java/exclude /excludes /configuration executions execution idintegration-test/id goals goaltest/goal /goals phaseintegration-test/phase configuration junitArtifactNamenone:none/junitArtifactName testNGArtifactNameorg.testng:testng/testNGArtifactName suiteXmlFiles suiteXmlFile src/test/resourcestestng.xml /suiteXmlFile /suiteXmlFiles excludes excludenone/exclude /excludes includes include**/integration/*.java/include /includes /configuration /execution /executions /plugin When JUnit and TestNG tests are in same project, only one set gets run -- Key: SUREFIRE-377 URL: http://jira.codehaus.org/browse/SUREFIRE-377 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Reporter: Dan Fabulich Fix For: 2.4 Attachments: surefire377.patch, testng-junit-together.zip The attached Maven project has two tests: one JUnit test and one TestNG test. According to the documentation, in this case TestNG should run both tests. Run mvn test. Only the TestNG test will run. If you modify the pom to set the property junit=true, only the JUnit test will run. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4-SNAPSHOT/version configuration properties property namejunit/name valuetrue/value /property /properties /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] Issue Comment Edited: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221986#action_221986 ] James Kato edited comment on SUREFIRE-377 at 5/20/10 7:34 PM: -- Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.3/version configuration testNGArtifactNamenone:none/testNGArtifactName excludes exclude**/integration/*.java/exclude /excludes /configuration executions execution idintegration-test/id goals goaltest/goal /goals phaseintegration-test/phase configuration junitArtifactNamenone:none/junitArtifactName testNGArtifactNameorg.testng:testng/testNGArtifactName suiteXmlFiles suiteXmlFile src/test/resourcestestng.xml /suiteXmlFile /suiteXmlFiles excludes excludenone/exclude /excludes includes include**/integration/*.java/include /includes /configuration /execution /executions /plugin was (Author: kato): Aleksei's fix works well, but I just had to mess about with the default execution, so here is a variation using Aleksei's solution. code plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.3/version configuration testNGArtifactNamenone:none/testNGArtifactName excludes exclude**/integration/*.java/exclude /excludes /configuration executions execution idintegration-test/id goals goaltest/goal /goals phaseintegration-test/phase configuration junitArtifactNamenone:none/junitArtifactName testNGArtifactNameorg.testng:testng/testNGArtifactName suiteXmlFiles suiteXmlFile src/test/resourcestestng.xml /suiteXmlFile /suiteXmlFiles excludes excludenone/exclude /excludes includes include**/integration/*.java/include /includes /configuration /execution /executions /plugin /code When JUnit and TestNG tests are in same project, only one set gets run -- Key: SUREFIRE-377 URL: http://jira.codehaus.org/browse/SUREFIRE-377 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Reporter: Dan Fabulich Fix For: 2.4 Attachments: surefire377.patch, testng-junit-together.zip The attached Maven project has two tests: one JUnit test and one TestNG test. According to the documentation, in this case TestNG should run both tests. Run mvn test. Only the TestNG test will run. If you modify the pom to set the property junit=true, only the JUnit test will run. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4-SNAPSHOT/version configuration properties property namejunit/name valuetrue/value /property /properties /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] Issue Comment Edited: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[
http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221986#action_221986
]
James Kato edited comment on SUREFIRE-377 at 5/20/10 7:39 PM:
--
Aleksei's fix works well, but I just had to mess about with the default
execution, so here is a variation using Aleksei's solution.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testNGArtifactNamenone:none/testNGArtifactName
excludes
exclude**/integration/*.java/exclude
/excludes
/configuration
executions
execution
idintegration-test/id
goals
goaltest/goal
/goals
phaseintegration-test/phase
configuration
junitArtifactNamenone:none/junitArtifactName
testNGArtifactNameorg.testng:testng/testNGArtifactName
suiteXmlFiles
suiteXmlFile
src/test/resourcestestng.xml
/suiteXmlFile
/suiteXmlFiles
excludes
excludenone/exclude
/excludes
includes
include**/integration/*.java/include
/includes
/configuration
/execution
/executions
/plugin
{code}
was (Author: kato):
Aleksei's fix works well, but I just had to mess about with the default
execution, so here is a variation using Aleksei's solution.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testNGArtifactNamenone:none/testNGArtifactName
excludes
exclude**/integration/*.java/exclude
/excludes
/configuration
executions
execution
idintegration-test/id
goals
goaltest/goal
/goals
phaseintegration-test/phase
configuration
junitArtifactNamenone:none/junitArtifactName
testNGArtifactNameorg.testng:testng/testNGArtifactName
suiteXmlFiles
suiteXmlFile
src/test/resourcestestng.xml
/suiteXmlFile
/suiteXmlFiles
excludes
excludenone/exclude
/excludes
includes
include**/integration/*.java/include
/includes
/configuration
/execution
/executions
/plugin
When JUnit and TestNG tests are in same project, only one set gets run
--
Key: SUREFIRE-377
URL: http://jira.codehaus.org/browse/SUREFIRE-377
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4
Reporter: Dan Fabulich
Fix For: 2.4
Attachments: surefire377.patch, testng-junit-together.zip
The attached Maven project has two tests: one JUnit test and one TestNG test.
According to the documentation, in this case TestNG should run both tests.
Run mvn test. Only the TestNG test will run. If you modify the pom to set
the property junit=true, only the JUnit test will run.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4-SNAPSHOT/version
configuration
properties
property
namejunit/name
valuetrue/value
/property
/properties
/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] Issue Comment Edited: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[
http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221986#action_221986
]
James Kato edited comment on SUREFIRE-377 at 5/20/10 7:41 PM:
--
Aleksei's fix works well, thanks! I just had to mess about with the default
execution, so here is a variation using Aleksei's solution.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testNGArtifactNamenone:none/testNGArtifactName
excludes
exclude**/integration/*.java/exclude
/excludes
/configuration
executions
execution
idintegration-test/id
goals
goaltest/goal
/goals
phaseintegration-test/phase
configuration
junitArtifactNamenone:none/junitArtifactName
testNGArtifactNameorg.testng:testng/testNGArtifactName
suiteXmlFiles
suiteXmlFile
src/test/resourcestestng.xml
/suiteXmlFile
/suiteXmlFiles
excludes
excludenone/exclude
/excludes
includes
include**/integration/*.java/include
/includes
/configuration
/execution
/executions
/plugin
{code}
was (Author: kato):
Aleksei's fix works well, but I just had to mess about with the default
execution, so here is a variation using Aleksei's solution.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testNGArtifactNamenone:none/testNGArtifactName
excludes
exclude**/integration/*.java/exclude
/excludes
/configuration
executions
execution
idintegration-test/id
goals
goaltest/goal
/goals
phaseintegration-test/phase
configuration
junitArtifactNamenone:none/junitArtifactName
testNGArtifactNameorg.testng:testng/testNGArtifactName
suiteXmlFiles
suiteXmlFile
src/test/resourcestestng.xml
/suiteXmlFile
/suiteXmlFiles
excludes
excludenone/exclude
/excludes
includes
include**/integration/*.java/include
/includes
/configuration
/execution
/executions
/plugin
{code}
When JUnit and TestNG tests are in same project, only one set gets run
--
Key: SUREFIRE-377
URL: http://jira.codehaus.org/browse/SUREFIRE-377
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.4
Reporter: Dan Fabulich
Fix For: 2.4
Attachments: surefire377.patch, testng-junit-together.zip
The attached Maven project has two tests: one JUnit test and one TestNG test.
According to the documentation, in this case TestNG should run both tests.
Run mvn test. Only the TestNG test will run. If you modify the pom to set
the property junit=true, only the JUnit test will run.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4-SNAPSHOT/version
configuration
properties
property
namejunit/name
valuetrue/value
/property
/properties
/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] Closed: (MANTRUN-100) Allow antrun plugin to attach artifacts to maven build
[ http://jira.codehaus.org/browse/MANTRUN-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTRUN-100. - Resolution: Fixed Fixed in [r946867|http://svn.apache.org/viewvc?view=revisionrevision=946867] Allow antrun plugin to attach artifacts to maven build -- Key: MANTRUN-100 URL: http://jira.codehaus.org/browse/MANTRUN-100 Project: Maven 2.x Antrun Plugin Issue Type: New Feature Reporter: Paul Gier Assignee: Paul Gier Fix For: 1.4 It would be useful if a jar or zip file created by the antrun plugin could be attached to the maven build lifecycle and deployed to the repository. -- 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: (MANTRUN-51) Problems with multiple antrun declarations in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MANTRUN-51.
Resolution: Fixed
Assignee: Paul Gier
Documentation about this issue was added to the site FAQ in
[r790402|http://svn.apache.org/viewvc?view=revrevision=790402].
A note about it has also been added to the plugin [wiki
page|http://docs.codehaus.org/display/MAVENUSER/Antrun+Plugin]
Problems with multiple antrun declarations in multiproject
--
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
Assignee: Paul Gier
Fix For: 1.4
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be
found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing
ant tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
[jira] Updated: (MANTRUN-129) Please add as 'skip' parameter
[ http://jira.codehaus.org/browse/MANTRUN-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-129: -- Fix Version/s: (was: 1.4) Please add as 'skip' parameter -- Key: MANTRUN-129 URL: http://jira.codehaus.org/browse/MANTRUN-129 Project: Maven 2.x Antrun Plugin Issue Type: New Feature Affects Versions: 1.3 Reporter: Benson Margulies In some structures involving parent poms, it is very helpful when plugin have a 'skip' parameter, so that an execution which is inherited through an entire forest of projects can be selectively turned on and off. Other plugins have this. -- 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-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[
http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222001#action_222001
]
A commented on SUREFIRE-576:
I've tested the new commit. It appears to be working for my purposes - testing
a packaged for distribution product rather than the project compiled classes.
Thank you for implementing this feature!
I'm putting below a sample configuration just for a reference. I see that
system dependencies can be excluded either by the test scope or with their
group and artifact id. Also the build classes can be excluded by configuring a
fake location for them and although looking hacky, this method seems reasonable
to me.
{code:xml}
profile
idproduct-test/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.6-SNAPSHOT/version
configuration
classesDirectoryfakeClassesDirectory/classesDirectory
!--
testClassesDirectoryfakeTestClassesDirectory/testClassesDirectory --
classpathDependencyScopeExcluderuntime/classpathDependencyScopeExclude
classpathDependencyExcludes
excludeorg.apache.commons:*/exclude
excludetestGrp:testId/exclude
/classpathDependencyExcludes
additionalClasspathElements
additionalClasspathElement/path/to/product/installation/artifact1.jar/additionalClasspathElement
additionalClasspathElement/path/to/product/installation/artifact2.jar/additionalClasspathElement
/additionalClasspathElements
/configuration
/plugin
/plugins
/build
/profile
{code}
Then tester should look at the mvn -Pproduct-test -X output (search for Test
Classpath)to verify classpath is what's expected. btw it will become more
convenient once MNG-2570 is resolved and debug logging only from the
SurefirePlugin class can be enabled through CLI rather than full debug of
everything.
Have the abiltiy to remove a dependency from the test classpath (at least
optional ones
---
Key: SUREFIRE-576
URL: http://jira.codehaus.org/browse/SUREFIRE-576
Project: Maven Surefire
Issue Type: New Feature
Components: classloading, Maven Surefire Plugin
Reporter: Hardy Ferentschik
Assignee: Paul Gier
Fix For: 2.6
--
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
