[jira] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304311#comment-304311
]
Yegor Bugayenko commented on MCOMPILER-178:
---
see also some discussion here: http://stackoverflow.com/questions/11339056
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-654) Release:perform fails on releasing a tag from an empty directory
[
https://jira.codehaus.org/browse/MRELEASE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304321#comment-304321
]
Jameson Porter edited comment on MRELEASE-654 at 7/23/12 8:21 AM:
--
Yes, I was able to get around it as well by providing a bootstrap pom.xml:
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
...
release
pom
Release
1.0.0
...
...
target
2.3
${basedir}/${target.dir}/classes
${basedir}/${target.dir}/test-classes
org.apache.maven.plugins
maven-release-plugin
${release.plugin.version}
org.apache.maven.plugins
maven-release-plugin
${release.plugin.version}
...
...
{code}
It would be nice if the default pom used by maven when there is none provided
were sufficient or if the release plugin was able to check out the pom(s) from
the tag specified in the release.properties.
was (Author: alhizeer):
Yes, I was able to get around it as well by providing a bootstrap pom.xml:
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
...
release
pom
Release
1.0.0
...
...
target
2.3
${basedir}/${target.dir}/classes
${basedir}/${target.dir}/test-classes
org.apache.maven.plugins
maven-release-plugin
${release.plugin.version}
org.apache.maven.plugins
maven-release-plugin
${release.plugin.version}
...
...
{code}
It would be nice if the default pom used by maven when there is none provided
were sufficient or if the release plugin was able to check out the pom(s) from
the tag specified in the release.properties.
> Release:perform fails on releasing a tag from an empty directory
>
>
> Key: MRELEASE-654
> URL: https://jira.codehaus.org/browse/MRELEASE-654
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.1
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"
>Reporter: Giacomo Boccardo
>
> If we release our project from the same directory when we executed the
> release:prepare the perform phase completes successfully, while performing a
> release from a tag (in an empty directory) we have the following stack trace:
> {noformat}
> $ mvn release:perform -Dtag=unilet-base-5.3.13
> -DconnectionUrl=scm:svn:https://srvdevel.unimatica.lan/svn/unilet -X
> Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"
> [INFO] Error stacktraces are turned on.
> [DEBUG] Reading global settings from /usr/local/app/maven/conf/settings.xml
> [DEBUG] Reading user settings from /home/gboccardo/.m2/settings.xml
> [DEBUG] Using local repository at /home/gboccardo/.m2/repository
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for
> /home/gboccardo/.m2/repository
> [INFO] Scanning for projects...
> [DEBUG] Extension realms for project org.apache.maven:standalone-pom:pom:1:
> (none)
> [DEBUG] Looking up lifecyle mappings for packaging pom from
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
> org.codehaus.mojo]
> [DEBUG] Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> org.apache.maven:standalone-pom:pom:1
> [DEBUG] === REACTOR BUILD PLAN
>
> [DEBUG] Project: org.apache.maven:standalone-pom:pom:1
> [DEBUG] Tasks: [release:perform]
> [DEBUG] Style: Aggregatin
[jira] (MRELEASE-654) Release:perform fails on releasing a tag from an empty directory
[
https://jira.codehaus.org/browse/MRELEASE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304321#comment-304321
]
Jameson Porter commented on MRELEASE-654:
-
Yes, I was able to get around it as well by providing a bootstrap pom.xml:
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
...
release
pom
Release
1.0.0
...
...
target
2.3
${basedir}/${target.dir}/classes
${basedir}/${target.dir}/test-classes
org.apache.maven.plugins
maven-release-plugin
${release.plugin.version}
org.apache.maven.plugins
maven-release-plugin
${release.plugin.version}
...
...
{code}
It would be nice if the default pom used by maven when there is none provided
were sufficient or if the release plugin was able to check out the pom(s) from
the tag specified in the release.properties.
> Release:perform fails on releasing a tag from an empty directory
>
>
> Key: MRELEASE-654
> URL: https://jira.codehaus.org/browse/MRELEASE-654
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.1
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"
>Reporter: Giacomo Boccardo
>
> If we release our project from the same directory when we executed the
> release:prepare the perform phase completes successfully, while performing a
> release from a tag (in an empty directory) we have the following stack trace:
> {noformat}
> $ mvn release:perform -Dtag=unilet-base-5.3.13
> -DconnectionUrl=scm:svn:https://srvdevel.unimatica.lan/svn/unilet -X
> Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35-25-generic", arch: "amd64", family: "unix"
> [INFO] Error stacktraces are turned on.
> [DEBUG] Reading global settings from /usr/local/app/maven/conf/settings.xml
> [DEBUG] Reading user settings from /home/gboccardo/.m2/settings.xml
> [DEBUG] Using local repository at /home/gboccardo/.m2/repository
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for
> /home/gboccardo/.m2/repository
> [INFO] Scanning for projects...
> [DEBUG] Extension realms for project org.apache.maven:standalone-pom:pom:1:
> (none)
> [DEBUG] Looking up lifecyle mappings for packaging pom from
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
> org.codehaus.mojo]
> [DEBUG] Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> org.apache.maven:standalone-pom:pom:1
> [DEBUG] === REACTOR BUILD PLAN
>
> [DEBUG] Project: org.apache.maven:standalone-pom:pom:1
> [DEBUG] Tasks: [release:perform]
> [DEBUG] Style: Aggregating
> [DEBUG]
> ===
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
> org.codehaus.mojo]
> [DEBUG] Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> org.apache.maven:standalone-pom:pom:1
> [DEBUG] Lifecycle default -> [validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy]
> [DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
> [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
> [DEBUG] === PROJECT BUILD PLAN
> =
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail
[ https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304325#comment-304325 ] Rene Krell commented on MNG-4831: - Has there been any progress with this issue? Maybe in newer Maven versions? Actually, loosing transitive dependencies just because they are filtered out in the appropriate POM makes using of dependencysets with maven-assembly-plugin very difficult (tested with Maven 2.2.1). > artifact.getDependencyTrail() doesn't include full information; causes > problems filtering artifacts by transitive dependency trail > -- > > Key: MNG-4831 > URL: https://jira.codehaus.org/browse/MNG-4831 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-beta-3 >Reporter: John Casey > > Artifact.getDependencyTrail() is a List, not a graph. This means the artifact > doesn't include information about every artifact that depends on that > artifact. > In cases where the project's artifacts are filtered using the dependency > trail, it can become impossible to capture the full dependency closure for an > included artifact if that artifact depends on something that an excluded > artifact also depends on. > For a concrete example / test case of this, see MASSEMBLY-504. > In this example, A and B both depend on C. However, the dependencySet > _excludes_ B from the assembly. By luck of the draw, profile dependencies are > appended to the project's other dependencies, and B is in the dependencyTrail > of C, not A (both are valid to be there). Since transitive filtering is > enabled, C is _excluded_ from the assembly along with B, and the classpath > for A is not fully represented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail
[ https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304325#comment-304325 ] Rene Krell edited comment on MNG-4831 at 7/23/12 9:00 AM: -- Has there been any progress with this issue? Maybe in newer Maven versions? Actually, loosing transitive dependencies just because they are filtered out in the appropriate POM based on the order they are defined in the POM makes using of dependencysets with maven-assembly-plugin difficult and intransparent(tested with Maven 2.2.1). was (Author: rkrell): Has there been any progress with this issue? Maybe in newer Maven versions? Actually, loosing transitive dependencies just because they are filtered out in the appropriate POM makes using of dependencysets with maven-assembly-plugin very difficult (tested with Maven 2.2.1). > artifact.getDependencyTrail() doesn't include full information; causes > problems filtering artifacts by transitive dependency trail > -- > > Key: MNG-4831 > URL: https://jira.codehaus.org/browse/MNG-4831 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-beta-3 >Reporter: John Casey > > Artifact.getDependencyTrail() is a List, not a graph. This means the artifact > doesn't include information about every artifact that depends on that > artifact. > In cases where the project's artifacts are filtered using the dependency > trail, it can become impossible to capture the full dependency closure for an > included artifact if that artifact depends on something that an excluded > artifact also depends on. > For a concrete example / test case of this, see MASSEMBLY-504. > In this example, A and B both depend on C. However, the dependencySet > _excludes_ B from the assembly. By luck of the draw, profile dependencies are > appended to the project's other dependencies, and B is in the dependencyTrail > of C, not A (both are valid to be there). Since transitive filtering is > enabled, C is _excluded_ from the assembly along with B, and the classpath > for A is not fully represented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-167) .component assumes all dependencies should be packaged in WAR
[ https://jira.codehaus.org/browse/MECLIPSE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Ledanseur updated MECLIPSE-167: - Attachment: MECLIPSE-167.patch > .component assumes all dependencies should be packaged in WAR > - > > Key: MECLIPSE-167 > URL: https://jira.codehaus.org/browse/MECLIPSE-167 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Reporter: Shelley Baker >Priority: Critical > Attachments: MECLIPSE-167.patch, MECLIPSE-167.zip > > > Our applications are packaged such that the JAR dependencies are packaged > within the EAR, not the WARs. The dependencies are listed in the WAR in > order to generate the MANIFEST.MF class-path entries, and to add compile > dependencies to the .classpath. These dependencies are excluded from the > packaged WAR, however, via the maven-war-plugin's warSourceExcludes > configuration: WEB-INF/lib/*.jar since > they reference the EAR. [Related: MWAR-9] > The Eclipse Plugin WTP configuration file generation currently assumes that > all WAR project dependencies should be packaged and deployed in the WAR. > Each dependency is listed as a "dependent-module" with a deploy-path of > "/WEB-INF/lib" in the .component file. > This causes the dependencies to be duplicated and packaged in the EAR and in > every WAR when the project is published to an app server. > The eclipse-plugin should expose additional WTP configuration or read the > war-plugin's configuration in order to exclude these dependencies from being > packaged and deployed within the WAR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-167) .component assumes all dependencies should be packaged in WAR
[ https://jira.codehaus.org/browse/MECLIPSE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304339#comment-304339 ] David Ledanseur commented on MECLIPSE-167: -- Here is a patch that allows excluding some artifacts from the WEB-INF/lib folder. It follows the given guideline : http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html i.e. dependencies marked as optional are excluded from the packaging > .component assumes all dependencies should be packaged in WAR > - > > Key: MECLIPSE-167 > URL: https://jira.codehaus.org/browse/MECLIPSE-167 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Reporter: Shelley Baker >Priority: Critical > Attachments: MECLIPSE-167.patch, MECLIPSE-167.zip > > > Our applications are packaged such that the JAR dependencies are packaged > within the EAR, not the WARs. The dependencies are listed in the WAR in > order to generate the MANIFEST.MF class-path entries, and to add compile > dependencies to the .classpath. These dependencies are excluded from the > packaged WAR, however, via the maven-war-plugin's warSourceExcludes > configuration: WEB-INF/lib/*.jar since > they reference the EAR. [Related: MWAR-9] > The Eclipse Plugin WTP configuration file generation currently assumes that > all WAR project dependencies should be packaged and deployed in the WAR. > Each dependency is listed as a "dependent-module" with a deploy-path of > "/WEB-INF/lib" in the .component file. > This causes the dependencies to be duplicated and packaged in the EAR and in > every WAR when the project is published to an app server. > The eclipse-plugin should expose additional WTP configuration or read the > war-plugin's configuration in order to exclude these dependencies from being > packaged and deployed within the WAR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304340#comment-304340
]
Dennis Lundberg commented on MCOMPILER-178:
---
You can use the other syntax instead, like this:
{code:xml}
-Xlint:-path
{code}
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304345#comment-304345
]
Yegor Bugayenko commented on MCOMPILER-178:
---
Yes, but only for a single argument
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304346#comment-304346
]
Dennis Lundberg commented on MCOMPILER-178:
---
Can you please put together a minimal buildable project that exhibits the
problems you describe?
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304350#comment-304350
]
Yegor Bugayenko commented on MCOMPILER-178:
---
This is my configuration:
{noformat}
maven-compiler-plugin
{noformat}
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-339) tree mojo doesn't work with maven3
[ https://jira.codehaus.org/browse/MDEP-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MDEP-339: --- Comment: was deleted (was: fixed in [r1348664|http://svn.apache.org/viewvc?rev=1348664&view=rev]) > tree mojo doesn't work with maven3 > -- > > Key: MDEP-339 > URL: https://jira.codehaus.org/browse/MDEP-339 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: tree >Reporter: Olivier Lamy >Assignee: Herve Boutemy > Fix For: 2.5 > > > didn't find any issue. But I have something working with m2 and m3 so add an > issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-339) tree mojo doesn't work with maven3
[ https://jira.codehaus.org/browse/MDEP-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MDEP-339: --- Comment: was deleted (was: sorry, this one is not fixed yet but MPIR-237) > tree mojo doesn't work with maven3 > -- > > Key: MDEP-339 > URL: https://jira.codehaus.org/browse/MDEP-339 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: tree >Reporter: Olivier Lamy >Assignee: Herve Boutemy > Fix For: 2.5 > > > didn't find any issue. But I have something working with m2 and m3 so add an > issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-827) Surefire 2.12 cannot run a single test, regression from 2.11
[ https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304355#comment-304355 ] Andrew Gaul commented on SUREFIRE-827: -- Verified fixed in r1364394. Thank you for your persistence Kristian. > Surefire 2.12 cannot run a single test, regression from 2.11 > > > Key: SUREFIRE-827 > URL: https://jira.codehaus.org/browse/SUREFIRE-827 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.12 > Environment: Ubuntu 11.10 >Reporter: Andrew Gaul >Assignee: Kristian Rosenvold > Fix For: 2.12.1 > > Attachments: BUG-827.zip > > > # Surefire 2.11 > $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile > ... > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > # Surefire 2.12 > mvn test -Dtest=DataTest#testDataServerGetNonExistentFile > ... > Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-646) Brackets not working when generating links using site plugin
Liviu Tudor created MSITE-646:
-
Summary: Brackets not working when generating links using site
plugin
Key: MSITE-646
URL: https://jira.codehaus.org/browse/MSITE-646
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Environment: MacOSX Lion 64 bit
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/java/maven-3.0.3
Java version: 1.6.0_33, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"
Reporter: Liviu Tudor
Attachments: aggregator.xml
This was discovered together with Simone Tripodi when dealing with the Apache
Commons Functor project (http://commons.apache.org/functor/): I've put together
the attached file which include some links to the javadoc section of the site
(generated using maven site plugin).
Some links are links to the classes/interfaces or packages -- and these work.
Example:
{code:xml}
ArrayListBackedAggregator
{code}
However, where the link is meant to be a link to the method javadoc directly,
and as such it includes brackets, the brackets are lost it the process of
generating the html. Example:
{code:xml}
createList()
{code}
generates (you can see this on the live site here
http://commons.apache.org/functor/aggregator.html):
{code:xml}
createList()
{code}
Same happens if the method has parameters:
{code:xml}
add()
{code}
generates
{code:xml}
add()
{code}
I am attaching the original xml file to this. I use a Mac but I believe Simo
uses a Linux -- so it's not something to do with encoding I don't think. (As a
side note we have actually changed various encoding settings to get the same
result.)
Please let me know if there is anything else we need to provide you with.
Kind regards,
Liv
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
