[jira] [Comment Edited] (DOXIA-568) Doxia Markdown extension > Support for some MarkDown extensions has been removed since 1.7

2018-01-16 Thread Matthieu Ghilain (JIRA)

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

Matthieu Ghilain edited comment on DOXIA-568 at 1/17/18 7:28 AM:
-

I don't see anyway of influencing Flexmark configuration, the MarkDown parser 
is instantiated as a component and the configuration of that component is not 
externalized but done directly in the Doxia parsing code. I guess it should be 
a Maven plugin option if it has to be externalized.

I don't want to use old version, I like to stay up to date 
\{#emotions_dlg.smile}.

.
 So for the markdown example they are quite simple:
{code:java}
## Some title

{code}
-> previously an anchor link was automatically added to that title
{code:java}
``` xml



``` 

{code}
-> previously there was color highlighting in that small MarkDown snippet, this 
is not the case anymore.


was (Author: ghila...@gmail.com):
I don't see anyway of influencing Flexmark configuration, the MarkDown parser 
is instantiated as a component and the configuration of that component is not 
externalized but done directly in the Doxia parsing code.

I don't want to use old version, I like to stay up to date 
{#emotions_dlg.smile}.
So for the markdown example they are quite simple:

{code}

## Some title

{code}

-> previously an anchor link was automatically added to that title

{code}

``` xml



``` 

{code}

-> previously there was color highlighting in that small MarkDown snippet, this 
is not the case anymore.

> Doxia Markdown extension > Support for some MarkDown extensions has been 
> removed since 1.7
> --
>
> Key: DOXIA-568
> URL: https://issues.apache.org/jira/browse/DOXIA-568
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Site Renderer (moved to DOXIASITETOOLS)
>Affects Versions: 1.7
>Reporter: Matthieu Ghilain
>Priority: Major
>
> Currently the markdown extensions which are allowed by the Doxia parser seems 
> to be fixed to a subset of what was allowed with Doxia 1.7 and old PegDown 
> library.
> I would like to be able to use the anchor link extension which was available 
> with 1.7 as well as the syntax highlighting that was also available for 
> scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (DOXIA-568) Doxia Markdown extension > Support for some MarkDown extensions has been removed since 1.7

2018-01-16 Thread Matthieu Ghilain (JIRA)

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

Matthieu Ghilain commented on DOXIA-568:


I don't see anyway of influencing Flexmark configuration, the MarkDown parser 
is instantiated as a component and the configuration of that component is not 
externalized but done directly in the Doxia parsing code.

I don't want to use old version, I like to stay up to date 
{#emotions_dlg.smile}.
So for the markdown example they are quite simple:

{code}

## Some title

{code}

-> previously an anchor link was automatically added to that title

{code}

``` xml



``` 

{code}

-> previously there was color highlighting in that small MarkDown snippet, this 
is not the case anymore.

> Doxia Markdown extension > Support for some MarkDown extensions has been 
> removed since 1.7
> --
>
> Key: DOXIA-568
> URL: https://issues.apache.org/jira/browse/DOXIA-568
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Site Renderer (moved to DOXIASITETOOLS)
>Affects Versions: 1.7
>Reporter: Matthieu Ghilain
>Priority: Major
>
> Currently the markdown extensions which are allowed by the Doxia parser seems 
> to be fixed to a subset of what was allowed with Doxia 1.7 and old PegDown 
> library.
> I would like to be able to use the anchor link extension which was available 
> with 1.7 as well as the syntax highlighting that was also available for 
> scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-01-16 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16328334#comment-16328334
 ] 

Hervé Boutemy edited comment on MPLUGIN-328 at 1/17/18 6:33 AM:


ok, issue analyzed, plugin improvement ready, but I need to make the IT more 
simple.
 In fact, in this testcase, ASM is choking on 
{{com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class}} in 
{{com.ibm.icu:icu4j:2.6.1}} dependency
 then using MPLUGIN-305 dependency filtering feature would permit you to 
workaround the issue

Not using {{java-annotations}} mojo extractor would also solve the issue, since 
you're using javadoc annotations, but I suppose javadoc annotations are not so 
common nowadays: Java 5 annotations are more convenient, since strongly typed


was (Author: hboutemy):
ok, issue analyzed, plugin improvement ready, but I need to make the IT more 
simple.
In fact, in this testcase, ASM is choking on 
{{com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class}} in 
{{com.ibm.icu:icu4j:2.6.1}} dependency
then using MPLUGIN-305 dependency filtering feature would permit you to 
workaround the issue

Not using {{java-annotations}} mojo extractor would also sole the issue, since 
you're using javadoc annotations, but I suppose javadoc annotations are not so 
common nowadays: Java 5 annotations are more convenient, since strongly typed


> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launc

[jira] [Commented] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-01-16 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16328334#comment-16328334
 ] 

Hervé Boutemy commented on MPLUGIN-328:
---

ok, issue analyzed, plugin improvement ready, but I need to make the IT more 
simple.
In fact, in this testcase, ASM is choking on 
{{com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class}} in 
{{com.ibm.icu:icu4j:2.6.1}} dependency
then using MPLUGIN-305 dependency filtering feature would permit you to 
workaround the issue

Not using {{java-annotations}} mojo extractor would also sole the issue, since 
you're using javadoc annotations, but I suppose javadoc annotations are not so 
common nowadays: Java 5 annotations are more convenient, since strongly typed


> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused b

[jira] [Commented] (SUREFIRE-1450) TestNG Listener aren't working from Property Tag in POM.xml With JDK9

2018-01-16 Thread Hammad (JIRA)

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

Hammad commented on SUREFIRE-1450:
--

Yes I think we can, with help from [~eolivelli], I also verified that problem 
isn't reproducing with 2.21.0-SNAPSHOT .

> TestNG Listener aren't working from Property Tag in POM.xml With JDK9
> -
>
> Key: SUREFIRE-1450
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1450
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, TestNG 
> support
>Affects Versions: 2.20.1
> Environment: macOS + Ubuntu, JDK9
>Reporter: Hammad
>Assignee: Tibor Digana
>Priority: Major
>  Labels: newbie
> Fix For: 2.21.0.Jigsaw
>
>
> TestNG Listener are not working when using:
> Maven = Apache Maven 3.5.2
> JDK9
> Here is relevant repo: https://github.com/HammadHost/poc_testng_surefire
> I executed it with jdk8 in same environment listener did work, but they 
> aren't working with JDK9
> FYI: 
> https://stackoverflow.com/questions/47560412/maven-surefire-is-not-respecting-testng-listeners-in-property-tag



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1450) TestNG Listener aren't working from Property Tag in POM.xml With JDK9

