[jira] Created: (MSHARED-190) More flexible manifest classpath
More flexible manifest classpath
Key: MSHARED-190
URL: http://jira.codehaus.org/browse/MSHARED-190
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-archiver
Affects Versions: maven-archiver-2.4.1
Reporter: Yves Langisch
Attachments: third_party_classpathPrefix.patch
I'd like to see a more flexible way to adjust the classpath entries in the
manifest file. For example with the ear-plugin I'm able to put third party
libraries to a different folder (e.g. lib/) than project module artifacts (e.g.
root folder). For ejb-modules I need to be able to specify classpath entries
for both folders (e.g. lib/log4j.jar and a.b.c.project-common.jar). As you can
only specify a general prefix this layout is currently not handled.
Attached you find a patch against the trunk which introduces a new additional
configuration option {{classpathPrefixThirdParty}}. Dependencies that have a
different groupId from the project itself are prefixed with that option.
--
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-3328) Allow multiple profile activation properties.
[
http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260532#action_260532
]
Pulkit Singhal commented on MNG-3328:
-
Why is an enhancement with this many votes being ignored? What is the reason
that this is not being considered or scheduled in the pipeline?
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: http://jira.codehaus.org/browse/MNG-3328
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: 3.x / Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
> {code:xml}
>
>
> some-value
> another-value
>
>
> {code}
> This would provide more flexibility in profile activation.
--
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: (MENFORCER-28) Create a rule, which fail when the upper most parent (corporate pom) is not the latest version
[
http://jira.codehaus.org/browse/MENFORCER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260536#action_260536
]
Marc Rohlfs commented on MENFORCER-28:
--
We're (also) using a corporate Super POM. To prevent our projects to experience
unexpected side effects (or even broken builds) when changing that Super POM,
we're preventing them to inherit from snapshot versions.
A standard rule to achieve that would be nice, currently we use a Beanshell
evaluation:
{code:xml}
/* The rule shouldn't fail for the Super POM build itself. */
"${project.parent}".equals("${"+"project.parent"+"}")
@or
(
"${project.parent.artifactId}".equals("corporate-super-pom")
@and
!"${project.parent.version}".contains("SNAPSHOT")
)
Don't use a SNAPSHOT version of the corporate super POM!
{code}
> Create a rule, which fail when the upper most parent (corporate pom) is not
> the latest version
> --
>
> Key: MENFORCER-28
> URL: http://jira.codehaus.org/browse/MENFORCER-28
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Nick Stolwijk
>Assignee: Brian Fox
>Priority: Minor
>
> Basic functionality:
> - Should fail if the current project is a SNAPSHOT and there is a newer
> version of the top most (the corporate pom) artifact. (Don't fail on
> released versions)
> - Very optional (I can't find a good use case):Option to fail on
> released versions also.
> - Option to not fail on major changes. (so update from 0.9.1 -> 0.9.2
> fail, from 0.9.0 to 1.0.0 don't 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: (MECLIPSE-684) Plugin insists on adding references to Javadoc, even when not asked
Plugin insists on adding references to Javadoc, even when not asked --- Key: MECLIPSE-684 URL: http://jira.codehaus.org/browse/MECLIPSE-684 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Environment: Maven 2.2.1 Reporter: John Doe The .classpath file generated by this command mvn eclipse:eclipse -DdownloadSources=true always contains references to javadoc packages, even though I didn't ask for it! Specifying "-DdownloadJavadocs=false" make no difference whatsoever. -- 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: (ARCHETYPE-191) Ability to filter filenames (rename files) during project generation
[ http://jira.codehaus.org/browse/ARCHETYPE-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260559#action_260559 ] Earl Baugh edited comment on ARCHETYPE-191 at 3/17/11 10:42 AM: I'm seeing that this behavior doesn't properly work when trying to rename the "top" level directory under the archetype-resources directory, at least for multi module projects. It seems that the replacement strategy gets confused... This first line, it shows that "test" (the variable value has been replaced) but velocity doesn't know how to reference it or the like. The line in the file was . The dir in the archtype-resources is named __rootArtifactId__, so that's right, and from the below it replaced the value correctly. [ERROR] ResourceManager : unable to find resource 'archetype-resources/test/pom.xml' in any resource loader. [ERROR] org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error merging velocity templates: Unable to find resource 'archetype-resources/test/pom.xml' Should I open a new issue on this? was (Author: ebaugh): I'm seeing that this behavior doesn't properly work when trying to rename the "top" level directory under the archetype-resources directory, at least for multi module projects. It seems that the replacement strategy gets confused... This first line, it shows that "test" (the variable value has been replaced) but velocity doesn't know how to reference it or the like. The line in the file was . The dir in the archtype-resources is named __rootArtifactId__, so that's right, and from the below it replaced the value correctly. [ERROR] ResourceManager : unable to find resource 'archetype-resources/test/pom.xml' in any resource loader. [ERROR] org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error merging velocity templates: Unable to find resource 'archetype-resources/test/pom.xml' Should I open a new issue on this? > Ability to filter filenames (rename files) during project generation > > > Key: ARCHETYPE-191 > URL: http://jira.codehaus.org/browse/ARCHETYPE-191 > Project: Maven Archetype > Issue Type: New Feature > Components: Generator >Affects Versions: 2.0-alpha-3 >Reporter: Wendy Smoak > Fix For: 2.0-alpha-4 > > Attachments: mytest-1.0.1.jar, mytest-1.0.1.pom, > ReplaceAnyContextPropertyEnhancement-v2.patch, > ReplaceAnyContextPropertyEnhancement.patch, ReplaceFileNameToken_RegExp.patch > > > When generating a new project from an archetype, I need to filter not only > values within files, but the names of the files themselves. > For example, in .NET projects, the project files (.sln, .csproj) match the > name of the solution or project rather than having a fixed name like Maven's > pom.xml does. > Another user raised a similar issue on the mailing list, the ability to > filter in the name of Java source code files. > See: http://www.nabble.com/Archetype%2C-define-file-name-ts18430983.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-191) Ability to filter filenames (rename files) during project generation
[ http://jira.codehaus.org/browse/ARCHETYPE-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260559#action_260559 ] Earl Baugh commented on ARCHETYPE-191: -- I'm seeing that this behavior doesn't properly work when trying to rename the "top" level directory under the archetype-resources directory, at least for multi module projects. It seems that the replacement strategy gets confused... This first line, it shows that "test" (the variable value has been replaced) but velocity doesn't know how to reference it or the like. The line in the file was . The dir in the archtype-resources is named __rootArtifactId__, so that's right, and from the below it replaced the value correctly. [ERROR] ResourceManager : unable to find resource 'archetype-resources/test/pom.xml' in any resource loader. [ERROR] org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error merging velocity templates: Unable to find resource 'archetype-resources/test/pom.xml' Should I open a new issue on this? > Ability to filter filenames (rename files) during project generation > > > Key: ARCHETYPE-191 > URL: http://jira.codehaus.org/browse/ARCHETYPE-191 > Project: Maven Archetype > Issue Type: New Feature > Components: Generator >Affects Versions: 2.0-alpha-3 >Reporter: Wendy Smoak > Fix For: 2.0-alpha-4 > > Attachments: mytest-1.0.1.jar, mytest-1.0.1.pom, > ReplaceAnyContextPropertyEnhancement-v2.patch, > ReplaceAnyContextPropertyEnhancement.patch, ReplaceFileNameToken_RegExp.patch > > > When generating a new project from an archetype, I need to filter not only > values within files, but the names of the files themselves. > For example, in .NET projects, the project files (.sln, .csproj) match the > name of the solution or project rather than having a fixed name like Maven's > pom.xml does. > Another user raised a similar issue on the mailing list, the ability to > filter in the name of Java source code files. > See: http://www.nabble.com/Archetype%2C-define-file-name-ts18430983.html -- 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: (ARCHETYPE-191) Ability to filter filenames (rename files) during project generation
[ http://jira.codehaus.org/browse/ARCHETYPE-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260559#action_260559 ] Earl Baugh edited comment on ARCHETYPE-191 at 3/17/11 10:42 AM: I'm seeing that this behavior doesn't properly work when trying to rename the "top" level directory under the archetype-resources directory, at least for multi module projects. It seems that the replacement strategy gets confused... This first line, it shows that "test" (the variable value has been replaced) but velocity doesn't know how to reference it or the like. The line in the file was . The dir in the archtype-resources is named __rootArtifactId__, so that's right, and from the below it replaced the value correctly. [ERROR] ResourceManager : unable to find resource 'archetype-resources/test/pom.xml' in any resource loader. [ERROR] org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error merging velocity templates: Unable to find resource 'archetype-resources/test/pom.xml' Should I open a new issue on this? was (Author: ebaugh): I'm seeing that this behavior doesn't properly work when trying to rename the "top" level directory under the archetype-resources directory, at least for multi module projects. It seems that the replacement strategy gets confused... This first line, it shows that "test" (the variable value has been replaced) but velocity doesn't know how to reference it or the like. The line in the file was . The dir in the archtype-resources is named __rootArtifactId__, so that's right, and from the below it replaced the value correctly. [ERROR] ResourceManager : unable to find resource 'archetype-resources/test/pom.xml' in any resource loader. [ERROR] org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error merging velocity templates: Unable to find resource 'archetype-resources/test/pom.xml' Should I open a new issue on this? > Ability to filter filenames (rename files) during project generation > > > Key: ARCHETYPE-191 > URL: http://jira.codehaus.org/browse/ARCHETYPE-191 > Project: Maven Archetype > Issue Type: New Feature > Components: Generator >Affects Versions: 2.0-alpha-3 >Reporter: Wendy Smoak > Fix For: 2.0-alpha-4 > > Attachments: mytest-1.0.1.jar, mytest-1.0.1.pom, > ReplaceAnyContextPropertyEnhancement-v2.patch, > ReplaceAnyContextPropertyEnhancement.patch, ReplaceFileNameToken_RegExp.patch > > > When generating a new project from an archetype, I need to filter not only > values within files, but the names of the files themselves. > For example, in .NET projects, the project files (.sln, .csproj) match the > name of the solution or project rather than having a fixed name like Maven's > pom.xml does. > Another user raised a similar issue on the mailing list, the ability to > filter in the name of Java source code files. > See: http://www.nabble.com/Archetype%2C-define-file-name-ts18430983.html -- 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: (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
[
http://jira.codehaus.org/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260564#action_260564
]
Ramon Buckland commented on MCOMPILER-97:
-
I needed to do something similar.
I have a Unit Test which actually runs my Processor by calling the JavaCompiler.
{{{
@Test
public void fullComprehensiveTest() {
...
// Get an instance of java compiler
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
// Get a new instance of the standard file manager implementation
StandardJavaFileManager fileManager =
compiler.getStandardFileManager(null, null, null);
List options = new ArrayList();
options.add("-d");
File outputDir = new File("target", "processor-test");
outputDir.mkdirs();
options.add(outputDir.getAbsolutePath());
options.add("-s");
options.add(outputDir.getAbsolutePath());
// Get the list of java file objects
SrcFilesTestClass srcFiles = new SrcFilesTestClass();
System.out.println(">> testing: files to run annotation test on (only
some have annotations): ");
for (String f : srcFiles.srcFiles()) {
System.out.println(f);
}
Iterable compilationUnits1 =
fileManager.getJavaFileObjects(srcFiles.srcFiles());
StringWriter output = new StringWriter();
CompilationTask task = compiler.getTask(output, fileManager, null,
options, null, compilationUnits1);
// Create a list to hold annotation processors
LinkedList processors = new
LinkedList();
// Add an annotation processor to the list
processors.add(new VannitationOneToOneProcessor());
processors.add(new VannitationManyToOneProcessor());
// Set the annotation processor to the compiler task
task.setProcessors(processors);
// Perform the compilation task.
// the compiler will return false for us because the files we are
// creating won't compile as
// we don't have the required fields.
task.call();
// now some tests .. we will just validate that
...
}
}}}
So .. to ensure that the processor does not run in my package from maven, and
that I control it (maven via surefire runs it), I -proc:none on the compile
test also.
{{{
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
default-compile
-proc:none
1.6
1.6
default-testCompile
-proc:none
1.6
1.6
}}}
> META-INF/services/javax.annotation.processing.Processor copied before
> compilation and causes error
> --
>
> Key: MCOMPILER-97
> URL: http://jira.codehaus.org/browse/MCOMPILER-97
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
>Reporter: Jesse Glick
> Attachments: maven-6647998-test.zip
>
>
> It is tricky to compile a Maven module which defines a (269-compliant)
> annotation processor. If you write the code for the processor in
> src/main/java and register it in src/main/resources,
> META-INF/services/javax.annotation.processing.Processor is copied to
> target/classes first, and then javac is run. But javac is given
> target/classes in -classpath, so it tries to load the processor, which of
> course has not been compiled yet - a chicken-and-egg problem.
> The most straightforward workaround is to specify
> -proc:none in your POM. This will only
> work, however, if the module does not use any annotation processors defined
> in dependencies. If it does, there may be some other trick involving
> -processorpath and Maven variable substitution to insert the dependency
> classpath.
> Switching the order of resources:resources and compiler:compile would help -
> at least a clean build would work - though it could still cause problems in
> incremental builds. Better would be for the compiler plugin to pass
> -processorpath based on the dependency classpath (i.e. -classpath minus
> target/classes) when using -source 1.6 or higher.
--
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: (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
[
http://jira.codehaus.org/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260564#action_260564
]
Ramon Buckland edited comment on MCOMPILER-97 at 3/17/11 11:32 AM:
---
I needed to do something similar.
I have a Unit Test which actually runs my Processor by calling the JavaCompiler.
{code}
@Test
public void fullComprehensiveTest() {
...
// Get an instance of java compiler
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
// Get a new instance of the standard file manager implementation
StandardJavaFileManager fileManager =
compiler.getStandardFileManager(null, null, null);
List options = new ArrayList();
options.add("-d");
File outputDir = new File("target", "processor-test");
outputDir.mkdirs();
options.add(outputDir.getAbsolutePath());
options.add("-s");
options.add(outputDir.getAbsolutePath());
// Get the list of java file objects
SrcFilesTestClass srcFiles = new SrcFilesTestClass();
System.out.println(">> testing: files to run annotation test on (only
some have annotations): ");
for (String f : srcFiles.srcFiles()) {
System.out.println(f);
}
Iterable compilationUnits1 =
fileManager.getJavaFileObjects(srcFiles.srcFiles());
StringWriter output = new StringWriter();
CompilationTask task = compiler.getTask(output, fileManager, null,
options, null, compilationUnits1);
// Create a list to hold annotation processors
LinkedList processors = new
LinkedList();
// Add an annotation processor to the list
processors.add(new VannitationOneToOneProcessor());
processors.add(new VannitationManyToOneProcessor());
// Set the annotation processor to the compiler task
task.setProcessors(processors);
// Perform the compilation task.
// the compiler will return false for us because the files we are
// creating won't compile as
// we don't have the required fields.
task.call();
// now some tests .. we will just validate that
...
}
{code}
So .. to ensure that the processor does not run in my package from maven, and
that I control it (maven via surefire runs it), I -proc:none on the compile
test also.
{code:xml}
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
default-compile
-proc:none
1.6
1.6
default-testCompile
-proc:none
1.6
1.6
{code}
was (Author: rbuckland):
I needed to do something similar.
I have a Unit Test which actually runs my Processor by calling the JavaCompiler.
{{{
@Test
public void fullComprehensiveTest() {
...
// Get an instance of java compiler
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
// Get a new instance of the standard file manager implementation
StandardJavaFileManager fileManager =
compiler.getStandardFileManager(null, null, null);
List options = new ArrayList();
options.add("-d");
File outputDir = new File("target", "processor-test");
outputDir.mkdirs();
options.add(outputDir.getAbsolutePath());
options.add("-s");
options.add(outputDir.getAbsolutePath());
// Get the list of java file objects
SrcFilesTestClass srcFiles = new SrcFilesTestClass();
System.out.println(">> testing: files to run annotation test on (only
some have annotations): ");
for (String f : srcFiles.srcFiles()) {
System.out.println(f);
}
Iterable compilationUnits1 =
fileManager.getJavaFileObjects(srcFiles.srcFiles());
StringWriter output = new StringWriter();
CompilationTask task = compiler.getTask(output, fileManager, null,
options, null, compilationUnits1);
// Create a list to hold annotation processors
LinkedList processors = new
LinkedList();
// Add an annotation processor to the list
processors.add(new VannitationOneToOneProcessor());
processors.add(new VannitationManyToOneProcessor());
// Set the annotation processor to the compiler task
task.setProcessors(processors);
// Perform the compilation task.
// the compiler will return false for us because the files we are
// creating won't compile as
// we don't have the required fields.
task.call();
// now some tests .. we will just validate that
...
}
}}}
So .. to ensure that the processor doe
[jira] Created: (ARCHETYPE-368) Enforced parent of modules gets replaced by project parent
Enforced parent of modules gets replaced by project parent
--
Key: ARCHETYPE-368
URL: http://jira.codehaus.org/browse/ARCHETYPE-368
Project: Maven Archetype
Issue Type: Bug
Components: Creator
Affects Versions: 2.0
Environment: Maven 3.0.2
Reporter: Georges-Etienne Legendre
We want to have archetype that creates a project with modules. Child modules
should not inherit from the project POM. This is the model presented in the
Maven Guide: section 3.6.2.2
http://sonatype.com/books/mvnref-book/reference/pom-relationships-sect-multi-vs-inherit.html
Example:
{code}
test-project/
pom.xml: parent is com.test.pom:my-meta-parent
test-module1/
pom.xml: parent should be com.test.pom:my-parent-1
test-module2/
pom.xml: parent should be com.test.pom:my-parent-2
test-module3/
pom.xml: parent should be test-project
{code}
In the archetype, I have:
{code}
project-archetype/
src/main/resources/
__rootArtifactId__-module1/
pom.xml:
4.0.0
com.test.pom
my-parent-1
RELEASE
...
__rootArtifactId__-module2/
pom.xml:
4.0.0
com.test.pom
my-parent-2
RELEASE
...
__rootArtifactId__-module3/
pom.xml:
4.0.0
${groupId}
${rootArtifactId}
${version}
...
{code}
When the archetype is used to create a project, all of module get
replaced by the new project Pom.xml... They all end up with:
{code}
com.test.project
test-project
0.0.1-SNAPSHOT
{code}
Is there a way to fix this? Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-714) maven-surefire-report-plugin version 2.8 generates the error org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown
maven-surefire-report-plugin version 2.8 generates the error
org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown
--
Key: SUREFIRE-714
URL: http://jira.codehaus.org/browse/SUREFIRE-714
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.8
Environment: Linux CentOS, Windows XP, Java 1.6.0_19.
Reporter: Hansen Candrawinata
Priority: Minor
Running 'mvn site:site' with maven-surefire-report-plugin version 2.8 generates
the following exception in our project:
{quote}
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO]
org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown(Ljava/lang/String;[Ljava/lang/Object;Lorg/apache/maven/doxia/sink/SinkEventAttributes;)V
[INFO]
[INFO] Trace
java.lang.AbstractMethodError:
org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown(Ljava/lang/String;[Ljava/lang/Object;Lorg/apache/maven/doxia/sink/SinkEventAttributes;)V
at
org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:76)
at
org.apache.maven.plugins.surefire.report.SurefireReportMojo.executeReport(SurefireReportMojo.java:200)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:144)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
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:597)
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)
{quote}
Here is the relevant section of our pom file:
{quote}
org.apache.maven.plugins
maven-surefire-report-plugin
2.8/version>
-Xmx512m
{quote}
This does not happen with version 2.7.2, so we have temporarily switched back
to version 2.7.2 for now.
Does anyone know what is causing the problem? The release notes for version
2.8 does not give any hints.
Thanks,
Hansen
--
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-714) maven-surefire-report-plugin version 2.8 generates the error org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown
[
http://jira.codehaus.org/browse/SUREFIRE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260641#action_260641
]
Kristian Rosenvold edited comment on SUREFIRE-714 at 3/18/11 1:00 AM:
--
As can be seen from
http://maven.apache.org/plugins/maven-surefire-report-plugin/
"Note: As of version 2.8 this plugin requires Maven Site Plugin 2.1 or higher
to work properly. Version 2.7.2 and older are still compatible with newer
surefire versions, so mixing is possible."
For all practical purposes you can stay on 2.7.2 as long as you want, since the
xml format used for interchange will stay backward compatible (newer surefire
versions can use older surefire-report-plugins). You will, of course, be
missing out on bugfixes in reporting if you choose to not upgrade
reporting-plugin/site.
It's only indirectly expressed in the release notes through SUREFIRE-566, and
I'll take note to be clearer on that next time. Thanks.
was (Author: krosenvold):
As can be seen from
http://maven.apache.org/plugins/maven-surefire-report-plugin/
Note: As of version 2.8 this plugin requires Maven Site Plugin 2.1 or higher to
work properly. Version 2.7.2 and older are still compatible with newer surefire
versions, so mixing is possible.
For all practical purposes you can stay on 2.7.2 as long as you want, since the
xml format used for interchange will stay backward compatible (newer surefire
versions can use older surefire-report-plugins). You will, of course, be
missing out on bugfixes if you choose to not upgrade site.
It's only indirectly expressed in the release notes through SUREFIRE-566, and
I'll take note to be clearer on that next time. Thanks.
> maven-surefire-report-plugin version 2.8 generates the error
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown
> --
>
> Key: SUREFIRE-714
> URL: http://jira.codehaus.org/browse/SUREFIRE-714
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.8
> Environment: Linux CentOS, Windows XP, Java 1.6.0_19.
>Reporter: Hansen Candrawinata
>Assignee: Kristian Rosenvold
>Priority: Minor
>
> Running 'mvn site:site' with maven-surefire-report-plugin version 2.8
> generates the following exception in our project:
> {quote}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown(Ljava/lang/String;[Ljava/lang/Object;Lorg/apache/maven/doxia/sink/SinkEventAttributes;)V
> [INFO]
>
> [INFO] Trace
> java.lang.AbstractMethodError:
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown(Ljava/lang/String;[Ljava/lang/Object;Lorg/apache/maven/doxia/sink/SinkEventAttributes;)V
> at
> org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:76)
> at
> org.apache.maven.plugins.surefire.report.SurefireReportMojo.executeReport(SurefireReportMojo.java:200)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:144)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle
[jira] Closed: (SUREFIRE-714) maven-surefire-report-plugin version 2.8 generates the error org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown
[
http://jira.codehaus.org/browse/SUREFIRE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-714.
---
Resolution: Not A Bug
Assignee: Kristian Rosenvold
As can be seen from
http://maven.apache.org/plugins/maven-surefire-report-plugin/
Note: As of version 2.8 this plugin requires Maven Site Plugin 2.1 or higher to
work properly. Version 2.7.2 and older are still compatible with newer surefire
versions, so mixing is possible.
For all practical purposes you can stay on 2.7.2 as long as you want, since the
xml format used for interchange will stay backward compatible (newer surefire
versions can use older surefire-report-plugins). You will, of course, be
missing out on bugfixes if you choose to not upgrade site.
It's only indirectly expressed in the release notes through SUREFIRE-566, and
I'll take note to be clearer on that next time. Thanks.
> maven-surefire-report-plugin version 2.8 generates the error
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown
> --
>
> Key: SUREFIRE-714
> URL: http://jira.codehaus.org/browse/SUREFIRE-714
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.8
> Environment: Linux CentOS, Windows XP, Java 1.6.0_19.
>Reporter: Hansen Candrawinata
>Assignee: Kristian Rosenvold
>Priority: Minor
>
> Running 'mvn site:site' with maven-surefire-report-plugin version 2.8
> generates the following exception in our project:
> {quote}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown(Ljava/lang/String;[Ljava/lang/Object;Lorg/apache/maven/doxia/sink/SinkEventAttributes;)V
> [INFO]
>
> [INFO] Trace
> java.lang.AbstractMethodError:
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.unknown(Ljava/lang/String;[Ljava/lang/Object;Lorg/apache/maven/doxia/sink/SinkEventAttributes;)V
> at
> org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:76)
> at
> org.apache.maven.plugins.surefire.report.SurefireReportMojo.executeReport(SurefireReportMojo.java:200)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:144)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> 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:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.L
