[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error

2017-07-11 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083443#comment-16083443
 ] 

Tibor Digana commented on SUREFIRE-1374:


Thx. I have a fix prepared in my working copy been developed in December
2016 but it is a big change so we would first proceed with small one
SUREFIRE-1302 making release 2.20.1 and then release with version 2.20.2
including the patch from December.

On Wed, Jul 12, 2017 at 6:37 AM, Emmanuel Lecharny (JIRA) 



> 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
>Assignee: Tibor Digana
>
> 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.4.14#64029)

[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error

2017-07-11 Thread Emmanuel Lecharny (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083435#comment-16083435
 ] 

Emmanuel Lecharny commented on SUREFIRE-1374:
-

Ok, I can confirm that the 21-SNAPSHOT is fixing the issue, which otherwise 
occurs 75% of the time when I run a mvn test.

At this point, I'd fancy a release :-)

Sorry for the delayed check, and thanks for the fix !

> 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
>Assignee: Tibor Digana
>
> 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.4.14#64029)

[jira] [Created] (SUREFIRE-1389) Java package regex via command line selects no tests

2017-07-11 Thread Josh Elser (JIRA) 
Josh Elser created SUREFIRE-1389:


 Summary: Java package regex via command line selects no tests
 Key: SUREFIRE-1389
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1389
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.20
Reporter: Josh Elser


We noticed the following problem over in 
[HBase|https://issues.apache.org/jira/browse/HBASE-18264?focusedCommentId=16082795=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16082795]

On surefire 2.18.1 and 2.19.1, the following command would have the effect of 
running all tests which exist in the package {{org.apache.hadoop.hbase.quotas}}:

{noformat}
mvn package -Dtest='org.apache.hadoop.hbase.quotas.*'
{noformat}

Upon upgrading to 2.20, the same command executes no tests.

If helpful, plugin configuration (albeit convoluted) can be found at 
https://github.com/apache/hbase/blob/branch-2/pom.xml. Happy to provide other 
info to help debug further -- I haven't tried a trivial reproduction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MJAR-238) Allow setting of module main class

2017-07-11 Thread Robert Scholte (JIRA) 

[ 
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082813#comment-16082813
 ] 

Robert Scholte commented on MJAR-238:
-

bq. When using the JDK9 jar command ...

Right, but almost every packaging plugin uses Plexus Archiver. This means that 
we must change the {{module-info.class}} during packaging, probably with ASM. 
If there's a new release of ASM, we can pick this up.

> Allow setting of module main class
> --
>
> Key: MJAR-238
> URL: https://issues.apache.org/jira/browse/MJAR-238
> Project: Maven JAR Plugin
>  Issue Type: Improvement
> Environment: Java9 build 9+176, MacOS
>Reporter: Machiel Groeneveld
>Priority: Minor
>
> When a Java9 module is created using the maven-jar plugin, setting the 
> manifest/mainclass does not set the module main class. Therefore the module 
> is not executable without specifying the main class. Executing the module 
> using java -m domain.app gives the following error:
> _module jigsaw.app does not have a MainClass attribute_
> According to the module specification a module (jar) can have a main class 
> set. If I understand correctly it's inside the module-info.class as a 
> property called ModuleMainClass
> When using the JDK9 jar command it will update the jar and the 
> module-info.class.
> {noformat}
>   -e, --main-class=CLASSNAME The application entry point for stand-alone
>  applications bundled into a modular, or 
> executable,
>  jar archive
> {noformat}
> I guess it would make sense to have this as a separate configuration item 
> since the mainclass entry in the manifest file is not needed in 'module mode' 
> and vice versa.
> If this is a duplicate of another issue, please close this one, I couldn't 
> find any existing issues related to this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6254) Clarificatin on sorting in Repository Metadata

2017-07-11 Thread Markus Karg (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082801#comment-16082801
 ] 

Markus Karg commented on MNG-6254:
--

Just as I said, all I propose is to clarify and document, not to rework 
anything.

> Clarificatin on  sorting in Repository Metadata
> -
>
> Key: MNG-6254
> URL: https://issues.apache.org/jira/browse/MNG-6254
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0
>Reporter: Markus Karg
>
> The document 
> http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
>  explains that  does contain a _List_, hence is _sorted_.
> When pulling _real _metadata from Maven Central, e. g. 
> http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml,
>  it is apparent that the content of  is _not_ sorted (in this 
> example, 1.1-ea is listed _after_ 1.1, which is a violation of the sorting, 
> because -ea must be listed _before_ 1.1). So effectively Maven Central 
> devliers _unsorted_ versions.
> Also, the effectively listed XSD 
> http://maven.apache.org/xsd/metadata-1.1.0.xsd is nonexistent, so cannot be 
> looked but whether Maven Central is wrong, or whether actually the 
> specification should say it must be Set instead of List.
> To sum up, there should be a clarification whether  must be sorted 
> according to the Maven Version Numbering Schema, whether it must be Set vs 
> List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6254) Clarificatin on sorting in Repository Metadata