2018-01-16 Thread Tibor Digana (JIRA)

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

Tibor Digana commented on SUREFIRE-1450:


[~hammadhost]

Can we close this issue? As Enrico said current version 2.21.0-SNAPSHOT does 
not reproduce the problem on your project.

> TestNG Listener aren't working from Property Tag in POM.xml With JDK9
> -
>
> Key: SUREFIRE-1450
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1450
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, TestNG 
> support
>Affects Versions: 2.20.1
> Environment: macOS + Ubuntu, JDK9
>Reporter: Hammad
>Assignee: Tibor Digana
>Priority: Major
>  Labels: newbie
> Fix For: 2.21.0.Jigsaw
>
>
> TestNG Listener are not working when using:
> Maven = Apache Maven 3.5.2
> JDK9
> Here is relevant repo: https://github.com/HammadHost/poc_testng_surefire
> I executed it with jdk8 in same environment listener did work, but they 
> aren't working with JDK9
> FYI: 
> https://stackoverflow.com/questions/47560412/maven-surefire-is-not-respecting-testng-listeners-in-property-tag



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MSHARED-47) maven-dependency-analyzer finds too many used dependencies

2018-01-16 Thread Sylwester Lachiewicz (JIRA)

[ 
https://issues.apache.org/jira/browse/MSHARED-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327953#comment-16327953
 ] 

Sylwester Lachiewicz commented on MSHARED-47:
-

I have something that can help - i found that with jre there is file 
lib/classlist distrinuted with class list inside JRE

I have not found any documentation about this feature, but only this reference:
{noformat}
JDK-8168108 lib/classlist should be packaged in java.base.jmod{noformat}

> maven-dependency-analyzer finds too many used dependencies
> --
>
> Key: MSHARED-47
> URL: https://issues.apache.org/jira/browse/MSHARED-47
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Reporter: Matthew Beermann
>Assignee: Brian Fox
>Priority: Major
> Attachments: MNG-3620-maven-dependency-analyzer.patch
>
>
> I'll just quote the post from our internal mailing list:
> "I don't like that plugin - it has reported dozens of missing dependencies 
> that were unnecessary for me, so I stopped using it. The most common example 
> is when you have a dependency on a project that has a dependency on Xerces, 
> Xalan or some other XML project and your project has java.xml.* imports, 
> which you're resolving from the JDK, it gives a higher priority to external 
> dependencies, even if another project introduces them, than it does to JDK 
> libraries."
> I've got a (possible) patch coming up in a few...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-01-16 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327913#comment-16327913
 ] 

Hervé Boutemy commented on MPLUGIN-328:
---

ok, I can open plugin.rar. BTW, I can open plugin.zip with unrar: it's not a 
zip file but a rar file with unusual extension...

And I was able to reproduce the issue: working on it

> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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.ArrayIndexOutOfBoundsException: 48188
> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.analyzeClassStream(DefaultM

[jira] [Commented] (DOXIA-568) Doxia Markdown extension > Support for some MarkDown extensions has been removed since 1.7

2018-01-16 Thread JIRA

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

Hervé Boutemy commented on DOXIA-568:
-

If you really need it, you can force use of Doxia Markdown Module version 1.6

Then, on the issue, can you give concrete Markdown examples?

And ideally see in Flexmark https://github.com/vsch/flexmark-java how the 
Pegdown extensions could be activated: perhaps there is some configuration top 
be done

> Doxia Markdown extension > Support for some MarkDown extensions has been 
> removed since 1.7
> --
>
> Key: DOXIA-568
> URL: https://issues.apache.org/jira/browse/DOXIA-568
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Site Renderer (moved to DOXIASITETOOLS)
>Affects Versions: 1.7
>Reporter: Matthieu Ghilain
>Priority: Major
>
> Currently the markdown extensions which are allowed by the Doxia parser seems 
> to be fixed to a subset of what was allowed with Doxia 1.7 and old PegDown 
> library.
> I would like to be able to use the anchor link extension which was available 
> with 1.7 as well as the syntax highlighting that was also available for 
> scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (MRELEASE-655) Maven Release Plugin Fails to perform the Release when using TFS scm

2018-01-16 Thread Robert Scholte (JIRA)

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

Robert Scholte closed MRELEASE-655.
---
Resolution: Auto Closed
  Assignee: Robert Scholte

Old issue which is still open without any recent activities. Let's assume this 
is solved by now and close it.

> Maven Release Plugin Fails to perform the Release when using TFS scm
> 
>
> Key: MRELEASE-655
> URL: https://issues.apache.org/jira/browse/MRELEASE-655
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.1
> Environment: Windows 7  64 bit, Maven 3.0.1, Java 1.6_23, TFS 2010
>Reporter: njain
>Assignee: Robert Scholte
>Priority: Blocker
>  Labels: scrub-review-started
> Attachments: Release_Command.txt, keymanager-release.log
>
>
> We are able to prepare a build successfully using Prepare release but while 
> performing release the release plugin is not able to perform release using 
> TFS 2010. It errors due to incorrect sequence of SCM commands for TFS. The 
> output of perform release is attached.
> For performing release we are issuing a command while specifies to use edit 
> mode, Provides anew TFS workspace to map and a working directory to checkout 
> code to perform a release.
> We are using the release plugin with TFS as suggested on Teamprise site 
> http://kb.teamprise.com/article/view/95



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (MRELEASE-636) Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1 version of plugin - please apply

2018-01-16 Thread Robert Scholte (JIRA)

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

Robert Scholte closed MRELEASE-636.
---
Resolution: Auto Closed
  Assignee: Robert Scholte

Old issue which is still open without any recent activities. Let's assume this 
is solved by now and close it.

> Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1 
> version of plugin - please apply
> ---
>
> Key: MRELEASE-636
> URL: https://issues.apache.org/jira/browse/MRELEASE-636
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: branch
>Affects Versions: 2.1
> Environment: Maven 2.2.1/maven3.0.X JDK6/7
>Reporter: Nico De Groote
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: Maven Release Plugin - Trunk.patch, release.patch
>
>
> When trying to create a branch with the {{commitByProject=true}} value, it is 
> not taken into account. 
> So I created a patch on for the 2.1 version.
> The attached patch consist of the following: 
> in the maven-release-manager
> # the MRELEASE-619 
> # some extra logging concerning the use of commitByProject property in the 
> AbstractScmCommitPhase.java 
> in the maven-release-plugin
> # I've put the {{commitByProject}} in the {{AbstractReleaseMojo}}, and used 
> it in both the {{BranchReleaseMojo}} and {{PrepareReleaseMojo}} in similar 
> way.  
> Can you guys create a version {{2.1.1}} fix with this patch. There seem to be 
> a lot of people out there having troublwe releasing a Flat Layout multimodule.
> I do it in the following way... 
> {noformat}
> /PARENT/pom.xml
> /MODULE1/POM.XML
> ...
> {noformat}
> and in the parent {{pom.xml}}
> {code:xml}
> 
>../MODULE1/pom.xml...
> 
> {code}
> and in SVN 
> {noformat}
> project/trunk/PARENT   (0.0.10-SNAPSHOT)
>/trunk/MODULE1  (0.0.10-SNAPSHOT)
>/trunk/ (0.0.10-SNAPSHOT)
> {noformat}
> When releasing this application we perform the following commands
> First checkout the application... and run the following command to release a 
> {{0.0.10-SNAPSHOT}} version on the trunk.
> Also make sure you did fill in the SCM information.
> # {{release:clean}} {{release:branch}} with the following values set 
> {{username= -Dpassword= -DcommitByProject=true 
> -DautoVersionSubmodules=true -DreleaseVersion=0.0.10RC1 
> -DdevelopmentVersion=0.0.11-SNAPSHOT -DupdateBranchVersions=true 
> -DbranchName=project-0.0.10_branch}}
> This will update your trunk value to {{0.11-SNAPSHOT}} and create a branch 
> with version {{0.0.10RC1-SNAPSHOT}}
> Svn will look like this
> {noformat}
> project/trunk/PARENT   (0.0.11-SNAPSHOT)
>/trunk/MODULE1  (0.0.11-SNAPSHOT)
>/trunk/ 
>/branches/project-0.0.10_branch/PARENT  (0.0.10RC1-SNAPSHOT)  
>/branches/project-0.0.10_branch/MODULE1 (0.0.10RC1-SNAPSHOT)
>/branches/project-0.0.10_branch/...
> {noformat}
> Now, when this is done checkout this newly created branch
> and perform the following
> # {{release:clean release:prepare release:perform}} with the following values 
> {{-Dusername= -Dpassword= -DcommitByProject=true 
> -DautoVersionSubmodules=true}}
> This will release your {{0.0.10RC1-SNAPSHOT}} as {{0.0.10RC1}}, creates a tag 
> for it and an upgrade the version number on the branch to 
> {{0.0.11RC2-SNAPSHOT}}
> Svn will look like this
> {noformat}
> project/trunk/PARENT   (0.0.11-SNAPSHOT)
>/trunk/MODULE1  (0.0.11-SNAPSHOT)
>/trunk/ 
>/branches/project-0.0.10_branch/PARENT  (0.0.10RC2-SNAPSHOT)  
>/branches/project-0.0.10_branch/MODULE1 (0.0.10RC2-SNAPSHOT)
>/branches/project-0.0.10_branch/...
>/tags/project-0.0.10RC1/PARENT (0.0.10RC1)
>/tags/project-0.0.10RC1/MODULE1 (0.0.10RC1)
>/tags/project-0.0.10RC1/...
> {noformat}   
> Hope this helps... 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (MRELEASE-140) Tests fail during release:perform but work elsewhere

2018-01-16 Thread Robert Scholte (JIRA)

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

Robert Scholte closed MRELEASE-140.
---
Resolution: Auto Closed
  Assignee: Robert Scholte

Old issue which is still open without any recent activities. Let's assume this 
is solved by now and close it.

> Tests fail during release:perform but work elsewhere
> 
>
> Key: MRELEASE-140
> URL: https://issues.apache.org/jira/browse/MRELEASE-140
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.0-beta-4
> Environment: Maven 2.0.4. Linux 
>Reporter: Adrian
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: 
> TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml, 
> WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml, 
> com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt, perform-output
>
>
> h2. Summary
> I have a project that builds successfully when {{mvn clean install}} is 
> executed.
> When {{mvn clean release:prepare}} is executed the integration tests run 
> successfully too.
> When {{mvn release:perform}} is executed the junit tests using surefire fail.
> h2. Details
> h3. The project layout
> The project is an EJB 3 project. The unit tests bootstrap/startup an embedded 
> EJB container to test the EJBs. The container is configured via a set of xml 
> and property files that are specified in the testResources section of the 
> pom. The embedded container is a dependency of the project with _test_ scope.
> h3. release:perform output
> The output of the release:perform goal is attached to this issue.
> h3. surefire junit test report
> The output of the release:perform goal is attached to this issue. A snippet 
> is shown here:
> {code}
> ---
> Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
> ---
> Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec 
> testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase)  Time elapsed: 
> 2.255 sec  <<< ERROR!
> [ stdout ] ---
> [ stderr ] ---
> [ stacktrace ] ---
> java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException: 
> Failed to create a new SAX parser
>   at 
> org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
>   at 
> com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
>   at 
> com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
>   at 
> com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
>   at junit.framework.TestCase.runBare(TestCase.java:128)
>   at junit.framework.TestResult$1.protect(TestResult.java:110)
>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>   at junit.framework.TestResult.run(TestResult.java:113)
>   at junit.framework.TestCase.run(TestCase.java:120)
>   at junit.framework.TestSuite.runTest(TestSuite.java:228)
>   at junit.framework.TestSuite.run(TestSuite.java:223)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at 
> org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
>   at 
> org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
>   at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
>   at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
>   at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at 
> org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
>   at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
>   at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
>   at 
> org.apache.mav

