[jira] [Updated] (SUREFIRE-1371) Plugin should fail if argLine is set when forkCount = 0
[
https://issues.apache.org/jira/browse/SUREFIRE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1371:
---
Fix Version/s: 2.20.1
> Plugin should fail if argLine is set when forkCount = 0
>
>
> Key: SUREFIRE-1371
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1371
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Gili
> Fix For: 2.20.1
>
>
> Following up on SUREFIRE-1369: The plugin should fail with a verbose error if
> {{forkCount=0}} and {{}} is set.
> Per [~tibor17], this sanity check should happen in {{AbstractSurefireMojo}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001460#comment-16001460
]
Gili commented on SUREFIRE-1369:
Not sure if I'll end up submitting a patch for this, but I filed SUREFIRE-1371
to get the ball rolling.
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), )}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1371) Plugin should fail if argLine is set when forkCount = 0
Gili created SUREFIRE-1371:
--
Summary: Plugin should fail if argLine is set when forkCount = 0
Key: SUREFIRE-1371
URL: https://issues.apache.org/jira/browse/SUREFIRE-1371
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
forking
Reporter: Gili
Following up on SUREFIRE-1369: The plugin should fail with a verbose error if
{{forkCount=0}} and {{}} is set.
Per [~tibor17], this sanity check should happen in {{AbstractSurefireMojo}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001449#comment-16001449
]
Tibor Digana commented on SUREFIRE-1369:
Such sanity check is what we really miss and the plugin should seriously fail
with verbose error.
Please help us with fixing it in GitHub. This needs to be done in a new Jira
issue and class {{AbstractSurefireMojo}}, there should be integration test as
well.
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), )}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1369) No way to output ANSI colors when running under Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001445#comment-16001445
]
Gili commented on SUREFIRE-1369:
It turns out that my mistake was mixing {{0}} with
{{}} when the latter contained system properties.
If {{forkCount}} is zero and {{}} is set, can you please issue a
warning that the latter will be ignored? It would help prevent this kind of
mistake in the future.
> No way to output ANSI colors when running under Surefire
>
>
> Key: SUREFIRE-1369
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1369
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows 10 64-bit, 10.0.14393
>Reporter: Gili
>Assignee: Tibor Digana
>
> I invoke the following native code from inside a unit test:
> {{GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), )}}
> It fails with {{GetLastError() == ERROR_INVALID_HANDLE}} indicating that
> stdout has been redirected.
> I am blocked by the fact that it isn't possible to use ANSI colors under
> Windows when stdout has been redirected. I tried configuring Surefire with:
> {code}
> 0
> false
> false
> false
> {code}
> but stdout is still getting redirected. Is it possible to configure Surefire
> to use the default stdout (connected to a terminal) without redirection?
> Expected behavior: Surefire shouldn't fork the JVM or redirect stdout when
> {{forkCount}} is zero and {{useFile}} is false.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6225) Application cannot output ANSI colors when run by Maven
[
https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001441#comment-16001441
]
Gili commented on MNG-6225:
---
Thanks for asking for a minimal testcase. As painful as it was to try to
produce, it helped me figure out the problem.
* In order to use native code, one has to point {{java.library.path}} to the
directory holding the native library.
* There are 3 ways to set this:
** Plugin-specific configuration (e.g. Surefire
{{-Djava.library.path=X}})
** Pass the system properties to the {{mvn}} command-line launcher: {{mvn
-Djava.library.path=X goals}}
** Set {{MAVEN_OPTS=-Djava.library.path=X}} prior to running {{mvn}}
command-line launcher.
I was initially configuring Surefire with {{0}} and
setting {{}}. I assumed that adding {{0}} would
be enough to transition from a forked processed to a non-forked process, but I
was wrong. When the process is not forked, {{}} gets ignored and the
system properties of the initial Maven process gets used instead. This seems
obvious in hindsight but was not obvious at the moment.
I then tried the other two options. It turns out that {{mvn -Dkey=value goals}}
is meant for non-JVM system properties (e.g. if the user application wants to
read a system property). This leaves us with one option: setting the
{{MAVEN_OPTS=-Djava.library.path=X}} environment variable. This worked.
As a result, I would like to request two changes:
1. Maven CLI should warn when it is passed a JVM system property since we know
these cannot be set this way.
2. Surefire should warn when {{0}} is mixed with
{{}}
I will file a separate bug report against Surefire for the second point. Are
you able to convert this bug report for the first point?
> Application cannot output ANSI colors when run by Maven
> ---
>
> Key: MNG-6225
> URL: https://issues.apache.org/jira/browse/MNG-6225
> Project: Maven
> Issue Type: Bug
> Components: Command Line, core
>Affects Versions: 3.5.0
>Reporter: Gili
>
> I'm not sure which Maven component this bug report belongs to (please
> reassign if needed).
> This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369
> To recap: someone (probably Maven core) is redirecting the native stdout
> handle when running plugins such as Surefire. This prevents applications from
> outputting ANSI colors under Windows 10 because:
> * Applications must explicitly enable ANSI support using JNI.
> * The JNI calls fail if the stdout handle has been redirected.
> If I run the exact same application outside of Maven, JNI no longer detects
> that stdout has been redirected and ANSI colors as expected.
> Any idea who is doing the redirection, and how to disable it?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MJAVADOC-427) "Error fetching URL" for valid non-Java API links
[
https://issues.apache.org/jira/browse/MJAVADOC-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001367#comment-16001367
]
Dick Adams commented on MJAVADOC-427:
-
Bug still present in plugin version 2.10.4
> "Error fetching URL" for valid non-Java API links
> -
>
> Key: MJAVADOC-427
> URL: https://issues.apache.org/jira/browse/MJAVADOC-427
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.3
> Environment: Windows 7
> Apache Maven 3.2.1
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
>Reporter: Selena Renee Phillips
> Attachments: testcase-detectLinks-enabled-no-manual-link-config.zip,
> testcase-detectLinks-enabled-with-manual-link-config-no-trailing-slash.zip,
> testcase-detectLinks-enabled-with-manual-link-config-trailing-slash.zip,
> testcases-detectLinks-disabled-with-manual-link-config-no-trailing-slash.zip,
> testcases-detectLinks-disabled-with-manual-link-config-trailing-slash.zip
>
>
> When I generate Javadoc for a simple project with 3rd party dependencies, no
> configuration generates links for these dependencies. For valid Javadoc links
> which have a package-list, I get the following error:
> [WARNING] javadoc: warning - Error fetching URL
> Test Cases w/ results (sample project(s)) attached:
> *1. No manual link configuration. 'detectLinks' is set to true.*
> {code:title=pom.xml - No manual link configuration with
> detectLinks=true|borderStyle=solid}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
>
> ${project.basedir}/target
> javadoc
> Epiphany
> Epiphany
> private
> true
> true
> true
> true
>
>
>
>
> javadoc
> test-javadoc
>
>
>
>
> {code}
> Output of 'mvn javadoc:javadoc':
> {code:title=Resulting output for mvn javadoc:javadoc - No manual link
> configuration with detectLinks=true|borderStyle=solid}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] Using the builder
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
> with a thread count of 1
> [INFO]
> [INFO]
>
> [INFO] Building epiphany 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany <<<
> SNIP DOWNLOADING INFO.
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany ---
> [ERROR] Error fetching link:
> http://selenium.googlecode.com/selenium-java/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link:
> http://selenium.googlecode.com/selenium-api/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link:
> http://selenium.googlecode.com/selenium-support/apidocs/package-list. Ignored
> it.
> [ERROR] Error fetching link:
> http://code.google.com/p/guava-libraries/guava/apidocs/package-list. Ignored
> it.
> [ERROR] Error fetching link:
> http://logback.qos.ch/logback-core/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link:
> http://logback.qos.ch/logback-classic/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: http://testng.org/apidocs/package-list. Ignored
> it.
> [INFO]
> Loading source files for package com.example...
> Constructing Javadoc information...
> Standard Doclet version 1.8.0_05
> Building tree for all the packages and classes...
> Generating
> C:\Users\sephilli\git\javadoc-bug\target\javadoc\com\example\AbstractLoadable.html...
> .SNIP
> 1 warning
> [WARNING] Javadoc Warnings
> [WARNING] javadoc: warning - Error fetching URL: http://www.slf4j.org/apidocs
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 13.694 s
> [INFO] Finished at: 2015-04-18T08:24:05-05:00
> [INFO] Final Memory: 16M/92M
> [INFO]
>
> {code}
> I expected that the plugin would fail to find javadoc to link for Selenium,
> Logback, Guava and TestNg, but to succeed in fetching Javadoc for SLF4Jj. The
>
[jira] [Commented] (MJAVADOC-480) Javadoc generation broken on Java9 if there are references to javax.xml.bind.annontation.XmlElement and building code for java8
[
https://issues.apache.org/jira/browse/MJAVADOC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001282#comment-16001282
]
Robert Scholte commented on MJAVADOC-480:
-
Thanks for the confirmation. This would be a valid usecase to introduce a
profile:
{code:xml}
[9,)
org.apache.maven.plugins
maven-javadoc-plugin
--add-modules ALL-SYSTEM
${additionalparam}
{code}
I don't think we should do some magic in this plugin to resolve this, the
developer should be aware of this setup.
However, let's add a FAQ or example page for it.
> Javadoc generation broken on Java9 if there are references to
> javax.xml.bind.annontation.XmlElement and building code for java8
> ---
>
> Key: MJAVADOC-480
> URL: https://issues.apache.org/jira/browse/MJAVADOC-480
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> The code uses javax.xml.bind.annotation.XmlElement annotations
> Plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
>
> true
>
>
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> This is my error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
> project scripting-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:23:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlFieldValue.java:19:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:21:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/mock/MockContactsDB.java:27:
> error: package javax.xml.bind is not visible
> [ERROR] import javax.xml.bind.JAXB;
> [ERROR] ^
> [ERROR] (package javax.xml.bind is declared in module java.xml.bind, which is
> not in the module graph)
> [ERROR]
> [ERROR] Command line was:
> /home/diennea.lan/enrico.olivelli/dev/jdk-9/bin/javadoc @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/diennea.lan/enrico.olivelli/dev/magnews/scripting/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MJAVADOC-480) Javadoc generation broken on Java9 if there are references to javax.xml.bind.annontation.XmlElement and building code for java8
[
https://issues.apache.org/jira/browse/MJAVADOC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-480:
Priority: Minor (was: Blocker)
> Javadoc generation broken on Java9 if there are references to
> javax.xml.bind.annontation.XmlElement and building code for java8
> ---
>
> Key: MJAVADOC-480
> URL: https://issues.apache.org/jira/browse/MJAVADOC-480
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Enrico Olivelli
>Priority: Minor
>
> The code uses javax.xml.bind.annotation.XmlElement annotations
> Plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
>
> true
>
>
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> This is my error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
> project scripting-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:23:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlFieldValue.java:19:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:21:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/mock/MockContactsDB.java:27:
> error: package javax.xml.bind is not visible
> [ERROR] import javax.xml.bind.JAXB;
> [ERROR] ^
> [ERROR] (package javax.xml.bind is declared in module java.xml.bind, which is
> not in the module graph)
> [ERROR]
> [ERROR] Command line was:
> /home/diennea.lan/enrico.olivelli/dev/jdk-9/bin/javadoc @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/diennea.lan/enrico.olivelli/dev/magnews/scripting/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001258#comment-16001258
]
Tibor Digana commented on SUREFIRE-1302:
[~xeagle]
[~opeyrusse]
Please let me know if you still have this issue with new version {{2.20}} of
Surefire.
If you could measure the GC pauses {{via -verbose:gc}} I would really
appreciate your help. Thx.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-564) NPE on maven 3.5.0
[ https://issues.apache.org/jira/browse/MDEP-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001231#comment-16001231 ] Karl Heinz Marbaise commented on MDEP-564: -- [~archmisha] Do you have further details? > NPE on maven 3.5.0 > -- > > Key: MDEP-564 > URL: https://issues.apache.org/jira/browse/MDEP-564 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: get >Affects Versions: 3.0.0 >Reporter: Michael Dikman >Priority: Critical > > When using get goal on maven 3.5.0 getting NPE. > Works fine on maven 3.3.9 > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get (default-cli) on > project standalone-pom: Execution default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get failed.: > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get (default-cli) > on project standalone-pom: Execution default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 20 more > Caused by: java.lang.NullPointerException > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:370) > at > org.apache.maven.shared.dependencies.resolve.internal.Maven31DependencyResolver.resolveDependencies(Maven31DependencyResolver.java:227) > at > org.apache.maven.shared.dependencies.resolve.internal.Maven31DependencyResolver.resolveDependencies(Maven31DependencyResolver.java:90) > at > org.apache.maven.shared.dependencies.resolve.internal.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:81) > at > org.apache.maven.plugins.dependency.GetMojo.execute(GetMojo.java:226) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > ... 21 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-439) Remove archetypeRepository param
[ https://issues.apache.org/jira/browse/ARCHETYPE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001188#comment-16001188 ] Karl Heinz Marbaise commented on ARCHETYPE-439: --- [~chenjianjx] First can you please more specific what exactly the problem is (and yes breaking is done with a major version change) and furthermore don't use JIRA issues for discussion please come onto the dev mailing list for further discussion... > Remove archetypeRepository param > > > Key: ARCHETYPE-439 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-439 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator > Environment: n/a >Reporter: Anders Hammar >Assignee: Robert Scholte > Fix For: 3.0.0 > > > The archetypeRepository param makes it possible to bypass the configured > Maven repos for retrieving an archetype. This is not good. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6225) Application cannot output ANSI colors when run by Maven
[ https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001098#comment-16001098 ] Michael Osipov commented on MNG-6225: - A minimal example would be very helpful. > Application cannot output ANSI colors when run by Maven > --- > > Key: MNG-6225 > URL: https://issues.apache.org/jira/browse/MNG-6225 > Project: Maven > Issue Type: Bug > Components: Command Line, core >Affects Versions: 3.5.0 >Reporter: Gili > > I'm not sure which Maven component this bug report belongs to (please > reassign if needed). > This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369 > To recap: someone (probably Maven core) is redirecting the native stdout > handle when running plugins such as Surefire. This prevents applications from > outputting ANSI colors under Windows 10 because: > * Applications must explicitly enable ANSI support using JNI. > * The JNI calls fail if the stdout handle has been redirected. > If I run the exact same application outside of Maven, JNI no longer detects > that stdout has been redirected and ANSI colors as expected. > Any idea who is doing the redirection, and how to disable it? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments
[ https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAVADOC-481: Description: In its infinite wisdom, Oracle added a new command line flag in the standard doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any script tags in headers and footers. An example use for these would be to add Google Analytics to the footer of each page of Javadoc. For example [see here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] The rejection of scripts can be turned off using "--allow-script-in-comments" (note the double hyphen). The new flag can only be added to javadoc in 1.8.0u121 or later. If the flag is added to "additionalparam" and used on earlier releases of JDK 8, it will complain that it is an unrecognised flag. Sadly, this does not work: [1.8.0.121,] --allow-script-in-comments As such, this needs to be exposed as a flag in Maven to provide a way to create a Maven pom.xml that is valid for all JDK 8 releases. Thread complaining about the lack of release notes: http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html Issue in Gradle: https://github.com/gradle/gradle/issues/1393 was: In its infinite wisdom, Oracle added a new command line flag in the standard doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any script tags in headers and footers. An example use for these would be to add Google Analytics to the footer of each page of Javadoc. For example [see here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] The rejection of scripts can be turned off using "--allow-script-in-comments" (note the double dash). The new flag can only be added to javadoc in 1.8.0u121 or later. If the flag is added to "additionalparam" and used on earlier releases of JDK 8, it will complain that it is an unrecognised flag. Sadly, this does not work: [1.8.0.121,] --allow-script-in-comments As such, this needs to be exposed as a flag in Maven to provide a way to create a Maven pom.xml that is valid for all JDK 8 releases. Thread complaining about the lack of release notes: http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html Issue in Gradle: https://github.com/gradle/gradle/issues/1393 > Java 1.8.0_u121 allow-script-in-comments > > > Key: MJAVADOC-481 > URL: https://issues.apache.org/jira/browse/MJAVADOC-481 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.4 >Reporter: Stephen Colebourne > > In its infinite wisdom, Oracle added a new command line flag in the standard > doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any > script tags in headers and footers. An example use for these would be to add > Google Analytics to the footer of each page of Javadoc. For example [see > here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] > > The rejection of scripts can be turned off using "--allow-script-in-comments" > (note the double hyphen). The new flag can only be added to javadoc in > 1.8.0u121 or later. If the flag is added to "additionalparam" and used on > earlier releases of JDK 8, it will complain that it is an unrecognised flag. > Sadly, this does not work: > > > [1.8.0.121,] > > > --allow-script-in-comments > > > As such, this needs to be exposed as a flag in Maven to provide a way to > create a Maven pom.xml that is valid for all JDK 8 releases. > Thread complaining about the lack of release notes: > http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html > Issue in Gradle: https://github.com/gradle/gradle/issues/1393 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments
[
https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-481:
Description:
In its infinite wisdom, Oracle added a new command line flag in the standard
doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any
script tags in headers and footers. An example use for these would be to add
Google Analytics to the footer of each page of Javadoc. For example [see
here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
The rejection of scripts can be turned off using "--allow-script-in-comments"
(note the double hyphen). The new flag can only be added to javadoc in
1.8.0u121 or later. If the flag is added to "additionalparam" and used on
earlier releases of JDK 8, it will complain that it is an unrecognised flag.
Sadly, this does not work:
{code}
[1.8.0.121,]
--allow-script-in-comments
{code}
As such, this needs to be exposed as a flag in Maven to provide a way to create
a Maven pom.xml that is valid for all JDK 8 releases.
Thread complaining about the lack of release notes:
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
Issue in Gradle: https://github.com/gradle/gradle/issues/1393
was:
In its infinite wisdom, Oracle added a new command line flag in the standard
doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any
script tags in headers and footers. An example use for these would be to add
Google Analytics to the footer of each page of Javadoc. For example [see
here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
The rejection of scripts can be turned off using "--allow-script-in-comments"
(note the double hyphen). The new flag can only be added to javadoc in
1.8.0u121 or later. If the flag is added to "additionalparam" and used on
earlier releases of JDK 8, it will complain that it is an unrecognised flag.
Sadly, this does not work:
[1.8.0.121,]
--allow-script-in-comments
As such, this needs to be exposed as a flag in Maven to provide a way to create
a Maven pom.xml that is valid for all JDK 8 releases.
Thread complaining about the lack of release notes:
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
Issue in Gradle: https://github.com/gradle/gradle/issues/1393
> Java 1.8.0_u121 allow-script-in-comments
>
>
> Key: MJAVADOC-481
> URL: https://issues.apache.org/jira/browse/MJAVADOC-481
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Stephen Colebourne
>
> In its infinite wisdom, Oracle added a new command line flag in the standard
> doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any
> script tags in headers and footers. An example use for these would be to add
> Google Analytics to the footer of each page of Javadoc. For example [see
> here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
>
> The rejection of scripts can be turned off using "--allow-script-in-comments"
> (note the double hyphen). The new flag can only be added to javadoc in
> 1.8.0u121 or later. If the flag is added to "additionalparam" and used on
> earlier releases of JDK 8, it will complain that it is an unrecognised flag.
> Sadly, this does not work:
> {code}
>
>
> [1.8.0.121,]
>
>
> --allow-script-in-comments
>
>
> {code}
> As such, this needs to be exposed as a flag in Maven to provide a way to
> create a Maven pom.xml that is valid for all JDK 8 releases.
> Thread complaining about the lack of release notes:
> http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
> Issue in Gradle: https://github.com/gradle/gradle/issues/1393
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000974#comment-16000974
]
Simone Bordet commented on ARCHETYPE-519:
-
Robert,
that a URL has never been a valid value for {{archetypeCatalog}} is obviously
false, since it works fine with 2.4 and it's indeed what everybody here uses in
2.4 as a workaround for the removal of this exact feature in 3.0+.
So in summary: nobody asked for this feature change, no discussion about it
that I could find (please link if there was), it went in as a surprise breaking
change in 3.0, the community complains about the 3.0 change in this issue, and
there is denial of evidence when people reports the breakage.
Can you please report the rationale behind this change ? If it was driven by
community discussion, is there a link ? Otherwise, why has this change been
made, and why there is so much resistance in restoring its functionality when
the community asks for it ?
> archetype:generate with specified remote archetypeCatalog falls back to
> internal catalog
>
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working
> anymore. It turns out it was the release of
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate
> -DarchetypeCatalog=}} we end up with the
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) >
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) <
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An
> archetype which contains a sample Maven plugin site.
> This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype
> which contains a sample Maven site which demonstrates
> some of the supported document types like APT, XDoc, and FML and
> demonstrates how
> to i18n your site. This archetype can be layered upon an existing Maven
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL
> and can be downloaded).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments
[ https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated MJAVADOC-481: Description: In its infinite wisdom, Oracle added a new command line flag in the standard doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any script tags in headers and footers. An example use for these would be to add Google Analytics to the footer of each page of Javadoc. For example [see here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] The rejection of scripts can be turned off using "--allow-script-in-comments" (note the double dash). The new flag can only be added to javadoc in 1.8.0u121 or later. If the flag is added to "additionalparam" and used on earlier releases of JDK 8, it will complain that it is an unrecognised flag. Sadly, this does not work: [1.8.0.121,] --allow-script-in-comments As such, this needs to be exposed as a flag in Maven to provide a way to create a Maven pom.xml that is valid for all JDK 8 releases. Thread complaining about the lack of release notes: http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html Issue in Gradle: https://github.com/gradle/gradle/issues/1393 was: In its infinite wisdom, Oracle added a new command line flag in the standard doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any script tags in headers and footers. An example use for these would be to add Google Analytics to the footer of each page of Javadoc. For example [see here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] The rejection of scripts can be turned off using "--allow-script-in-comments" (note the double dash). The new flag can only be added to javadoc in 1.8.0u121 or later. If the flag is added to "additionalparam" and used on earlier releases of JDK 8, it will complain that it is an unrecognised flag. Fortunately, it does seem that this works: [1.8.0.121,] --allow-script-in-comments This needs to be exposed as a flag in Maven to provide an easy way to create a Maven pom.xml that is valid for all JDK 8 releases. Thread complaining about the lack of release notes: http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html Issue in Gradle: https://github.com/gradle/gradle/issues/1393 > Java 1.8.0_u121 allow-script-in-comments > > > Key: MJAVADOC-481 > URL: https://issues.apache.org/jira/browse/MJAVADOC-481 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.4 >Reporter: Stephen Colebourne > > In its infinite wisdom, Oracle added a new command line flag in the standard > doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any > script tags in headers and footers. An example use for these would be to add > Google Analytics to the footer of each page of Javadoc. For example [see > here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] > > The rejection of scripts can be turned off using "--allow-script-in-comments" > (note the double dash). The new flag can only be added to javadoc in > 1.8.0u121 or later. If the flag is added to "additionalparam" and used on > earlier releases of JDK 8, it will complain that it is an unrecognised flag. > Sadly, this does not work: > > > [1.8.0.121,] > > > --allow-script-in-comments > > > As such, this needs to be exposed as a flag in Maven to provide a way to > create a Maven pom.xml that is valid for all JDK 8 releases. > Thread complaining about the lack of release notes: > http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html > Issue in Gradle: https://github.com/gradle/gradle/issues/1393 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MJAVADOC-481) Java Update 121 allow-script-in-comments
Stephen Colebourne created MJAVADOC-481: --- Summary: Java Update 121 allow-script-in-comments Key: MJAVADOC-481 URL: https://issues.apache.org/jira/browse/MJAVADOC-481 Project: Maven Javadoc Plugin Issue Type: Improvement Components: javadoc Affects Versions: 2.10.4 Reporter: Stephen Colebourne In its infinite wisdom, Oracle added a new command line flag in the standard doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any script tags in headers and footers. An example use for these would be to add Google Analytics to the footer of each page of Javadoc. For example [see here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645] The rejection of scripts can be turned off using "--allow-script-in-comments" (note the double dash). The new flag can only be added to javadoc in 1.8.0u121 or later. If the flag is added to "additionalparam" and used on earlier releases of JDK 8, it will complain that it is an unrecognised flag. Fortunately, it does seem that this works: [1.8.0.121,] --allow-script-in-comments This needs to be exposed as a flag in Maven to provide an easy way to create a Maven pom.xml that is valid for all JDK 8 releases. Thread complaining about the lack of release notes: http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html Issue in Gradle: https://github.com/gradle/gradle/issues/1393 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1370) Build failed in Jenkins with error :The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ https://issues.apache.org/jira/browse/SUREFIRE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000622#comment-16000622 ] Tibor Digana commented on SUREFIRE-1370: [~vijayblp] This has always been considered user error. This is stated in the log. Provide us with project to reproduce it or any argument which helps us to improve Surefire; otherwise this issue will be closed. > Build failed in Jenkins with error :The forked VM terminated without properly > saying goodbye. VM crash or System.exit called? > - > > Key: SUREFIRE-1370 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1370 > Project: Maven Surefire > Issue Type: Bug >Reporter: Vijay >Assignee: Tibor Digana > Attachments: failureLogs.txt > > > Build failed in Jenkins with error :The forked VM terminated without properly > saying goodbye. VM crash or System.exit called? > Tried on version 2.19.1 and 2.20 ,both the versions having same problem and > This problem is very frequently occured , see attached logs for more details . > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MJAVADOC-480) Javadoc generation broken on Java9 if there are references to javax.xml.bind.annontation.XmlElement and building code for java8
[
https://issues.apache.org/jira/browse/MJAVADOC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000391#comment-16000391
]
Enrico Olivelli commented on MJAVADOC-480:
--
[~rfscholte] I confirm that with
{code}
--add-modules java.se.ee
{code}
and with
{code}
--add-modules ALL-SYSTEM
{code}
unfortunately if I leave the '--add-modules' options the build fails on java8
(as expected)
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
project scripting-api: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - invalid flag: --add-modules
{code}
> Javadoc generation broken on Java9 if there are references to
> javax.xml.bind.annontation.XmlElement and building code for java8
> ---
>
> Key: MJAVADOC-480
> URL: https://issues.apache.org/jira/browse/MJAVADOC-480
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> The code uses javax.xml.bind.annotation.XmlElement annotations
> Plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
>
> true
>
>
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> This is my error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
> project scripting-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:23:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlFieldValue.java:19:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:21:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/mock/MockContactsDB.java:27:
> error: package javax.xml.bind is not visible
> [ERROR] import javax.xml.bind.JAXB;
> [ERROR] ^
> [ERROR] (package javax.xml.bind is declared in module java.xml.bind, which is
> not in the module graph)
> [ERROR]
> [ERROR] Command line was:
> /home/diennea.lan/enrico.olivelli/dev/jdk-9/bin/javadoc @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/diennea.lan/enrico.olivelli/dev/magnews/scripting/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