2017-07-11 Thread Manfred Moser (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082666#comment-16082666
 ] 

Manfred Moser commented on MNG-6254:


I do not think it is realistic to reprocess all existing metadata files based 
on some new desired "correct" behavior. Instead I propose to document how it 
actually works 

> Clarificatin on  sorting in Repository Metadata
> -
>
> Key: MNG-6254
> URL: https://issues.apache.org/jira/browse/MNG-6254
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0
>Reporter: Markus Karg
>
> The document 
> http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
>  explains that  does contain a _List_, hence is _sorted_.
> When pulling _real _metadata from Maven Central, e. g. 
> http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml,
>  it is apparent that the content of  is _not_ sorted (in this 
> example, 1.1-ea is listed _after_ 1.1, which is a violation of the sorting, 
> because -ea must be listed _before_ 1.1). So effectively Maven Central 
> devliers _unsorted_ versions.
> Also, the effectively listed XSD 
> http://maven.apache.org/xsd/metadata-1.1.0.xsd is nonexistent, so cannot be 
> looked but whether Maven Central is wrong, or whether actually the 
> specification should say it must be Set instead of List.
> To sum up, there should be a clarification whether  must be sorted 
> according to the Maven Version Numbering Schema, whether it must be Set vs 
> List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6254) Clarificatin on sorting in Repository Metadata

2017-07-11 Thread Markus Karg (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082613#comment-16082613
 ] 

Markus Karg commented on MNG-6254:
--

Actually the aim of this bug report is that make clear what the specification 
wants, neither what you "AFAIK" nor what I want. It is to be clarified and 
clearly documented once.

> Clarificatin on  sorting in Repository Metadata
> -
>
> Key: MNG-6254
> URL: https://issues.apache.org/jira/browse/MNG-6254
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0
>Reporter: Markus Karg
>
> The document 
> http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
>  explains that  does contain a _List_, hence is _sorted_.
> When pulling _real _metadata from Maven Central, e. g. 
> http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml,
>  it is apparent that the content of  is _not_ sorted (in this 
> example, 1.1-ea is listed _after_ 1.1, which is a violation of the sorting, 
> because -ea must be listed _before_ 1.1). So effectively Maven Central 
> devliers _unsorted_ versions.
> Also, the effectively listed XSD 
> http://maven.apache.org/xsd/metadata-1.1.0.xsd is nonexistent, so cannot be 
> looked but whether Maven Central is wrong, or whether actually the 
> specification should say it must be Set instead of List.
> To sum up, there should be a clarification whether  must be sorted 
> according to the Maven Version Numbering Schema, whether it must be Set vs 
> List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DOXIA-554) Parsing Markdown documents can hang site generation: switch parser from Pegdown to Flexmark

2017-07-11 Thread Michael Benz (JIRA) 

[ 
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082239#comment-16082239
 ] 

Michael Benz commented on DOXIA-554:


No - the next version 1.8 has not been released. You would need to checkout the 
source and install this into your local repository.
Just checked 
https://mvnrepository.com/artifact/org.apache.maven.doxia/doxia-module-markdown 
to make sure.

> Parsing Markdown documents can hang site generation: switch parser from 
> Pegdown to Flexmark
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
>Assignee: Hervé Boutemy
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site 
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since 
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to 
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial 
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological 
> input runtime can even become exponential, which means that the parser either 
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to 
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kennedy updated MNG-6255:

Description: 
A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will not 
parse it correctly. The script uses the {{tr}} command to change *LF* to space, 
but this leaves *CR* behind. For example, with the {{jvm.config}} file 
containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following 
error message is printed:

{code}
$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial heap size: -Xms512m
{code}


  was:
A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will not 
parse it correctly. The script uses the {{tr}} command to change *LF* to space, 
but this leaves *CR* behind. For example, with the {{jvm.config}} file 
containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following 
error message is printed:

{code}
$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m
{code}



> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will 
> not parse it correctly. The script uses the {{tr}} command to change *LF* to 
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file 
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following 
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kennedy updated MNG-6255:

Description: 
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{$ mvn install}}
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m

  was:
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m


> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
> parse it correctly. The script uses the 'tr' command to change LF to space, 
> but this leaves CR behind. For example, with the 'jvm.config' file containing 
> the text '-Xmx1024m -Xms512m' followed by CRLF, the following error message 
> is printed:
> {{$ mvn install}}
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial head size: -Xms512m



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kennedy updated MNG-6255:

Description: 
A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will not 
parse it correctly. The script uses the {{tr}} command to change *LF* to space, 
but this leaves *CR* behind. For example, with the {{jvm.config}} file 
containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following 
error message is printed:

{code}
$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m
{code}


  was:
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{
{{$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m}}
}}


> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will 
> not parse it correctly. The script uses the {{tr}} command to change *LF* to 
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file 
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following 
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial head size: -Xms512m
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1608#comment-1608
 ] 

Andrew Kennedy commented on MNG-6255:
-

Fixed by https://github.com/apache/maven/pull/127

> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will 
> not parse it correctly. The script uses the {{tr}} command to change *LF* to 
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file 
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following 
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kennedy updated MNG-6255:

Description: 
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{
{{$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m}}
}}

  was:
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{
$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m
}}


> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
> parse it correctly. The script uses the 'tr' command to change LF to space, 
> but this leaves CR behind. For example, with the 'jvm.config' file containing 
> the text '-Xmx1024m -Xms512m' followed by CRLF, the following error message 
> is printed:
> {{
> {{$ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial head size: -Xms512m}}
> }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kennedy updated MNG-6255:

Description: 
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{
$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m
}}

  was:
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{$ mvn install}}
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m


> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
> parse it correctly. The script uses the 'tr' command to change LF to space, 
> but this leaves CR behind. For example, with the 'jvm.config' file containing 
> the text '-Xmx1024m -Xms512m' followed by CRLF, the following error message 
> is printed:
> {{
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial head size: -Xms512m
> }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kennedy updated MNG-6255:

Description: 
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

$ mvn install
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m

  was:
A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{$ mvn install
Error: Could not create the Java Virtual Machinbe.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m}}


> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows 
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
> parse it correctly. The script uses the 'tr' command to change LF to space, 
> but this leaves CR behind. For example, with the 'jvm.config' file containing 
> the text '-Xmx1024m -Xms512m' followed by CRLF, the following error message 
> is printed:
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial head size: -Xms512m



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MNG-6255) Maven script cannot parse jvm.config with CRLF

2017-07-11 Thread Andrew Kennedy (JIRA) 
Andrew Kennedy created MNG-6255:
---

 Summary: Maven script cannot parse jvm.config with CRLF
 Key: MNG-6255
 URL: https://issues.apache.org/jira/browse/MNG-6255
 Project: Maven
  Issue Type: Bug
  Components: Command Line
Affects Versions: 3.5.0
 Environment: Windows 7 with MINGW64 environment via Git for Windows 
0.1.1 including GNU coreutils and bash 4.4.12
Reporter: Andrew Kennedy


A project with a '.mvn/jvm.config' file that has CRLF line endings will not 
parse it correctly. The script uses the 'tr' command to change LF to space, but 
this leaves CR behind. For example, with the 'jvm.config' file containing the 
text '-Xmx1024m -Xms512m' followed by CRLF, the following error message is 
printed:

{{$ mvn install
Error: Could not create the Java Virtual Machinbe.
Error: A fatal exception has occurred. Program will exit.
Invalid initial head size: -Xms512m}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DOXIA-554) Parsing Markdown documents can hang site generation: switch parser from Pegdown to Flexmark