[jira] [Commented] (MRELEASE-923) mvn release:prepare-with-pom doesn't replace SNAPSHOTs defined in a SNAPSHOT parent

2018-01-16 Thread Robert Scholte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327894#comment-16327894
 ] 

Robert Scholte commented on MRELEASE-923:
-

bq. So first of all, why are the transitive dependencies resolved before the 
parent?

The project doesn't point to the parent, so there's no relationship between the 
2 pom files.

bq. And now the issue: in the released version of my.parent (1.0.0) there is 
also the released version of my.maven.plugin (1.0.0) so why is the 
relase:prepare-with-pom failing?
If I manually set the parent version to 1.0.0 before I run mvn 
relase:prepare-with-pom everything works fine as expected.

I've done quite some changes for the 3.0.0 I can't reproduce your issue.

bq. Also I when use the option "Dependency type to resolve,: specify the 
selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 
4:Extensions ): (0/1/2/3) 1: : 0" I'm asked for the relese version of the 
my.maven.plugin and can perform the release as expected.

There's room for improvement here. The root cause is that here all versions of 
the effective pom are mapped, without knowing that some versions come from a 
parent, which have already assigned new values.

bq. And a last question: why is the default answer for the "What version should 
the dependency be reset to for development?" question always the released 
version and not the next SNAPSHOT version?

This is by design. In the code it says: {{by default, keep the same version for 
the dependency after release, unless it was previously newer}}
And that makes sense. In general you should only point to a SNAPSHOT of an 
external dependency if it contains a specific change you depend on. Otherwise 
you should ask yourself if that external dependency should have been part of a 
multimodule project.

> mvn release:prepare-with-pom doesn't replace SNAPSHOTs defined in a SNAPSHOT 
> parent
> ---
>
> Key: MRELEASE-923
> URL: https://issues.apache.org/jira/browse/MRELEASE-923
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare-with-pom
>Affects Versions: 2.5.2, 2.5.3
>Reporter: Andreas Schaller
>Priority: Blocker
>
> If I use a SNAPSHOT version of a plugin within a parent pom that is also a 
> SNAPSHOT, the mvn release:prepare-with-pom can't replace it with its released 
> version.
> I'm asked:
> {noformat}
> There are still some remaining snapshot dependencies.
> : Do you want to resolve them now? (yes/no) no: : yes
> Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
> Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 
> Dependency 'my.group:my.dependency' is a snapshot (1.0.0-SNAPSHOT)
> : Which release version should it be set to? 1.0.0: : 
> What version should the dependency be reset to for development? 1.0.0: : 
> 1.0.1-SNAPSHOT
> Dependency 'my.group:my.parent' is a snapshot (1.0.0-SNAPSHOT)
> : Which release version should it be set to? 1.0.0: : 
> What version should the dependency be reset to for development? 1.0.0: : 
> 1.0.1-SNAPSHOT
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 40.211s
> [INFO] Finished at: Wed Sep 23 13:35:33 CEST 2015
> [INFO] Final Memory: 17M/157M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare-with-pom 
> (default-cli) on project my.project: Can't release project due to non 
> released dependencies :
> [ERROR] my.group:my.maven.plugin:maven-plugin:1.0.0-SNAPSHOT:runtime
> {noformat}
> Example parent pom:
> {code:xml}
> 
> my.group
> my.parent
> 1.0.0-SNAPSHOT
> pom
> 
> 
> java-packaging-tools
> 
> true
> 
> 
> 
> 
> my.group
> my.maven.plugin
> 1.0.0-SNAPSHOT
> 
> 
> 
> 
> 
> 
> {code}
> Example project pom:
> {code:xml}
> 
> my.group
> my.project
> 1.0.0-SNAPSHOT
> 
> 
> my.group
> my.dependency
> 1.0.0-SNAPSHOT
> 
> 
> 
> {code}
> So first of all, why are the transitive dependencies resolved before the 
> parent?
> And now the issue: in the released version of my.parent (1.0.0) there is also 
> the released version of my.maven.plugin (1.0.0) so why is the 
> relase:prepare-with-pom failing?
> If I manually set the parent version to 1.0.0 before I run mvn

[jira] [Created] (MSHARED-676) Providing https links to verify dist KEYS

2018-01-16 Thread Sylwester Lachiewicz (JIRA)
Sylwester Lachiewicz created MSHARED-676:


 Summary: Providing https links to verify dist KEYS
 Key: MSHARED-676
 URL: https://issues.apache.org/jira/browse/MSHARED-676
 Project: Maven Shared Components
  Issue Type: Bug
