[jira] (SUREFIRE-843) Unable to run 'mvn test' with Java 7
[
https://jira.codehaus.org/browse/SUREFIRE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niraj Tolia closed SUREFIRE-843.
Resolution: Not A Bug
Turned out the problem was with an external library that was calling
System.exit(). This seems to be a timing problem that has never been triggered
by Java 6 (hundreds of 'mvn test' runs) but reliably occurs with Java 7.
> Unable to run 'mvn test' with Java 7
>
>
> Key: SUREFIRE-843
> URL: https://jira.codehaus.org/browse/SUREFIRE-843
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.12
> Environment: Mac OS X
> java version "1.7.0_04-ea"
> Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15, mixed mode)
>Reporter: Niraj Tolia
>
> I am trying to run mvn test and it always fails at some arbitrary time with
> the message 'Error occurred in starting fork'. See the output below. Note
> that it does not execute all tests but fails in between the test run. The
> number of tests surefire finishes executing is random but it has never
> completed the entire test run. I am using Java7u4 Build b13 with Maven 3.0.3
> and surefire v2.12.
> Any clue what might be going wrong? This is a blocker for me.
> {noformat}
> Results :
> Tests run: 230, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 41.204s
> [INFO] Finished at: Thu Feb 23 17:40:55 PST 2012
> [INFO] Final Memory: 17M/212M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on
> project test-project: Error occurred in starting fork, check output in log ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test)
> on project test-project: Error occurred in starting fork, check output in log
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error occurred in
> starting fork, check output in log
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:656)
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:645)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.surefire.booter.Su
[jira] (MJAVADOC-332) outputDirectory is not honored as it should, but valuated to destDir.
[
https://jira.codehaus.org/browse/MJAVADOC-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293626#comment-293626
]
Paolo Compieta commented on MJAVADOC-332:
-
Happens also on Ubuntu:
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-32-generic", arch: "amd64", family: "unix"
> outputDirectory is not honored as it should, but valuated to destDir.
> -
>
> Key: MJAVADOC-332
> URL: https://jira.codehaus.org/browse/MJAVADOC-332
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: WXP SP3 JDK 1.6.0_26 Maven 3.0
>Reporter: zosrothko
>
> Hi
> The outputDirectory is referencing ${destDir} instead of ${outputDirectory}
> as per following snippet extracted from AbstractJavadocMojo.java
> /**
> * Specifies the destination directory where javadoc saves the generated
> HTML files.
> *
> * See href="http://download.oracle.com/javase/1.4.2/docs/tooldocs/windows/javadoc.html#d";>d.
> *
> *
> * @parameter expression="${destDir}" alias="destDir"
> default-alue="${project.build.directory}/apidocs"
> * @required
> */
> protected File outputDirectory;
--
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-2163) Allow plugin dependencies to be excluded
[ https://jira.codehaus.org/browse/MNG-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293633#comment-293633 ] Jörg von Frantzius commented on MNG-2163: - I'd put it that way: it should be possible to define the plugins classpath using the same concepts as the dependencies classpath. Which includes "exclusions" ;) > Allow plugin dependencies to be excluded > > > Key: MNG-2163 > URL: https://jira.codehaus.org/browse/MNG-2163 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.2 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson > Fix For: Issues to be reviewed for 3.x > > > Need to add an exclusions block in the POM for plugins. The use-case is > excluding slf4j-simple > from the jetty6 plugin in order to use an alternative slf4j implementation. -- 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-849) Properites groups and excludedGroups do not enable JUnit47 provider
Marcin Kuthan created SUREFIRE-849:
--
Summary: Properites groups and excludedGroups do not enable
JUnit47 provider
Key: SUREFIRE-849
URL: https://jira.codehaus.org/browse/SUREFIRE-849
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.12
Reporter: Marcin Kuthan
I'm trying to define {{groups}} or {{excludeGroups}} for JUnit execution. When
I define property, JUnit4 provider is used, and the groups are ignored. To
enable group support I have to define {{parallel}} parameter or define JUnit47
provider explicitly as plugin dependency.
The plugin documentation is also inconsistent. The following goals
documentation defines, that JUnit47 provider will be enabled:
[http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#groups]
[http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#excludedGroups]
But on
[http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html],
the formula for provider selection define only {{parallel}} parameter.
--
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-5178) Substitute environment variable M2_HOME by M3_HOME
[
https://jira.codehaus.org/browse/MNG-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293671#comment-293671
]
Joerg Schaible commented on MNG-5178:
-
And why do you set the env variable at all?
> Substitute environment variable M2_HOME by M3_HOME
> --
>
> Key: MNG-5178
> URL: https://jira.codehaus.org/browse/MNG-5178
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Command Line
>Reporter: Oliver B. Fischer
>Priority: Minor
>
> Maven 3 uses the environment variable {{M2_HOME}} to point to it's
> installation directory. This variable should be replaced by {{M3_HOME}} to
> allow users to have parallel installations of Maven 2 and Maven 3 without any
> special handling of the environment variable {{M2_HOME}}.
--
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-5257) BuildNumber plugin does not work with maven 3
Brian Demers created MNG-5257: - Summary: BuildNumber plugin does not work with maven 3 Key: MNG-5257 URL: https://jira.codehaus.org/browse/MNG-5257 Project: Maven 2 & 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 3.0.4, 3.0.3 Reporter: Brian Demers Example: Shiro 1.2 uses the build number plugin see: http://search.maven.org/remotecontent?filepath=org/apache/shiro/shiro-root/1.2.0/shiro-root-1.2.0.pom If you build with maven 3 the buildNumber property is not interpolated. See uninterpolated property here: https://repository.sonatype.org/service/local/repositories/central-proxy/archive/org/apache/shiro/shiro-core/1.2.0/shiro-core-1.2.0.jar/!/META-INF/MANIFEST.MF NOTE: building this same project with maven 2.2.1 sets the buildNumber property correctly. Tested with buildnumber plugin 1.0-beta-4, 1.0, and 1.1-SNAPSHOT -- 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] (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
[ https://jira.codehaus.org/browse/MSHADE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHADE-105: Fix Version/s: 1.6 Assignee: Olivier Lamy > Classes processed by the relocator still have references to the original > classes in their constant pools > > > Key: MSHADE-105 > URL: https://jira.codehaus.org/browse/MSHADE-105 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Andreas Veithen >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: constant-pool.patch, javap2.txt, javap.txt > > > DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of > ClassWriter(int). According to the ASM Javadoc, this has the following > effects: > "- The constant pool from the original class is copied as is in the new > class, which saves time. New constant pool entries will be added at the end > if necessary, but unused constant pool entries won't be removed. > - Methods that are not transformed are copied as is in the new class, > directly from the original class bytecode (i.e. without emitting visit events > for all the method instructions), which saves a lot of time. Untransformed > methods are detected by the fact that the ClassReader receives MethodVisitor > objects that come from a ClassWriter (and not from a custom ClassAdapter or > any other ClassVisitor instance)." > The second item is actually not applicable in the case of DefaultShader > because the entire class needs to be transformed anyway. On the other hand, > the first item implies that the constant pool of the transformed class will > still have references to the original classes. This can be seen from the > attached "javap.txt" file (produced by javap on a class relocated by > maven-shade-plugin): the relocation adds new entries at the end of the > constant pool, but the original entries are still present. > Since the original entries are no longer referenced anywhere in the class, > this has no consequences at runtime. However, some tools such as Felix' > maven-bundle-plugin use the constant pool to determine the dependencies of a > class. The effect is that if such a shaded JAR is embedded into a bundle > using maven-bundle-plugin, it will generate spurious Import-Package > instructions referring to the original package names. An example of this is > described in AXIS2-5145. > The solution to this problem is simply not to pass the ClassReader object to > the ClassWriter constructor. With this change, the constant pool is properly > cleaned up (see the attached "javap2.txt" file). -- 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] (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
[ https://jira.codehaus.org/browse/MSHADE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293685#comment-293685 ] Olivier Lamy commented on MSHADE-105: - Hello, I wonder if you have a sample project to reproduce that ? I'd like to have a it test. Thanks in advance. > Classes processed by the relocator still have references to the original > classes in their constant pools > > > Key: MSHADE-105 > URL: https://jira.codehaus.org/browse/MSHADE-105 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Andreas Veithen >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: constant-pool.patch, javap2.txt, javap.txt > > > DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of > ClassWriter(int). According to the ASM Javadoc, this has the following > effects: > "- The constant pool from the original class is copied as is in the new > class, which saves time. New constant pool entries will be added at the end > if necessary, but unused constant pool entries won't be removed. > - Methods that are not transformed are copied as is in the new class, > directly from the original class bytecode (i.e. without emitting visit events > for all the method instructions), which saves a lot of time. Untransformed > methods are detected by the fact that the ClassReader receives MethodVisitor > objects that come from a ClassWriter (and not from a custom ClassAdapter or > any other ClassVisitor instance)." > The second item is actually not applicable in the case of DefaultShader > because the entire class needs to be transformed anyway. On the other hand, > the first item implies that the constant pool of the transformed class will > still have references to the original classes. This can be seen from the > attached "javap.txt" file (produced by javap on a class relocated by > maven-shade-plugin): the relocation adds new entries at the end of the > constant pool, but the original entries are still present. > Since the original entries are no longer referenced anywhere in the class, > this has no consequences at runtime. However, some tools such as Felix' > maven-bundle-plugin use the constant pool to determine the dependencies of a > class. The effect is that if such a shaded JAR is embedded into a bundle > using maven-bundle-plugin, it will generate spurious Import-Package > instructions referring to the original package names. An example of this is > described in AXIS2-5145. > The solution to this problem is simply not to pass the ClassReader object to > the ClassWriter constructor. With this change, the constant pool is properly > cleaned up (see the attached "javap2.txt" file). -- 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] (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
[ https://jira.codehaus.org/browse/MSHADE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293687#comment-293687 ] Olivier Lamy commented on MSHADE-105: - patch committed r1298572. If you can provide a sample project that will be lovely :-) (one which generate a bad Import-Package ) > Classes processed by the relocator still have references to the original > classes in their constant pools > > > Key: MSHADE-105 > URL: https://jira.codehaus.org/browse/MSHADE-105 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Andreas Veithen >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: constant-pool.patch, javap2.txt, javap.txt > > > DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of > ClassWriter(int). According to the ASM Javadoc, this has the following > effects: > "- The constant pool from the original class is copied as is in the new > class, which saves time. New constant pool entries will be added at the end > if necessary, but unused constant pool entries won't be removed. > - Methods that are not transformed are copied as is in the new class, > directly from the original class bytecode (i.e. without emitting visit events > for all the method instructions), which saves a lot of time. Untransformed > methods are detected by the fact that the ClassReader receives MethodVisitor > objects that come from a ClassWriter (and not from a custom ClassAdapter or > any other ClassVisitor instance)." > The second item is actually not applicable in the case of DefaultShader > because the entire class needs to be transformed anyway. On the other hand, > the first item implies that the constant pool of the transformed class will > still have references to the original classes. This can be seen from the > attached "javap.txt" file (produced by javap on a class relocated by > maven-shade-plugin): the relocation adds new entries at the end of the > constant pool, but the original entries are still present. > Since the original entries are no longer referenced anywhere in the class, > this has no consequences at runtime. However, some tools such as Felix' > maven-bundle-plugin use the constant pool to determine the dependencies of a > class. The effect is that if such a shaded JAR is embedded into a bundle > using maven-bundle-plugin, it will generate spurious Import-Package > instructions referring to the original package names. An example of this is > described in AXIS2-5145. > The solution to this problem is simply not to pass the ClassReader object to > the ClassWriter constructor. With this change, the constant pool is properly > cleaned up (see the attached "javap2.txt" file). -- 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] [Commented] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225583#comment-13225583 ] Sebb commented on MPOM-32: -- Furthermore, the "license" report is not supposed to be used on ASF websites: sites should link to the ASF license page instead => http://www.apache.org/licenses/ > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225705#comment-13225705 ] Sebb commented on MPOM-32: -- In ASF-9, the list of reports was left empty. That worked fine; if a child pom did not specify any reports, all of them were generated. And if the child specified just some of the reports, just those were generated. However, with ASF-10, all the reports are always generated - it does not appear to be possible to override the set of reports. I tried using false as per [1] but that does not work. [1]http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_inherited_Tag_In_Reporting_Plugins > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225705#comment-13225705 ] Sebb edited comment on MPOM-32 at 3/9/12 12:17 AM: --- In ASF-9, the list of reports was not provided. That worked fine; if a child pom did not specify any reports, all of them were generated. And if the child specified just some of the reports, just those were generated. However, with ASF-10, all the reports are always generated - it does not appear to be possible to override the set of reports. I tried using false as per [1] but that does not work. [1]http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_inherited_Tag_In_Reporting_Plugins was (Author: s...@apache.org): In ASF-9, the list of reports was left empty. That worked fine; if a child pom did not specify any reports, all of them were generated. And if the child specified just some of the reports, just those were generated. However, with ASF-10, all the reports are always generated - it does not appear to be possible to override the set of reports. I tried using false as per [1] but that does not work. [1]http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_inherited_Tag_In_Reporting_Plugins > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MPOM-32: - Attachment: MPOM-32-1.xml > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > Attachments: MPOM-32-1.xml, MPOM-32-2.xml > > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MPOM-32: - Attachment: MPOM-32-2.xml > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > Attachments: MPOM-32-1.xml, MPOM-32-2.xml > > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225718#comment-13225718 ] Sebb commented on MPOM-32: -- See attached sample POMs. Both attempt to change the list of generated reports; neither has any effect. > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > Attachments: MPOM-32-1.xml, MPOM-32-2.xml > > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-241) false does not work
SebbASF created MPIR-241: Summary: false does not work Key: MPIR-241 URL: https://jira.codehaus.org/browse/MPIR-241 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Reporter: SebbASF Priority: Blocker The plugin is supposed to support the tag [1]. However, it does not work. This makes it impossible to configure reports when using the Apache Parent pom 10. See also https://issues.apache.org/jira/browse/MPOM-32 [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_inherited_Tag_In_Reporting_Plugins -- 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