2017-07-11 Thread Jonathan Lally (JIRA) 

[ 
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082163#comment-16082163
 ] 

Jonathan Lally commented on DOXIA-554:
--

Hi,

I have come across a similar issue where parsing times out intermittently.
Has doxia-module-markdown version 1.8 been released?

Thanks,
Jon

> Parsing Markdown documents can hang site generation: switch parser from 
> Pegdown to Flexmark
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
>Assignee: Hervé Boutemy
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site 
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since 
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to 
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial 
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological 
> input runtime can even become exponential, which means that the parser either 
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to 
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SUREFIRE-1388) NullPointerException caused by DefaultReporterFactory.printTestFailures(DefaultReporterFactory.java:403)

2017-07-11 Thread Ruud Paulissen (JIRA) 
Ruud Paulissen created SUREFIRE-1388:


 Summary: NullPointerException caused by 
DefaultReporterFactory.printTestFailures(DefaultReporterFactory.java:403)
 Key: SUREFIRE-1388
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1388
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.20, 2.19
 Environment: Kotlin Spek
Reporter: Ruud Paulissen
 Attachments: pom kopie.xml, Schermafbeelding 2017-07-11 om 09.59.23.png

I'm trying to run Kotlin Spek tests (based on JUnit) from Maven. I've followed 
the guide on their website, and can run the tests locally perfectly fine.

When I run the Maven "test" task however, some tests are annotated with 
"FAILURE" in the output, with a plain "null" value appearing in the console. 
Upon running "mvn test -e", I get the attached stack trace.

I have attached my maven pom.xml file as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MJAR-238) Allow setting of module main class

2017-07-11 Thread Machiel Groeneveld (JIRA) 
Machiel Groeneveld created MJAR-238:
---

 Summary: Allow setting of module main class
 Key: MJAR-238
 URL: https://issues.apache.org/jira/browse/MJAR-238
 Project: Maven JAR Plugin
  Issue Type: Improvement
 Environment: Java9 build 9+176, MacOS
Reporter: Machiel Groeneveld
Priority: Minor


When a Java9 module is created using the maven-jar plugin, setting the 
manifest/mainclass does not set the module main class. Therefore the module is 
not executable without specifying the main class. Executing the module using 
java -m domain.app gives the following error:
_module jigsaw.app does not have a MainClass attribute_

According to the module specification a module (jar) can have a main class set. 
If I understand correctly it's inside the module-info.class as a property 
called ModuleMainClass

When using the JDK9 jar command it will update the jar and the 
module-info.class.

{noformat}
  -e, --main-class=CLASSNAME The application entry point for stand-alone
 applications bundled into a modular, or executable,
 jar archive
{noformat}

I guess it would make sense to have this as a separate configuration item since 
the mainclass entry in the manifest file is not needed in 'module mode' and 
vice versa.

If this is a duplicate of another issue, please close this one, I couldn't find 
any existing issues related to this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6254) Clarificatin on sorting in Repository Metadata

2017-07-11 Thread Manfred Moser (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081735#comment-16081735
 ] 

Manfred Moser commented on MNG-6254:


Afaik it is sorted by time of deployment... each deployment (independent of 
version) appends as new entry. So its sorted .. just not the way you might want 
it. 

> Clarificatin on  sorting in Repository Metadata
> -
>
> Key: MNG-6254
> URL: https://issues.apache.org/jira/browse/MNG-6254
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0
>Reporter: Markus Karg
>
> The document 
> http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
>  explains that  does contain a _List_, hence is _sorted_.
> When pulling _real _metadata from Maven Central, e. g. 
> http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml,
>  it is apparent that the content of  is _not_ sorted (in this 
> example, 1.1-ea is listed _after_ 1.1, which is a violation of the sorting, 
> because -ea must be listed _before_ 1.1). So effectively Maven Central 
> devliers _unsorted_ versions.
> Also, the effectively listed XSD 
> http://maven.apache.org/xsd/metadata-1.1.0.xsd is nonexistent, so cannot be 
> looked but whether Maven Central is wrong, or whether actually the 
> specification should say it must be Set instead of List.
> To sum up, there should be a clarification whether  must be sorted 
> according to the Maven Version Numbering Schema, whether it must be Set vs 
> List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)