[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027607#comment-16027607 ] Robert Scholte commented on MJAR-193: - I think the proper way is to have some kind of extensionpoint in the maven-jar-plugin where you can add MANIFEST-logic. One of the fundamental rules is that plugins should not be aware of each other and I think this can be solved within the maven-jar-plugin. > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027606#comment-16027606 ] Alex O'Ree commented on MPDF-81: if my patch for 555 is merged, then all that's needed for the maven pdf plugin is to revise the pom versions > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (DOXIA-555) Footer overrides for FO/PDF outputs
[ https://issues.apache.org/jira/browse/DOXIA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated DOXIA-555: - Attachment: DOXIA-555.patch > Footer overrides for FO/PDF outputs > --- > > Key: DOXIA-555 > URL: https://issues.apache.org/jira/browse/DOXIA-555 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - FO >Reporter: Alex O'Ree > Attachments: DOXIA-555.patch > > > Related https://issues.apache.org/jira/browse/MPDF-81 > I have a use case where I cannot have the copyright symbol on the bottom of > generated PDF documents. Currently, it looks like the footer is hard coded > and cannot be customized. > http://svn.apache.org/viewvc/maven/doxia/doxia/tags/doxia-1.7/doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java?view=markup#l762 > ideally, this should be configurable either properties or better yet, the pdf > descriptor document (maven-pdf-plugin). This would require a change in the > schema used for the pdf descriptor > http://maven.apache.org/xsd/document-1.0.1.xsd -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-555) Footer overrides for FO/PDF outputs
[ https://issues.apache.org/jira/browse/DOXIA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027603#comment-16027603 ] Alex O'Ree commented on DOXIA-555: -- sure thing, i've actually got a functioning patch which i'll attach shortly but here's the quick summary in: doxia\doxia-modules\doxia-module-fo\src\main\java\org\apache\maven\doxia\module\fo\FoAggregateSink.java - add/change the constructor to take a second parameter which is a reference to org.apache.maven.doxia.docrenderer.DocumentRendererContext - change the getFooter() code to check for the context for an override value, if present, return that value instead of the canned version in: doxia-sitetools\doxia-doc-renderer\src\main\java\org\apache\maven\doxia\docrenderer\pdf\fo\FoPdfRenderer.java - change the call from FoAggregateSink sink = new FoAggregateSink( writer ); to include the DocumentRendererContext finally, some pom changes to override some of the versions. I had a lot of difficultly getting the dependency structure just right in order to test this but I did get it eventually finally, in the maven pdf plugin, there's some code to gather some additional settings and add them to the DocumentRendererContext which enables the override. Using this approach, no changes are needed for the document xsd. It's probably not the best solution but it seems to be the easier in the short term. > Footer overrides for FO/PDF outputs > --- > > Key: DOXIA-555 > URL: https://issues.apache.org/jira/browse/DOXIA-555 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - FO >Reporter: Alex O'Ree > > Related https://issues.apache.org/jira/browse/MPDF-81 > I have a use case where I cannot have the copyright symbol on the bottom of > generated PDF documents. Currently, it looks like the footer is hard coded > and cannot be customized. > http://svn.apache.org/viewvc/maven/doxia/doxia/tags/doxia-1.7/doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java?view=markup#l762 > ideally, this should be configurable either properties or better yet, the pdf > descriptor document (maven-pdf-plugin). This would require a change in the > schema used for the pdf descriptor > http://maven.apache.org/xsd/document-1.0.1.xsd -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MCHECKSTYLE-338) Add support for 'omitIgnoredModules'
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MCHECKSTYLE-338. -- Resolution: Fixed Assignee: Guillaume Boué Fix Version/s: 3.0.0 > Add support for 'omitIgnoredModules' > > > Key: MCHECKSTYLE-338 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-338 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: checkstyle:check >Affects Versions: 2.17 > Environment: Windows 7, 64 bit >Reporter: richard >Assignee: Guillaume Boué > Fix For: 3.0.0 > > > Checkstyle has an option in it's ant process that allows users to avoid > executing modules that have a severity set to ignore. It is called > `omitIgnoredModules`. It has been in checkstyle already for atleast 2 years. > See: > https://github.com/checkstyle/checkstyle/blob/2f3f4b76f04f0b5071abcaed54648a49a0db3160/src/main/java/com/puppycrawl/tools/checkstyle/ant/CheckstyleAntTask.java#L118 > https://github.com/checkstyle/checkstyle/blob/2f3f4b76f04f0b5071abcaed54648a49a0db3160/src/main/java/com/puppycrawl/tools/checkstyle/ant/CheckstyleAntTask.java#L424-L428 > We are in the process of adding this option to our CLI > (https://github.com/checkstyle/checkstyle/issues/3566) and would like to see > maven-checkstyle-plugin support this feature so users can customize it. > A simple tag for this option like: > `false` would be enough. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MCHECKSTYLE-337) checkstyle:check only supports xml output format, but the docs say it supports plain as well
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027579#comment-16027579
]
Guillaume Boué commented on MCHECKSTYLE-337:
I'm not sure why the first option would break support for {{skipExec}}. But I
don't think the {{plain}} output format can be supported as-is with [Checkstyle
definition of
"plain"|http://checkstyle.sourceforge.net/cmdline.html#Command_line_usage]...
The log messages produced by {{DefaultLogger}} does not include the fully
qualified name of the check's class (only the simple name), and so it wouldn't
work in combination with {{violationIgnore}}. We could have our own formatter
for the messages, but then using {{skipExec}} on a result produced by
Checkstyle could possibly not be interpreted correctly.
> checkstyle:check only supports xml output format, but the docs say it
> supports plain as well
>
>
> Key: MCHECKSTYLE-337
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-337
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: Stig Rohde Døssing
>Priority: Minor
>
> The documentation for the check goal at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#outputFileFormat
> mentions "plain" as a valid option for file output. This is not true, the
> mojo only supports XML.
> I'd prefer added support for plain output, but the docs should be fixed if
> that is not possible.
> Taking a look at the code, it looks like the only reason plain isn't
> supported is because the check mojo needs to parse the output file to figure
> out if there were style violations. An option would be counting errors with
> the AuditListener instead, but this would break support for skipExec. An
> alternative would be to output an extra XML result file if the output format
> isn't XML.
> I'd be happy to implement either solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MCHECKSTYLE-338) Add support for 'omitIgnoredModules'
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027578#comment-16027578 ] Hudson commented on MCHECKSTYLE-338: SUCCESS: Integrated in Jenkins build maven-plugins #8969 (See [https://builds.apache.org/job/maven-plugins/8969/]) [MCHECKSTYLE-338] Add support for 'omitIgnoredModules' The boolean parameter 'omitIgnoredModules' controls whether modules in a Checkstyle configuration with a severity set to 'ignore' should be omitted or still executed during Checkstyle invocation. This defaults to false to be consistent with the previous behavior of the plugin. IT is done by writing a custom check that does nothing except always logging as an error the name of the file it was invoked on. This is used to verify whether the check was invoked or not depending on the value of 'omitIgnoredModules'. (gboue: [http://svn.apache.org/viewvc/?view=rev=1796441]) * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338 * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/checkstyle.xml * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/pom.xml * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java/org * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java/org/apache * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java/org/apache/maven * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java/org/apache/maven/plugins * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java/org/apache/maven/plugins/checkstyle * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/empty-logging-check/src/main/java/org/apache/maven/plugins/checkstyle/EmptyLoggingCheck.java * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/invoker.properties * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/pom.xml * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java/org * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java/org/apache * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java/org/apache/maven * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java/org/apache/maven/plugins * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java/org/apache/maven/plugins/checkstyle * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-false/src/main/java/org/apache/maven/plugins/checkstyle/TestFalse.java * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/pom.xml * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java/org * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java/org/apache * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java/org/apache/maven * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java/org/apache/maven/plugins * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java/org/apache/maven/plugins/checkstyle * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/omitignoredmodules-true/src/main/java/org/apache/maven/plugins/checkstyle/TestTrue.java * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/pom.xml * (add) maven-checkstyle-plugin/src/it/MCHECKSTYLE-338/verify.groovy * (edit) maven-checkstyle-plugin/src/main/java/org/apache/maven/plugins/checkstyle/AbstractCheckstyleReport.java * (edit) maven-checkstyle-plugin/src/main/java/org/apache/maven/plugins/checkstyle/CheckstyleViolationCheckMojo.java * (edit)
[jira] [Commented] (MCHECKSTYLE-338) Add support for 'omitIgnoredModules'
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027573#comment-16027573 ] Guillaume Boué commented on MCHECKSTYLE-338: Fixed in [r1796441|http://svn.apache.org/viewvc?rev=1796441=rev]. > Add support for 'omitIgnoredModules' > > > Key: MCHECKSTYLE-338 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-338 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: checkstyle:check >Affects Versions: 2.17 > Environment: Windows 7, 64 bit >Reporter: richard > > Checkstyle has an option in it's ant process that allows users to avoid > executing modules that have a severity set to ignore. It is called > `omitIgnoredModules`. It has been in checkstyle already for atleast 2 years. > See: > https://github.com/checkstyle/checkstyle/blob/2f3f4b76f04f0b5071abcaed54648a49a0db3160/src/main/java/com/puppycrawl/tools/checkstyle/ant/CheckstyleAntTask.java#L118 > https://github.com/checkstyle/checkstyle/blob/2f3f4b76f04f0b5071abcaed54648a49a0db3160/src/main/java/com/puppycrawl/tools/checkstyle/ant/CheckstyleAntTask.java#L424-L428 > We are in the process of adding this option to our CLI > (https://github.com/checkstyle/checkstyle/issues/3566) and would like to see > maven-checkstyle-plugin support this feature so users can customize it. > A simple tag for this option like: > `false` would be enough. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MPMD-237) Unnecessary modifiers on variables
[ https://issues.apache.org/jira/browse/MPMD-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027537#comment-16027537 ] Andreas Dangel commented on MPMD-237: - [~KCR] Since this sounds like a PMD issue, please report it under https://github.com/pmd/pmd/issues - Thanks! > Unnecessary modifiers on variables > -- > > Key: MPMD-237 > URL: https://issues.apache.org/jira/browse/MPMD-237 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.8 >Reporter: Kiranchandreddy Janga > > Why we are seeing UnnecessaryModifier rule set on enum/constants.? > Facing new issues with this check. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MPMD-239) Add documentation about upgrading PMD version at runtime
Andreas Dangel created MPMD-239:
---
Summary: Add documentation about upgrading PMD version at runtime
Key: MPMD-239
URL: https://issues.apache.org/jira/browse/MPMD-239
Project: Maven PMD Plugin
Issue Type: Improvement
Components: CPD, PMD
Reporter: Andreas Dangel
Fix For: 3.9
The documentation should be similar to
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
Example configuration, to use m-pmd-p 3.8 + PMD 5.7.0:
{noformat}
org.apache.maven.plugins
maven-pmd-plugin
3.8
net.sourceforge.pmd
pmd-core
5.7.0
net.sourceforge.pmd
pmd-java
5.7.0
{noformat}
See also https://github.com/pmd/pmd/issues/402
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MPMD-238) Execution default-cli of goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class was missing while executing org.apache.maven.plugins:maven-pmd-pl
[
https://issues.apache.org/jira/browse/MPMD-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027536#comment-16027536
]
Andreas Dangel commented on MPMD-238:
-
Hi Martijn,
The error sounds strange: The missing class is/should be included in
file:/Users/karianna/.m2/repository/org/ow2/asm/asm/5.0.4/asm-5.0.4.jar
Could you please try the following:
* Disable
[typeresolution|https://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#typeResolution]:
this is by default enabled with version 3.8, and this would be the part of the
code, that needs this dependency:
{noformat}
org.apache.maven.plugins
maven-pmd-plugin
3.8
false
{noformat}
* Delete the file
{{/Users/karianna/.m2/repository/org/ow2/asm/asm/5.0.4/asm-5.0.4.jar}} in your
local repository - maybe you have a corrupted version? You could also try to
delete your whole local repo (/Users/karianna/.m2/repository/), but it might
take a while, until you have downloaded all the dependencies again.
Also, could you please post the {{pom.xml}} of the failing project? Maybe there
are some conflicting dependencies...
Regards,
Andreas
> Execution default-cli of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
> org/objectweb/asm/ClassVisitor
> --
>
> Key: MPMD-238
> URL: https://issues.apache.org/jira/browse/MPMD-238
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.8
> Environment: Mac OS X 10.12.4, Oracle JDK 1.8.0_131, Apache Maven
> 3.5.0
>Reporter: Martijn Verburg
>Priority: Blocker
> Labels: maven
>
> When running `mvn pmd:pmd` on a project the command fails with:
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd (default-cli) on
> project jclarity-util: Execution default-cli of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
> org/objectweb/asm/ClassVisitor
> -
> realm =plugin>org.apache.maven.plugins:maven-pmd-plugin:3.8
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/Users/karianna/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.8/maven-pmd-plugin-3.8.jar
> urls[1] =
> file:/Users/karianna/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> urls[2] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> urls[3] =
> file:/Users/karianna/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> urls[4] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.4/doxia-sink-api-1.4.jar
> urls[5] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.4/doxia-logging-api-1.4.jar
> urls[6] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.4/doxia-decoration-model-1.4.jar
> urls[7] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar
> urls[8] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.4/doxia-site-renderer-1.4.jar
> urls[9] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-core/1.4/doxia-core-1.4.jar
> urls[10] =
> file:/Users/karianna/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar
> urls[11] =
> file:/Users/karianna/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar
> urls[12] =
> file:/Users/karianna/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> urls[13] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.4/doxia-module-xhtml-1.4.jar
> urls[14] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.4/doxia-module-fml-1.4.jar
> urls[15] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
> urls[16] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar
> urls[17] =
> file:/Users/karianna/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar
> urls[18] = file:/Users/karianna/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
> urls[19] =
>
[jira] [Commented] (DOXIA-555) Footer overrides for FO/PDF outputs
[ https://issues.apache.org/jira/browse/DOXIA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027515#comment-16027515 ] Michael Osipov commented on DOXIA-555: -- Can you briefly describe what needs to be changed with Doxia first? > Footer overrides for FO/PDF outputs > --- > > Key: DOXIA-555 > URL: https://issues.apache.org/jira/browse/DOXIA-555 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - FO >Reporter: Alex O'Ree > > Related https://issues.apache.org/jira/browse/MPDF-81 > I have a use case where I cannot have the copyright symbol on the bottom of > generated PDF documents. Currently, it looks like the footer is hard coded > and cannot be customized. > http://svn.apache.org/viewvc/maven/doxia/doxia/tags/doxia-1.7/doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java?view=markup#l762 > ideally, this should be configurable either properties or better yet, the pdf > descriptor document (maven-pdf-plugin). This would require a change in the > schema used for the pdf descriptor > http://maven.apache.org/xsd/document-1.0.1.xsd -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-528) Archetype:generate from repos besides central does not work
[
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027514#comment-16027514
]
Robert Scholte commented on ARCHETYPE-528:
--
bq. maven central is hardcoded into the plugin
I'm pretty sure that all hardcoded references to Maven Central have been
removed from this plugin. It means that it is falling back to Mavens own
defaults.
bq. the "archetype" repository isn't being used for fetching the catalog but
can be used for fetching artifacts
In case of a mirror I know this is working. This is a case which hasn't been
covered yet.
bq. it complains about the "archetype" repository missing despite it being
defined
Very likely related to the previous bullet.
For me this line is interesting: {{[DEBUG] Searching for remote catalog:
https://repo.maven.apache.org/maven2/archetype-catalog.xml}}. It should have
picked the archetype-repository. So this is a clear message that the
refactoring is not complete yet.
> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results in the following:
> {noformat}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate' with basic
> configurator -->
> [DEBUG] (f) archetypeCatalog = remote
> [DEBUG] (f) basedir = C:\Users\joao.cabrita\projects\bpm
> [DEBUG] (f) filter = org.camunda.bpm.archetype:
> [DEBUG] (f) interactiveMode = true
> [DEBUG] (f) localRepository = id: local
> url: file:///C:/Users/joao.cabrita/.m2/repository/
>layout: default
> snapshots: [enabled => true, update => always]
> releases: [enabled => true, update => always]
> [DEBUG] (f) remoteArtifactRepositories = [ id: central
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> , id: archetype
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> ]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@325f7fa9
> [DEBUG] -- end configuration --
> [INFO] Generating project in Interactive mode
> [DEBUG] Searching for remote catalog:
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> [WARNING] No archetype found in remote catalog. Defaulting to internal catalog
> [INFO] Your filter doesn't match any archetype, so try again with another
> value.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> I've attached my settings.xml file.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (DOXIA-555) Footer overrides for FO/PDF outputs
[ https://issues.apache.org/jira/browse/DOXIA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027512#comment-16027512 ] Alex O'Ree commented on DOXIA-555: -- ping. I'm not sure who maintains Doxia, but in order to support custom header/footers on generated PDF documents, unfortunately it requires changing a number of different repositories both in doxia and for the maven-pdf-plugin (and versions of cut of all affected modules). I'm willing to do the work, but I'd at least like some concurrency from the maintainers that this is a feasible change that can be made. > Footer overrides for FO/PDF outputs > --- > > Key: DOXIA-555 > URL: https://issues.apache.org/jira/browse/DOXIA-555 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - FO >Reporter: Alex O'Ree > > Related https://issues.apache.org/jira/browse/MPDF-81 > I have a use case where I cannot have the copyright symbol on the bottom of > generated PDF documents. Currently, it looks like the footer is hard coded > and cannot be customized. > http://svn.apache.org/viewvc/maven/doxia/doxia/tags/doxia-1.7/doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java?view=markup#l762 > ideally, this should be configurable either properties or better yet, the pdf > descriptor document (maven-pdf-plugin). This would require a change in the > schema used for the pdf descriptor > http://maven.apache.org/xsd/document-1.0.1.xsd -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027459#comment-16027459
]
Tibor Digana commented on SUREFIRE-1372:
[~mpkorstanje]
Can you mention usage of Cucumber in regard of rerun here?
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/rerun-failing-tests.apt.vm
Which versions are safe to use, details, config, expected results from the
tests.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRESOLVER-27: --- Description: Java 9 with Jigsaw modules is coming Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work was: Java 9 is coming, and Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature >Affects Versions: Maven Artifact Resolver 1.1.0 >Reporter: Hervé Boutemy > > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MRESOLVER-26) add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names
[ https://issues.apache.org/jira/browse/MRESOLVER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027454#comment-16027454 ] Hervé Boutemy commented on MRESOLVER-26: proposed patch: http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7 > add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module > names > > > Key: MRESOLVER-26 > URL: https://issues.apache.org/jira/browse/MRESOLVER-26 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Maven Artifact Resolver 1.0.3 >Reporter: Hervé Boutemy > Fix For: Maven Artifact Resolver 1.1.0 > > > as discussed in dev ML: > https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > starting by just defining Automatic Modules Names is a quickstart -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MRESOLVER-26) add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names
[ https://issues.apache.org/jira/browse/MRESOLVER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRESOLVER-26: --- Description: as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E Java 9 with Jigsaw modules is coming Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules starting by just defining Automatic Modules Names is a quickstart was: as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E Java 9 is coming, and Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules starting by just defining Automatic Modules Names is a quickstart > add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module > names > > > Key: MRESOLVER-26 > URL: https://issues.apache.org/jira/browse/MRESOLVER-26 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Maven Artifact Resolver 1.0.3 >Reporter: Hervé Boutemy > Fix For: Maven Artifact Resolver 1.1.0 > > > as discussed in dev ML: > https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > starting by just defining Automatic Modules Names is a quickstart -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027452#comment-16027452
]
matteo rulli edited comment on SUREFIRE-1374 at 5/27/17 3:07 PM:
-
[~tibor17]
Our code is doing nothing with std input/output stream. So I guess it is some
library we are using... Yet, I'm wondering why with previous surefire version
everything worked just fine.
Unfortunately I cannot attach the project since it is a proprietary project of
our customer.
Just to have a starting point for my investigations: could you describe me what
commands BYE_ACK, NOOP and all that are? Who is supposed to generate them and
why they should be corrupted? Version incompatibility of some kind?
Thanks.
was (Author: matteor):
[~tibor17]
Our code is doing nothing with std input stream. So I guess it is some library
we are using... Yet, I'm wondering why with previous surefire version
everything worked just fine.
Unfortunately I cannot attach the project since it is a proprietary project of
our customer.
Just to have a starting point for my investigations: could you describe me what
commands BYE_ACK, NOOP and all that are? Who is supposed to generate them and
why they should be corrupted? Version incompatibility of some kind?
Thanks.
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027452#comment-16027452
]
matteo rulli commented on SUREFIRE-1374:
[~tibor17]
Our code is doing nothing with std input stream. So I guess it is some library
we are using... Yet, I'm wondering why with previous surefire version
everything worked just fine.
Unfortunately I cannot attach the project since it is a proprietary project of
our customer.
Just to have a starting point for my investigations: could you describe me what
commands BYE_ACK, NOOP and all that are? Who is supposed to generate them and
why they should be corrupted? Version incompatibility of some kind?
Thanks.
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0
--
[jira] [Updated] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRESOLVER-27: --- Affects Version/s: (was: Maven Artifact Resolver 1.0.3) Maven Artifact Resolver 1.1.0 > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature >Affects Versions: Maven Artifact Resolver 1.1.0 >Reporter: Hervé Boutemy > > Java 9 is coming, and Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027416#comment-16027416
]
Tibor Digana commented on SUREFIRE-1374:
[~matteor]
These are errors for you as users. We are not sending wrong data to ourselves.
That's the point of these dump files that you have to investigate what your
code and JVM is doing with the stream.
I have committed unit tests encoding and decoding
https://github.com/apache/maven-surefire/commit/1ca8374d2618fa2667bd4a82c9684a30fba619d9
The command BYE_ACK has ordinal 5 and NOOP has 4 in enum.
according to {{java.io.IOException: Command BYE_ACK unexpectedly read Void data
with length 4.}} I wrote these tests in the commit above and the commands do
not interlace.
Download the source of surefire project and debug or print what commands are
coming in and out, means classes {{TestProvidingInputStream}},
{{TestLessInputStreamBuilder}} and {{CommandReader}}.
You can attach your project to Jira and I will try to reproduce the issue.
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR]
[jira] [Updated] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRESOLVER-27: --- Description: Java 9 is coming, and Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work was:could be useful for Maven Artifact Resolver consumers > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature >Affects Versions: Maven Artifact Resolver 1.0.3 >Reporter: Hervé Boutemy > > Java 9 is coming, and Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MRESOLVER-26) add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names
[ https://issues.apache.org/jira/browse/MRESOLVER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRESOLVER-26: --- Description: as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E Java 9 is coming, and Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules starting by just defining Automatic Modules Names is a quickstart was: as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E Java 9 is coming, and Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules > add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module > names > > > Key: MRESOLVER-26 > URL: https://issues.apache.org/jira/browse/MRESOLVER-26 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Maven Artifact Resolver 1.0.3 >Reporter: Hervé Boutemy > Fix For: Maven Artifact Resolver 1.1.0 > > > as discussed in dev ML: > https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E > Java 9 is coming, and Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > starting by just defining Automatic Modules Names is a quickstart -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MRESOLVER-26) add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names
[ https://issues.apache.org/jira/browse/MRESOLVER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRESOLVER-26: --- Description: as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E Java 9 is coming, and Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules was:as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E > add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module > names > > > Key: MRESOLVER-26 > URL: https://issues.apache.org/jira/browse/MRESOLVER-26 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Maven Artifact Resolver 1.0.3 >Reporter: Hervé Boutemy > Fix For: Maven Artifact Resolver 1.1.0 > > > as discussed in dev ML: > https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E > Java 9 is coming, and Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MRESOLVER-27) turn artifacts into Java 9 modules
Hervé Boutemy created MRESOLVER-27: -- Summary: turn artifacts into Java 9 modules Key: MRESOLVER-27 URL: https://issues.apache.org/jira/browse/MRESOLVER-27 Project: Maven Resolver Issue Type: New Feature Affects Versions: Maven Artifact Resolver 1.0.3 Reporter: Hervé Boutemy could be useful for Maven Artifact Resolver consumers -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MRESOLVER-26) add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names
Hervé Boutemy created MRESOLVER-26: -- Summary: add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names Key: MRESOLVER-26 URL: https://issues.apache.org/jira/browse/MRESOLVER-26 Project: Maven Resolver Issue Type: Improvement Affects Versions: Maven Artifact Resolver 1.0.3 Reporter: Hervé Boutemy Fix For: Maven Artifact Resolver 1.1.0 as discussed in dev ML: https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027395#comment-16027395
]
M.P. Korstanje edited comment on SUREFIRE-1372 at 5/27/17 10:59 AM:
bq. Ok, lets try to use latest cucumber release version without having
2.0.0-SNAPSHOT and run the build of surefire mvn install -P run-its. Is the
build successful?
No. {{cucumber-jvm:1.2.5}} does not provided proper id objects in Descriptions.
They don't implement equals and hashcode making it impossible to rerun failing
tests. This causes the the failure of JUnit47RerunFailingTestWithCucumberIT and
JUnit4RerunFailingTestWithCucumberIT.
Additionally I'm getting incorrect runcounts for JUnit4RerunFailingTestsIT
because it does not create a new {{Result}} object for the rerun session. This
did not bother the old implementation because by going straight to the
execution of the class method a testFinished event was never fired. Currently
considering how to resolve this, but at the moment I reckon it'd be best to
only support the Junit47Provider. Not unreasonable as cucumber requires Junit
4.12.
bq. Is there any way of using CucumberOptions with re-run in the old release
versions of cucumber?
No. Cucumber.Options was deprecated in favor of CucumberOptions and has been
removed in {{cucumber-jvm:1.2.0}}. This unfortunately did not result in a major
release.
bq. Any drawback?
CucumberOptions does not control or influence the rerun. It is not required.
However not using {{@CucumberOptions(junit = \{"--no-step-notifications"\})}}
means cucumber will report cucumber steps (the line in a test) as tests rather
then cucumber scenarios (the actual tests). This makes the test count and
reports look odd.
Additionally it will not be possible to rerun older versions of cucumber
because cucumber does not provide a way by which the tests to rerun can be
identified.
As shown in:
https://github.com/apache/maven-surefire/blob/cba4adb1b93002c5b4bb2d2f22f461cc53bd8738/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47WithCucumberIT.java#L57-L59
bq. Maybe the users of surefire and Cucubmer would prefer some documentation in
surefire if current CucumberOptions are possible.
Do you have any suggestion where I might submit such documentation?
was (Author: mpkorstanje):
bq. Ok, lets try to use latest cucumber release version without having
2.0.0-SNAPSHOT and run the build of surefire mvn install -P run-its. Is the
build successful?
No. {{cucumber-jvm:1.2.5}} does not provided proper id objects in Descriptions.
They don't implement equals and hashcode making it impossible to rerun failing
tests. This causes the the failure of JUnit47RerunFailingTestWithCucumberIT and
JUnit4RerunFailingTestWithCucumberIT.
Additionally I'm getting incorrect runcounts for JUnit4RerunFailingTestsIT
because it does not create a new {{Result}} object for the rerun session. This
did not bother the old implementation because by going straight to the
execution of the class method a testFinished event was never fired. Currently
considering how to resolve this, but at the moment I reckon it'd be best to
only support the Junit47Provider. Not unreasonable as cucumber requires Junit
4.12.
bq. Is there any way of using CucumberOptions with re-run in the old release
versions of cucumber?
No. Cucumber.Options was deprecated in favor of CucumberOptions and has been
removed in {{cucumber-jvm:1.2.0}}. This unfortunately did not result in a major
release.
bq. Any drawback?
CucumberOptions does not control or influence the rerun. It is not required.
However not using {{@CucumberOptions(junit = \{"--no-step-notifications"\})}}
means cucumber will report cucumber steps (the line in a test) as tests rather
then cucumber scenarios (the actual tests). This makes the test count and
reports look odd.
As shown in:
https://github.com/apache/maven-surefire/blob/cba4adb1b93002c5b4bb2d2f22f461cc53bd8738/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47WithCucumberIT.java#L57-L59
bq. Maybe the users of surefire and Cucubmer would prefer some documentation in
surefire if current CucumberOptions are possible.
Do you have any suggestion where I might submit such documentation?
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
>
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027395#comment-16027395
]
M.P. Korstanje commented on SUREFIRE-1372:
--
> Ok, lets try to use latest cucumber release version without having
> 2.0.0-SNAPSHOT and run the build of surefire mvn install -P run-its. Is the
> build successful?
No. {{cucumber-jvm:1.2.5}} does not provided proper id objects in Descriptions.
They don't implement equals and hashcode making it impossible to rerun failing
tests. This causes the the failure of JUnit47RerunFailingTestWithCucumberIT and
JUnit4RerunFailingTestWithCucumberIT.
Additionally I'm getting incorrect runcounts for JUnit4RerunFailingTestsIT
because it does not create a new {{Result}} object for the rerun session. This
did not bother the old implementation because by going straight to the
execution of the class method a testFinished event was never fired. Currently
considering how to resolve this, but at the moment I reckon it'd be best to
only support the Junit47Provider. Not unreasonable as cucumber requires Junit
4.12.
> Is there any way of using CucumberOptions with re-run in the old release
> versions of cucumber?
No. Cucumber.Options was deprecated in favor of CucumberOptions and has been
removed in {{cucumber-jvm:1.2.0}}. This unfortunately did not result in a major
release.
> Any drawback?
CucumberOptions does not control or influence the rerun. It is not required.
However not using {{@CucumberOptions(junit = \{"--no-step-notifications"\})}}
means cucumber will report cucumber steps (the line in a test) as tests rather
then cucumber scenarios (the actual tests). This makes the test count and
reports look odd.
As shown in:
https://github.com/apache/maven-surefire/blob/cba4adb1b93002c5b4bb2d2f22f461cc53bd8738/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47WithCucumberIT.java#L57-L59
> Maybe the users of surefire and Cucubmer would prefer some documentation in
> surefire if current CucumberOptions are possible.
Do you have any suggestion where I might submit such documentation?
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027395#comment-16027395
]
M.P. Korstanje edited comment on SUREFIRE-1372 at 5/27/17 10:41 AM:
bq. Ok, lets try to use latest cucumber release version without having
2.0.0-SNAPSHOT and run the build of surefire mvn install -P run-its. Is the
build successful?
No. {{cucumber-jvm:1.2.5}} does not provided proper id objects in Descriptions.
They don't implement equals and hashcode making it impossible to rerun failing
tests. This causes the the failure of JUnit47RerunFailingTestWithCucumberIT and
JUnit4RerunFailingTestWithCucumberIT.
Additionally I'm getting incorrect runcounts for JUnit4RerunFailingTestsIT
because it does not create a new {{Result}} object for the rerun session. This
did not bother the old implementation because by going straight to the
execution of the class method a testFinished event was never fired. Currently
considering how to resolve this, but at the moment I reckon it'd be best to
only support the Junit47Provider. Not unreasonable as cucumber requires Junit
4.12.
bq. Is there any way of using CucumberOptions with re-run in the old release
versions of cucumber?
No. Cucumber.Options was deprecated in favor of CucumberOptions and has been
removed in {{cucumber-jvm:1.2.0}}. This unfortunately did not result in a major
release.
bq. Any drawback?
CucumberOptions does not control or influence the rerun. It is not required.
However not using {{@CucumberOptions(junit = \{"--no-step-notifications"\})}}
means cucumber will report cucumber steps (the line in a test) as tests rather
then cucumber scenarios (the actual tests). This makes the test count and
reports look odd.
As shown in:
https://github.com/apache/maven-surefire/blob/cba4adb1b93002c5b4bb2d2f22f461cc53bd8738/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47WithCucumberIT.java#L57-L59
bq. Maybe the users of surefire and Cucubmer would prefer some documentation in
surefire if current CucumberOptions are possible.
Do you have any suggestion where I might submit such documentation?
was (Author: mpkorstanje):
> Ok, lets try to use latest cucumber release version without having
> 2.0.0-SNAPSHOT and run the build of surefire mvn install -P run-its. Is the
> build successful?
No. {{cucumber-jvm:1.2.5}} does not provided proper id objects in Descriptions.
They don't implement equals and hashcode making it impossible to rerun failing
tests. This causes the the failure of JUnit47RerunFailingTestWithCucumberIT and
JUnit4RerunFailingTestWithCucumberIT.
Additionally I'm getting incorrect runcounts for JUnit4RerunFailingTestsIT
because it does not create a new {{Result}} object for the rerun session. This
did not bother the old implementation because by going straight to the
execution of the class method a testFinished event was never fired. Currently
considering how to resolve this, but at the moment I reckon it'd be best to
only support the Junit47Provider. Not unreasonable as cucumber requires Junit
4.12.
> Is there any way of using CucumberOptions with re-run in the old release
> versions of cucumber?
No. Cucumber.Options was deprecated in favor of CucumberOptions and has been
removed in {{cucumber-jvm:1.2.0}}. This unfortunately did not result in a major
release.
> Any drawback?
CucumberOptions does not control or influence the rerun. It is not required.
However not using {{@CucumberOptions(junit = \{"--no-step-notifications"\})}}
means cucumber will report cucumber steps (the line in a test) as tests rather
then cucumber scenarios (the actual tests). This makes the test count and
reports look odd.
As shown in:
https://github.com/apache/maven-surefire/blob/cba4adb1b93002c5b4bb2d2f22f461cc53bd8738/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47WithCucumberIT.java#L57-L59
> Maybe the users of surefire and Cucubmer would prefer some documentation in
> surefire if current CucumberOptions are possible.
Do you have any suggestion where I might submit such documentation?
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
>
[jira] [Issue Comment Deleted] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1374:
---
Comment: was deleted
(was: [~matteor]
These are errors for you as users. We are not sending wrong data to ourselves.
That's the point of these dumpfiles that you have to investigate what your code
and JVM is doing with the stream.)
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027306#comment-16027306
]
Tibor Digana edited comment on SUREFIRE-1374 at 5/27/17 7:13 AM:
-
[~matteor]
These are errors for you as users. We are not sending wrong data to ourselves.
That's the point of these dumpfiles that you have to investigate what your code
and JVM is doing with the stream.
was (Author: tibor17):
[~matteor]
These are error for you user. We are not sending wrong data to ourselves.
That's the point of these dumpfiles that you have to investigate what your code
and JVM is doing with the stream.
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0
--
This message was sent by Atlassian JIRA
[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027306#comment-16027306
]
Tibor Digana commented on SUREFIRE-1374:
[~matteor]
These are error for you user. We are not sending wrong data to ourselves.
That's the point of these dumpfiles that you have to investigate what your code
and JVM is doing with the stream.
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