Reporter: Sylwester Lachiewicz


Links in download.html page for each component should point to https:// site

ie. [https://maven.apache.org/shared/maven-dependency-tree/download.cgi]

has links to 

[http://www.apache.org/dist/maven/KEYS|http://www.apache.org/dev/release-signing#verifying-signature]

[http://www.apache.org/dev/release-signing#verifying-signature]

[http://www.apache.org/dist/maven/shared/maven-dependency-tree-3.0.1-source-release.zip.md5]

 

Search in sources for: 
{noformat}
href="http://{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MPLUGIN-297) plugin-info.html should contain a better Usage section

2018-01-16 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MPLUGIN-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327787#comment-16327787
 ] 

Hervé Boutemy commented on MPLUGIN-297:
---

simply removing plugins section does not looks a good idea

Perhaps messages can be improved to explain about pluginManagement vs plugins: 
don't hesitate to provide PR

[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-plugin/src/main/resources/plugin-report.properties]

keys are {{report.plugin.usage.pluginManagement}} and 
{{report.plugin.usage.plugins}}

> plugin-info.html should contain a better Usage section
> --
>
> Key: MPLUGIN-297
> URL: https://issues.apache.org/jira/browse/MPLUGIN-297
> Project: Maven Plugin Tools
>  Issue Type: Improvement
>  Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN-297-maven-plugin-tools.patch
>
>
> The usage section in the page "plugin-info.html" being generated by the 
> {{report}} goal of the {{maven-plugin-plugin}} contains the version 
> information of the plugin in both sections {{pluginManagement}} as well as 
> {{plugins}}. I think it is best practice to only give out the version in the 
> {{pluginManagement}}. Therefore please remove the version from  the 
> {{plugins}} section.
> One example for that can be seen in 
> https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (MPLUGIN-297) plugin-info.html should contain a better Usage section

2018-01-16 Thread JIRA

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

Hervé Boutemy updated MPLUGIN-297:
--
Fix Version/s: (was: 3.5.1)
   3.6

> plugin-info.html should contain a better Usage section
> --
>
> Key: MPLUGIN-297
> URL: https://issues.apache.org/jira/browse/MPLUGIN-297
> Project: Maven Plugin Tools
>  Issue Type: Improvement
>  Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN-297-maven-plugin-tools.patch
>
>
> The usage section in the page "plugin-info.html" being generated by the 
> {{report}} goal of the {{maven-plugin-plugin}} contains the version 
> information of the plugin in both sections {{pluginManagement}} as well as 
> {{plugins}}. I think it is best practice to only give out the version in the 
> {{pluginManagement}}. Therefore please remove the version from  the 
> {{plugins}} section.
> One example for that can be seen in 
> https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MNG-6340) [Performance]To make System.gc() call configurable in target summary code

2018-01-16 Thread Tony Guan (JIRA)
Tony Guan created MNG-6340:
--

 Summary: [Performance]To make System.gc() call configurable in 
target summary code
 Key: MNG-6340
 URL: https://issues.apache.org/jira/browse/MNG-6340
 Project: Maven
  Issue Type: Improvement
  Components: Design, Patterns & Best Practices
Affects Versions: 3.5.2
 Environment: Linux, AWS, OpenStack
Reporter: Tony Guan


While investigating our internal builds (powered by Maven), I found that the in 
the maven target stats report, there is a big gap between the line of "Finished 
at ..." and "Final Memory...".

Depending on the Java heap size, there were 15 seconds to 30 seconds gap in the 
two lines. (Your mileage may vary)

Samples are (31 seconds below):

17:20:57.728 I [-@main] Finished at: 2017-10-26T17:20:57+00:00

17:21:28.105 I [-@main] Final Memory: 3352M/9102M

Further investigation showed that the big gap lies in the System.gc() call in 
maven code:

[https://github.com/apache/maven/blob/f5f76c70e1828a7e6c6267fc4bc53abc35c19ce7/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java]

The problematic code is here:
{code:java}
private void logStats( MavenSession session )
{
infoLine( '-' );
long finish = System.currentTimeMillis();
long time = finish - session.getRequest().getStartTime().getTime();
String wallClock = session.getRequest().getDegreeOfConcurrency() > 1 ? " (Wall 
Clock)" : "";
logger.info( "Total time: " + formatDuration( time ) + wallClock );
logger.info( "Finished at: " + formatTimestamp( finish ) );
System.gc();
Runtime r = Runtime.getRuntime();
long mb = 1024 * 1024;
logger.info( "Final Memory: " + ( r.totalMemory() - r.freeMemory() ) / mb + 
"M/" + r.totalMemory() / mb + "M" );
}
{code}
It turns out that for each executed target, there is a Full GC invoked, just in 
order to get the memory summary. The intention may be good, so you can 
investigate the heap footprint. But this hurts performance in an accumulated 
way, and most users are not aware of this losing cpu cycles using Maven.

Simple calculation for the cost of this coding: let's say Maven averages active 
N users, and these N users are using Maven to build everyday for T targets, 
then we have an estimate that N*T full GCs will be incurred everyday.

These Full GCs average H hours, then N*T*H is the time wasted.

Assuming they all use AWS for the builds, then it can be translated to money 
they have to pay to cloud providers unnecessary.

So we should make this "memory stats after mvn target execution" disabled by 
default. Of course, it's better to provide a parameter to disable/enable this 
summary line for more flexibility.

For current users, if you want to do something about this waste, the remedy is 
simple too: you can just add a JVM option -XX:+DisableExplicitGC from maven 
configuration.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MSITE-808) invalid XML in example

2018-01-16 Thread Gerard Weatherby (JIRA)
Gerard Weatherby created MSITE-808:
--

 Summary: invalid XML in example
 Key: MSITE-808
 URL: https://issues.apache.org/jira/browse/MSITE-808
 Project: Maven Site Plugin
  Issue Type: Improvement
  Components: documentation
Reporter: Gerard Weatherby


In 
https://maven.apache.org/plugins/maven-site-plugin/examples/configuring-reports.html,
 the "Selecting Reports from a Plugin: Configuring Report Sets" is not well 
formed; the close of the reportSet element on line 14 is missing the leading 
slash.

i.e. change  to <*/*reportSet.
h2.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (MEAR-254) Support JavaEE version 8

2018-01-16 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise reassigned MEAR-254:


Assignee: Karl Heinz Marbaise

> Support JavaEE version 8
> 
>
> Key: MEAR-254
> URL: https://issues.apache.org/jira/browse/MEAR-254
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.10.1
>Reporter: Fred Bricon
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
>
> Java EE 8 EARs can not be built using the latest ear plugin, eg. 
> {quote}
>  
> maven-ear-plugin
> 2.10.1
> 
>   true
>   8
>   lib
> 
>   
> {quote}
>  yields :
> ??Failed to execute goal 
> org.apache.maven.plugins:maven-ear-plugin:2.10.1:generate-application-xml 
> (default-generate-application-xml) on project gsdf: Invalid version [8]??
> See 
> http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html#8 
> for the latest Java EE schema updates



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (MEAR-254) Support JavaEE version 8

2018-01-16 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MEAR-254:
-
Fix Version/s: 3.0.0

> Support JavaEE version 8
> 
>
> Key: MEAR-254
> URL: https://issues.apache.org/jira/browse/MEAR-254
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.10.1
>Reporter: Fred Bricon
>Priority: Critical
> Fix For: 3.0.0
>
>
> Java EE 8 EARs can not be built using the latest ear plugin, eg. 
> {quote}
>  
> maven-ear-plugin
> 2.10.1
> 
>   true
>   8
>   lib
> 
>   
> {quote}
>  yields :
> ??Failed to execute goal 
> org.apache.maven.plugins:maven-ear-plugin:2.10.1:generate-application-xml 
> (default-generate-application-xml) on project gsdf: Invalid version [8]??
> See 
> http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html#8 
> for the latest Java EE schema updates



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRELEASE-900) release:prepare goal uses parent directory of real repository location

2018-01-16 Thread Robert Scholte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327621#comment-16327621
 ] 

Robert Scholte commented on MRELEASE-900:
-

Is this still an issue with 2.5.3?

> release:prepare goal uses parent directory of real repository location
> --
>
> Key: MRELEASE-900
> URL: https://issues.apache.org/jira/browse/MRELEASE-900
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.1
>Reporter: Jens Rabe
>Priority: Blocker
>
> I have this in my pom.xml:
> {code:xml}
> 
> 
> scm:git:http://my-git-server.example.com/git/somebody/my-project.git
> 
> ssh://g...@my-git-server.example.com:10022/somebody/my-project.git
> http://my-git-server.example.com/git/somebody/my-project
> 
> {code}
> When I do a mvn release:prepare, it tries to push the tag to 
> ssh://g...@my-git-server.example.com:10022/somebody/ instead of 
> ssh://g...@my-git-server.example.com:10022/somebody/my-project.git, causing 
> the release prepare to fail with "Access denied".
> When I add a "fake file" at the end, like:
> {code:xml}
> 
> 
> scm:git:http://my-git-server.example.com/git/somebody/my-project.git/.git
> 
> ssh://g...@my-git-server.example.com:10022/somebody/my-project.gi/.gitt
> http://my-git-server.example.com/git/somebody/my-project
> 
> {code}
> the release:prepare works, but release:perform fails because it is using the 
> URL as-is.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MRAR-70) Upgrade plexus-utils 3.1.0

2018-01-16 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MRAR-70:
---

 Summary: Upgrade plexus-utils 3.1.0
 Key: MRAR-70
 URL: https://issues.apache.org/jira/browse/MRAR-70
 Project: Maven Rar Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1028) Unable to run single test (junit)

2018-01-16 Thread Tibor Digana (JIRA)

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

Tibor Digana commented on SUREFIRE-1028:


It cannot be a regression because this feature was not changed and we have
a lot of unit and integration tests. If you attach a project + CLI to Jira
we can investigate.




> Unable to run single test (junit)
> -
>
> Key: SUREFIRE-1028
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1028
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Diwaker Gupta
>Assignee: Tibor Digana
>Priority: Critical
> Fix For: 2.18
>
>
> This is a regression from 2.15. It also looks like Surefire keeps regressing 
> on this feature (e.g. see SUREFIRE-827) -- are there no unit or integration 
> tests to prevent such regressions?
> With Surefire 2.15
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> ...
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> With Surefire 2.16
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRELEASE-991) Snapshot version is not published on snapshot repository but release version is published instead

2018-01-16 Thread Robert Scholte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327616#comment-16327616
 ] 

Robert Scholte commented on MRELEASE-991:
-

The problem seems to be the tagging. Can you check the versions in the tagged 
poms? Next question would be, what's wrong with the git command. Maybe that's 
something you can analyze yourself based on these logfiles.

> Snapshot version is not published on snapshot repository but release version 
> is published instead
> -
>
> Key: MRELEASE-991
> URL: https://issues.apache.org/jira/browse/MRELEASE-991
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.5.1, 2.5.2, 2.5.3
> Environment: Rhel 6.5, Java 8, 
>Reporter: nidhi
>Priority: Blocker
>  Labels: maven
> Attachments: 2.3.2_debug.txt, 2.5.1_debug.txt, pom.xml
>
>
> Snapshot version is not published on snapshot repository but release version 
> is published instead.
> Release is successful. No errors.
> Only change is upgrade of release plugin from 2.3.2 to 2.5.2
> Also tried 2.5.1 and 2.5.3 but none worked.
> Using apache maven 3.5.0
> Steps:
> •mvn clean install 
> •mvn release:prepare
> •mvn release:perform
> Output: Build Success in all three
> when I use maven release plugin 2.3.2 version , I can publish snapshot in 
> snapshot repo but nothing is published in release repo



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MNG-2205) "provided" scope dependencies must be transitive

2018-01-16 Thread Chris Povirk (JIRA)

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

Chris Povirk commented on MNG-2205:
---

I just learned that JUnit [stopped using provided/optional scope for their 
annotation dependencies for similar 
reasons|https://github.com/junit-team/junit5/issues/1105]: Users were reporting 
problems because the annotations weren't visible to downstream projects (e.g., 
[1|https://github.com/junit-team/junit5/issues/1104], 
[2|https://github.com/junit-team/junit5/issues/1210]).

> "provided" scope dependencies must be transitive
> 
>
> Key: MNG-2205
> URL: https://issues.apache.org/jira/browse/MNG-2205
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A 
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency 
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency 
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course! 
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be 
> somewhere on the runtime classpath in order for the application to function. 
> It's valid for Project C to assume that Sybase JConnect is available and use 
> JDBC all over the Project C code. Project C is safe to do this because it can 
> happily deduce that Sybase JConnect will be there in the runtime environment 
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely 
> critical and common sense that provided scope dependencies are transitive. 
> For the (very rare) odd case where you don't want to inherit provided 
> dependencies, you can  them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRELEASE-932) ReleaseFailureException of an artefact wich version as a property

2018-01-16 Thread Robert Scholte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327586#comment-16327586
 ] 

Robert Scholte commented on MRELEASE-932:
-

Can you add a minimal project (just some poms with this dependency) to 
reproduce the issue. For some reason the plugin detects a version conflict in 
your project.

> ReleaseFailureException of an artefact wich version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.1, 2.5.3
> Environment: Maven 3.2.1
> Windows 7
> Intel Core i7
>Reporter: Antoine
>Priority: Major
>  Labels: bug
>
> After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got 
>  the following exception:
> {quote}
> message : Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on 
> project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) 
> requires a different version (15.4.0) than what is found (12.2.1) for the 
> expression (version.client.tested) in the project 
> (com.mycompagny.myapp:myapp-client).
> cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different 
> version (15.4.0) than what is found (12.2.1) for the expression 
> (version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
> Stack trace : 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare 
> (default-cli) on project ping-parent: The artifact 
> (fr.generali.gael.ping:ping-injection-client) requires a different version 
> (15.4.1-git) than what is found (15.4.0) for the expression 
> (version.client.tested) in the project 
> (fr.generali.gael.ping:ping-client-test).
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java
> {quote}   
> This error happens in a multi-module application.
> For testing purpose, we depends from an older version of an artefact of the 
> same application.
> When the artefact version is an expression (ie. $\{version.client.tested\}), 
> the 
> [AbstractRewritePomsPhase|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.release/maven-release-manager/2.5.1/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java/#545]
>  class do a chek.
> If we don't use the expression (i.e. properties), the release is working.
> Maven configuration that fails:
> {code}
> 
>   12.1.0
> 
> 
>   ${project.groupId}
>   myapp-client
>   ${version.client.tested}
>  
> {code}
> Maven configuration that is working:
> {code}
> 
>   ${project.groupId}
>   myapp-client
>   12.1.0
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (MRESOLVER-34) Update dependences and plugins to latest versions

2018-01-16 Thread Michael Osipov (JIRA)

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

Michael Osipov closed MRESOLVER-34.
---
Resolution: Fixed

Fixed with 
[6f3158e6f62eb75ea9f2de857ba9babc0c174157|https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=6f3158e6f62eb75ea9f2de857ba9babc0c174157].

> Update dependences and plugins to latest versions
> -
>
> Key: MRESOLVER-34
> URL: https://issues.apache.org/jira/browse/MRESOLVER-34
> Project: Maven Resolver
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.1
>
>
> Update to latest versions based on versions:display-dependency-updates report
> {noformat}
> org.apache.httpcomponents:httpcore  4.4.6 -> 4.4.8
> org.eclipse.jetty:jetty-server  9.2.9.v20150224 -> 9.4.8.v20171121
> org.eclipse.jetty:jetty-servlet ... 9.2.9.v20150224 -> 9.4.8.v20171121
> org.eclipse.jetty:jetty-util .. 9.2.9.v20150224 -> 9.4.8.v20171121
> org.codehaus.plexus:plexus-utils . 3.0.24 -> 3.1.0
> org.eclipse.sisu:org.eclipse.sisu.plexus .. 0.1.1 -> 0.3.3
> org.sonatype.sisu:sisu-guice .. 3.1.6 -> 3.2.6
> {noformat}
> And plugins in demos:
> maven-invoker-plugin:3.0.1
> junit:junit:4.12
> org.eclipse.sisu.plexus:0.3.3



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (MRESOLVER-34) Update dependences and plugins to latest versions

2018-01-16 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MRESOLVER-34:

Fix Version/s: Maven Artifact Resolver 1.1.1

> Update dependences and plugins to latest versions
> -
>
> Key: MRESOLVER-34
> URL: https://issues.apache.org/jira/browse/MRESOLVER-34
> Project: Maven Resolver
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.1
>
>
> Update to latest versions based on versions:display-dependency-updates report
> {noformat}
> org.apache.httpcomponents:httpcore  4.4.6 -> 4.4.8
> org.eclipse.jetty:jetty-server  9.2.9.v20150224 -> 9.4.8.v20171121
> org.eclipse.jetty:jetty-servlet ... 9.2.9.v20150224 -> 9.4.8.v20171121
> org.eclipse.jetty:jetty-util .. 9.2.9.v20150224 -> 9.4.8.v20171121
> org.codehaus.plexus:plexus-utils . 3.0.24 -> 3.1.0
> org.eclipse.sisu:org.eclipse.sisu.plexus .. 0.1.1 -> 0.3.3
> org.sonatype.sisu:sisu-guice .. 3.1.6 -> 3.2.6
> {noformat}
> And plugins in demos:
> maven-invoker-plugin:3.0.1
> junit:junit:4.12
> org.eclipse.sisu.plexus:0.3.3



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (MRESOLVER-34) Update dependences and plugins to latest versions

2018-01-16 Thread Michael Osipov (JIRA)

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

Michael Osipov reassigned MRESOLVER-34:
---

Assignee: Michael Osipov

> Update dependences and plugins to latest versions
> -
>
> Key: MRESOLVER-34
> URL: https://issues.apache.org/jira/browse/MRESOLVER-34
> Project: Maven Resolver
>  Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
>
> Update to latest versions based on versions:display-dependency-updates report
> {noformat}
> org.apache.httpcomponents:httpcore  4.4.6 -> 4.4.8
> org.eclipse.jetty:jetty-server  9.2.9.v20150224 -> 9.4.8.v20171121
> org.eclipse.jetty:jetty-servlet ... 9.2.9.v20150224 -> 9.4.8.v20171121
> org.eclipse.jetty:jetty-util .. 9.2.9.v20150224 -> 9.4.8.v20171121
> org.codehaus.plexus:plexus-utils . 3.0.24 -> 3.1.0
> org.eclipse.sisu:org.eclipse.sisu.plexus .. 0.1.1 -> 0.3.3
> org.sonatype.sisu:sisu-guice .. 3.1.6 -> 3.2.6
> {noformat}
> And plugins in demos:
> maven-invoker-plugin:3.0.1
> junit:junit:4.12
> org.eclipse.sisu.plexus:0.3.3



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MRELEASE-932) ReleaseFailureException of an artefact wich version as a property

2018-01-16 Thread Falko Modler (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327209#comment-16327209
 ] 

Falko Modler commented on MRELEASE-932:
---

This is still a problem.

Our usecase: Keeping a JBoss EAP distribution up to date with patches from 
RedHat (e.g. 6.4.0 -> 6.4.10 -> 6.4.18 etc.).
For this we need to reference the previous distribution as a dependency.

> ReleaseFailureException of an artefact wich version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.5.1, 2.5.3
> Environment: Maven 3.2.1
> Windows 7
> Intel Core i7
>Reporter: Antoine
>Priority: Major
>  Labels: bug
>
> After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got 
>  the following exception:
> {quote}
> message : Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on 
> project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) 
> requires a different version (15.4.0) than what is found (12.2.1) for the 
> expression (version.client.tested) in the project 
> (com.mycompagny.myapp:myapp-client).
> cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different 
> version (15.4.0) than what is found (12.2.1) for the expression 
> (version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
> Stack trace : 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare 
> (default-cli) on project ping-parent: The artifact 
> (fr.generali.gael.ping:ping-injection-client) requires a different version 
> (15.4.1-git) than what is found (15.4.0) for the expression 
> (version.client.tested) in the project 
> (fr.generali.gael.ping:ping-client-test).
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java
> {quote}   
> This error happens in a multi-module application.
> For testing purpose, we depends from an older version of an artefact of the 
> same application.
> When the artefact version is an expression (ie. $\{version.client.tested\}), 
> the 
> [AbstractRewritePomsPhase|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.release/maven-release-manager/2.5.1/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java/#545]
>  class do a chek.
> If we don't use the expression (i.e. properties), the release is working.
> Maven configuration that fails:
> {code}
> 
>   12.1.0
> 
> 
>   ${project.groupId}
>   myapp-client
>   ${version.client.tested}
>  
> {code}
> Maven configuration that is working:
> {code}
> 
>   ${project.groupId}
>   myapp-client
>   12.1.0
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (DOXIA-568) Doxia Markdown extension > Support for some MarkDown extensions has been removed since 1.7

2018-01-16 Thread Matthieu Ghilain (JIRA)
Matthieu Ghilain created DOXIA-568:
--

 Summary: Doxia Markdown extension > Support for some MarkDown 
extensions has been removed since 1.7
 Key: DOXIA-568
 URL: https://issues.apache.org/jira/browse/DOXIA-568
 Project: Maven Doxia
  Issue Type: Bug
  Components: Site Renderer (moved to DOXIASITETOOLS)
Affects Versions: 1.7
Reporter: Matthieu Ghilain


Currently the markdown extensions which are allowed by the Doxia parser seems 
to be fixed to a subset of what was allowed with Doxia 1.7 and old PegDown 
library.

I would like to be able to use the anchor link extension which was available 
with 1.7 as well as the syntax highlighting that was also available for scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-01-16 Thread zosrothko (JIRA)

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326895#comment-16326895
 ] 

zosrothko commented on MPLUGIN-328:
---

[~hboutemy]: Uploaded a new attachement plugin.rar build with WinRAR. BTW, 
WinRAR is opening without any problem plugin.zip

> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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.ArrayIndexOutOfBoundsException: 48188
> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.analyzeClassStream(DefaultMojoAnnotationsScanner.java:215)
> at 
> org.apache.maven.

[jira] [Updated] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-01-16 Thread zosrothko (JIRA)

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

zosrothko updated MPLUGIN-328:
--
Attachment: plugin.rar

> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Priority: Major
> Fix For: 3.6
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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.ArrayIndexOutOfBoundsException: 48188
> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.analyzeClassStream(DefaultMojoAnnotationsScanner.java:215)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.scanArchive(DefaultMojoAnnotationsScanner.java:145)
> at 
> org.apache.mave