[jira] [Closed] (MSITE-782) Support for custom Velocity tools has disappeared
[
https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-782.
Resolution: Fixed
Fixed with [r1765053|http://svn.apache.org/r1765053].
For that test the reflow-maven-skin has been cloned from GitHub and changed
locally to suit the changes made in this fix. The solution has been implemented
as proposed earlier. Velocity has been instructed to load all
{{META-INF/maven/site-tools.xml}} files found on the classpath.
> Support for custom Velocity tools has disappeared
> -
>
> Key: MSITE-782
> URL: https://issues.apache.org/jira/browse/MSITE-782
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.5, 3.5.1
>Reporter: Bernardo
>Assignee: Michael Osipov
> Fix For: 3.6
>
>
> Since the version 3.5 any skin using custom velocity tools is no longer
> working.
> This can be seen on the Reflow maven skin, and also on my own skin, which was
> developed from the Reflow one.
> The Reflow skin, along its Velocity tools, can be found here:
> https://github.com/andriusvelykis/reflow-maven-skin
> My Maven skin can be found here:
> https://github.com/Bernardo-MG/docs-maven-skin
> My custom velocity tools:
> https://github.com/Bernardo-MG/maven-site-fixer
> All these projects are available through Maven central, making them easy to
> test.
> To see this problem just use the Reflow skin, which won't print the content
> of any page. In the case of my own skin, there will be several errors in the
> HTML code, the most visible being the broken headers.
> It may be actually a Doxia problem, related to this issue:
> https://issues.apache.org/jira/browse/DOXIASITETOOLS-93
> Additionally, there is a related link commenting this problem:
> http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MSITE-782: -- This can be only closed when Doxia Site Tools have been updated to 1.7.2. > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-168) Add ability to explicitly load custom Velocity tools
Michael Osipov created DOXIASITETOOLS-168: - Summary: Add ability to explicitly load custom Velocity tools Key: DOXIASITETOOLS-168 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-168 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.7.1 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 1.7.2 Previous versions instructed Velocity to load tools implicitly from classpath. We never supported this officially. Now that the toolbox is created explicitly, this options is gone. Provide a way to load tools explicitly designated for the Maven Site Plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-168) Add ability to explicitly load custom Velocity tools
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed DOXIASITETOOLS-168.
-
Resolution: Fixed
Fixed with [r1765053|http://svn.apache.org/r1765053].
For that test the reflow-maven-skin has been cloned from GitHub and changed
locally to suit the changes made in this fix. The solution has been implemented
as proposed earlier. Velocity has been instructed to load all
{{META-INF/maven/site-tools.xml}} files found on the classpath.
> Add ability to explicitly load custom Velocity tools
>
>
> Key: DOXIASITETOOLS-168
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-168
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.7.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 1.7.2
>
>
> Previous versions instructed Velocity to load tools implicitly from
> classpath. We never supported this officially. Now that the toolbox is
> created explicitly, this options is gone. Provide a way to load tools
> explicitly designated for the Maven Site Plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578058#comment-15578058 ] Michael Osipov edited comment on MSITE-782 at 10/15/16 1:05 PM: This can be only closed when Doxia Sitetools have been updated to 1.7.2. was (Author: michael-o): This can be only closed when Doxia Site Tools have been updated to 1.7.2. > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578069#comment-15578069 ] Michael Osipov commented on MSITE-782: -- Again, sorry for the huge delay though this fix way easy. I was simply to busy to take a serious look at it. > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-782: - Comment: was deleted (was: This can be only closed when Doxia Sitetools have been updated to 1.7.2.) > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MSITE-782) Support for custom Velocity tools has disappeared
[
https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578056#comment-15578056
]
Michael Osipov edited comment on MSITE-782 at 10/15/16 1:07 PM:
Fixed with [r1765053|http://svn.apache.org/r1765053].
For that test the reflow-maven-skin has been cloned from GitHub and changed
locally to suit the changes made in this fix. The solution has been implemented
as proposed earlier. Velocity has been instructed to load all
{{META-INF/maven/site-tools.xml}} files found on the classpath.
This can be only closed when Doxia Sitetools have been updated to 1.7.2.
was (Author: michael-o):
Fixed with [r1765053|http://svn.apache.org/r1765053].
For that test the reflow-maven-skin has been cloned from GitHub and changed
locally to suit the changes made in this fix. The solution has been implemented
as proposed earlier. Velocity has been instructed to load all
{{META-INF/maven/site-tools.xml}} files found on the classpath.
> Support for custom Velocity tools has disappeared
> -
>
> Key: MSITE-782
> URL: https://issues.apache.org/jira/browse/MSITE-782
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.5, 3.5.1
>Reporter: Bernardo
>Assignee: Michael Osipov
> Fix For: 3.6
>
>
> Since the version 3.5 any skin using custom velocity tools is no longer
> working.
> This can be seen on the Reflow maven skin, and also on my own skin, which was
> developed from the Reflow one.
> The Reflow skin, along its Velocity tools, can be found here:
> https://github.com/andriusvelykis/reflow-maven-skin
> My Maven skin can be found here:
> https://github.com/Bernardo-MG/docs-maven-skin
> My custom velocity tools:
> https://github.com/Bernardo-MG/maven-site-fixer
> All these projects are available through Maven central, making them easy to
> test.
> To see this problem just use the Reflow skin, which won't print the content
> of any page. In the case of my own skin, there will be several errors in the
> HTML code, the most visible being the broken headers.
> It may be actually a Doxia problem, related to this issue:
> https://issues.apache.org/jira/browse/DOXIASITETOOLS-93
> Additionally, there is a related link commenting this problem:
> http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-782: - Comment: was deleted (was: Again, sorry for the huge delay though this fix way easy. I was simply to busy to take a serious look at it.) > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MSITE-782) Support for custom Velocity tools has disappeared
[
https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578056#comment-15578056
]
Michael Osipov edited comment on MSITE-782 at 10/15/16 1:08 PM:
Fixed with [r1765053|http://svn.apache.org/r1765053].
For that test the reflow-maven-skin has been cloned from GitHub and changed
locally to suit the changes made in this fix. The solution has been implemented
as proposed earlier. Velocity has been instructed to load all
{{META-INF/maven/site-tools.xml}} files found on the classpath.
Again, sorry for the huge delay though this fix way easy. I was simply to busy
to take a serious look at it. This can be only closed when Doxia Sitetools have
been updated to 1.7.2.
[~hboutemy], please remember to align the IT as soon as the upgrade has been
done.
was (Author: michael-o):
Fixed with [r1765053|http://svn.apache.org/r1765053].
For that test the reflow-maven-skin has been cloned from GitHub and changed
locally to suit the changes made in this fix. The solution has been implemented
as proposed earlier. Velocity has been instructed to load all
{{META-INF/maven/site-tools.xml}} files found on the classpath.
This can be only closed when Doxia Sitetools have been updated to 1.7.2.
> Support for custom Velocity tools has disappeared
> -
>
> Key: MSITE-782
> URL: https://issues.apache.org/jira/browse/MSITE-782
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.5, 3.5.1
>Reporter: Bernardo
>Assignee: Michael Osipov
> Fix For: 3.6
>
>
> Since the version 3.5 any skin using custom velocity tools is no longer
> working.
> This can be seen on the Reflow maven skin, and also on my own skin, which was
> developed from the Reflow one.
> The Reflow skin, along its Velocity tools, can be found here:
> https://github.com/andriusvelykis/reflow-maven-skin
> My Maven skin can be found here:
> https://github.com/Bernardo-MG/docs-maven-skin
> My custom velocity tools:
> https://github.com/Bernardo-MG/maven-site-fixer
> All these projects are available through Maven central, making them easy to
> test.
> To see this problem just use the Reflow skin, which won't print the content
> of any page. In the case of my own skin, there will be several errors in the
> HTML code, the most visible being the broken headers.
> It may be actually a Doxia problem, related to this issue:
> https://issues.apache.org/jira/browse/DOXIASITETOOLS-93
> Additionally, there is a related link commenting this problem:
> http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578091#comment-15578091 ] Hudson commented on MSITE-782: -- SUCCESS: Integrated in Jenkins build doxia-all #298 (See [https://builds.apache.org/job/doxia-all/298/]) [MSITE-782] Support for custom Velocity tools has disappeared Instruct Velocity to load possible custom tools from /META-INF/maven/site-tools.xml found in the classpath of the Maven Site Plugin. (michaelo: [http://svn.apache.org/viewvc/?view=rev&rev=1765053]) * (edit) ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java * (edit) ./doxia-sitetools/doxia-site-renderer/src/site/apt/index.apt.vm > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MANT-86) Retire the plugin
[ https://issues.apache.org/jira/browse/MANT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578112#comment-15578112 ] Michael Osipov commented on MANT-86: [~khmarbaise], please go ahead and finally retire this plugin. > Retire the plugin > - > > Key: MANT-86 > URL: https://issues.apache.org/jira/browse/MANT-86 > Project: Maven Ant Plugin > Issue Type: Wish >Affects Versions: 3.0 >Reporter: Karl Heinz Marbaise > Fix For: 3.0 > > > We should start a VOTE > http://maven.apache.org/developers/retirement-plan-plugins.html at the > 2015/02/01 to ultimately retire this plugin... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578189#comment-15578189
]
Guillaume Boué commented on MNG-6105:
-
So the issue is about copying one Properties to another. Why would
synchronizing on the source property instance not be enough? I.e, following
code:
{code:java}
public static Properties copyProperties( Properties properties )
{
final Properties copyProperties = new Properties();
synchronized ( properties )
{
copyProperties.putAll( properties );
}
return copyProperties;
}
{code}
I ran all core-its with this (both on Windows 10 and Ubuntu 16.04) and didn't
have any issues. I also ran a build of {{maven-plugins-aggregator}} with {{-T
5}}. Since it synchronizes on the given properties, it makes sure no other
thread can remove a key or set a different value to a key during the iteration
in {{putAll}}. I also noticed this is what some [Oracle internal code
does|http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/management/Agent.java/#175]
([relevant
mail|http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009795.html]).
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.ja
[jira] [Commented] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578234#comment-15578234 ] Hudson commented on MSITE-782: -- FAILURE: Integrated in Jenkins build maven-plugins #7349 (See [https://builds.apache.org/job/maven-plugins/7349/]) [MSITE-782] check that Velocity tools declared in /META-INF/maven/site-tools.xml are discovered after DOXIASITETOOLS-168 r1765053 (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1765073]) * (add) maven-site-plugin/src/it/doxia-formats/src/main/resources/META-INF * (add) maven-site-plugin/src/it/doxia-formats/src/main/resources/META-INF/maven * (add) maven-site-plugin/src/it/doxia-formats/src/main/resources/META-INF/maven/site-tools.xml * (delete) maven-site-plugin/src/it/doxia-formats/src/main/resources/tools.xml * (edit) maven-site-plugin/src/it/doxia-formats/src/site/apt/velocity-context.apt.vm * (delete) maven-site-plugin/src/it/doxia-formats/verify.groovy.edited > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-168) Add ability to explicitly load custom Velocity tools
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578233#comment-15578233 ] Hudson commented on DOXIASITETOOLS-168: --- FAILURE: Integrated in Jenkins build maven-plugins #7349 (See [https://builds.apache.org/job/maven-plugins/7349/]) [MSITE-782] check that Velocity tools declared in /META-INF/maven/site-tools.xml are discovered after DOXIASITETOOLS-168 r1765053 (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1765073]) * (add) maven-site-plugin/src/it/doxia-formats/src/main/resources/META-INF * (add) maven-site-plugin/src/it/doxia-formats/src/main/resources/META-INF/maven * (add) maven-site-plugin/src/it/doxia-formats/src/main/resources/META-INF/maven/site-tools.xml * (delete) maven-site-plugin/src/it/doxia-formats/src/main/resources/tools.xml * (edit) maven-site-plugin/src/it/doxia-formats/src/site/apt/velocity-context.apt.vm * (delete) maven-site-plugin/src/it/doxia-formats/verify.groovy.edited > Add ability to explicitly load custom Velocity tools > > > Key: DOXIASITETOOLS-168 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-168 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.7.1 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 1.7.2 > > > Previous versions instructed Velocity to load tools implicitly from > classpath. We never supported this officially. Now that the toolbox is > created explicitly, this options is gone. Provide a way to load tools > explicitly designated for the Maven Site Plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578343#comment-15578343
]
Michael Osipov commented on MNG-6105:
-
This would only work, imho, if someone else synchronizes on {{properties}} when
{{addProperty}} is called. We cannot guarantee that. Am I wrong?
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578354#comment-15578354
]
Guillaume Boué commented on MNG-6105:
-
All methods of {{Properties}} itself (and {{Hashtable}} from which it inherits)
are internally synchronized so I think the guarantee is made.
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.res
[jira] [Comment Edited] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578354#comment-15578354
]
Guillaume Boué edited comment on MNG-6105 at 10/15/16 4:07 PM:
---
All methods of {{Properties}} itself (and {{Hashtable}} from which it inherits)
are internally synchronized on {{this}} so I think the guarantee is made.
was (Author: gboue):
All methods of {{Properties}} itself (and {{Hashtable}} from which it inherits)
are internally synchronized so I think the guarantee is made.
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultA
[jira] [Updated] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-387:
Component/s: javadoc
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-387:
Affects Version/s: 2.10.4
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-387:
Fix Version/s: 3.0.0
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MJAVADOC-387:
---
Assignee: Michael Osipov
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov resolved MJAVADOC-387.
-
Resolution: Implemented
Fixed with [r1765097|http://svn.apache.org/r1765097]. Snapshot deployed. Please
test thoroughly and report. If no negative feedback is given within a week, I
will close as fixed.
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-387:
Labels: close-pending (was: )
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Labels: close-pending
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MJAVADOC-474) Deprecate parameter additionalparam
Michael Osipov created MJAVADOC-474: --- Summary: Deprecate parameter additionalparam Key: MJAVADOC-474 URL: https://issues.apache.org/jira/browse/MJAVADOC-474 Project: Maven Javadoc Plugin Issue Type: Task Components: javadoc Affects Versions: 2.10.4 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.0.0 Due to the revealings in MJAVADOC-368: bad naming, unpredictable behavior, etc. it is best to deprecate this parameter in favor of a better one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MJAVADOC-475) Introduce parameter additionalOptions
Michael Osipov created MJAVADOC-475:
---
Summary: Introduce parameter additionalOptions
Key: MJAVADOC-475
URL: https://issues.apache.org/jira/browse/MJAVADOC-475
Project: Maven Javadoc Plugin
Issue Type: New Feature
Components: javadoc
Affects Versions: 2.10.4
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.0.0
Introduce an {{additionalOptions}} parameter which allows to pass multiple
arbitrary parameters to the {{javadoc}} process without the shortcomings of
MAVADOC-368.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-368.
---
Resolution: Won't Fix
> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT
> {{additionalparamS}}. So it should not be possible to set multiple parameters
> here.
> I also tried
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578516#comment-15578516
]
Hudson commented on MJAVADOC-387:
-
SUCCESS: Integrated in Jenkins build maven-plugins #7350 (See
[https://builds.apache.org/job/maven-plugins/7350/])
[MJAVADOC-387] Handle JDK8 -Xdoclint
Add proper handling of -Xdoclint. Option is only evaluated if Java 1.8+ is used
otherwise a warning is issued.
Due to a limitation in Modello, it cannot simply enabled by because
it is umarshaled to null instead of "". One has to use all
explicitly. (michaelo: [http://svn.apache.org/viewvc/?view=rev&rev=1765097])
* (edit)
maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Labels: close-pending
> Fix For: 3.0.0
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578550#comment-15578550
]
Michael Osipov commented on MJAVADOC-368:
-
This issue has now been closed because of the based discussion and following
points:
* {{header}} are supported out of the box
* {{doclint}} can now be passed
* all other Javadoc and standard doclet options are supported ouf of the box
If someone has a reasonable usecase, please phrase it in MJAVADOC-475 and
wether this is a JavaDocOption, StandardDocletOption or AlternateDocletOption.
> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT
> {{additionalparamS}}. So it should not be possible to set multiple parameters
> here.
> I also tried
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAVADOC-475) Introduce parameter additionalOptions
[
https://issues.apache.org/jira/browse/MJAVADOC-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-475:
Assignee: (was: Michael Osipov)
> Introduce parameter additionalOptions
> -
>
> Key: MJAVADOC-475
> URL: https://issues.apache.org/jira/browse/MJAVADOC-475
> Project: Maven Javadoc Plugin
> Issue Type: New Feature
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Michael Osipov
> Fix For: 3.0.0
>
>
> Introduce an {{additionalOptions}} parameter which allows to pass multiple
> arbitrary parameters to the {{javadoc}} process without the shortcomings of
> MAVADOC-368.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MJAVADOC-474) Deprecate parameter additionalparam
[ https://issues.apache.org/jira/browse/MJAVADOC-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MJAVADOC-474. --- Resolution: Fixed Fixed with [r1765098|http://svn.apache.org/r1765098]. > Deprecate parameter additionalparam > --- > > Key: MJAVADOC-474 > URL: https://issues.apache.org/jira/browse/MJAVADOC-474 > Project: Maven Javadoc Plugin > Issue Type: Task > Components: javadoc >Affects Versions: 2.10.4 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.0.0 > > > Due to the revealings in MJAVADOC-368: bad naming, unpredictable behavior, > etc. it is best to deprecate this parameter in favor of a better one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCM-834) Git Commit encoding is platform-dependend instead of UTF-8
[
https://issues.apache.org/jira/browse/SCM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578577#comment-15578577
]
Michael Osipov commented on SCM-834:
[~tgr], do you want to create a PR based on my previous comment?
> Git Commit encoding is platform-dependend instead of UTF-8
> --
>
> Key: SCM-834
> URL: https://issues.apache.org/jira/browse/SCM-834
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.4
>Reporter: Tobias Gruetzmacher
>
> When doing a release with the maven-release-plugin, if you have a
> non-ASCII-character in your commit message (setting scmCommentPrefix to
> "lösung" for example), the resulting commit message has a different encoding
> on different operating systems. If it isn't UTF-8 (on Windows, for example),
> git complains with
> {code}
> Warning: commit message did not conform to UTF-8.
> You may want to amend it after fixing the message, or set the config
> variable i18n.commitencoding to the encoding your project uses.
> {code}
> AFAICS, the fix is pretty simple: Just add "UTF-8" to the call of fileWrite
> in
> [GitCheckInCommand.java|https://github.com/apache/maven-scm/blob/master/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/checkin/GitCheckInCommand.java#L74]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNGSITE-274) Intellij maven docs reference broken link to introduction-to-plugin-registry.html
[ https://issues.apache.org/jira/browse/MNGSITE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNGSITE-274. -- Resolution: Not A Problem > Intellij maven docs reference broken link to > introduction-to-plugin-registry.html > - > > Key: MNGSITE-274 > URL: https://issues.apache.org/jira/browse/MNGSITE-274 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Andy Gumbrecht >Priority: Trivial > Original Estimate: 1h > Remaining Estimate: 1h > > http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html > is a broken link in Intellij IDEA help docs regarding maven configuration. > Is it possible to create a redirect for this missing page? This affects all > versions of intellij to date. (21 Jan 16) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-474) Deprecate parameter additionalparam
[ https://issues.apache.org/jira/browse/MJAVADOC-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578606#comment-15578606 ] Hudson commented on MJAVADOC-474: - SUCCESS: Integrated in Jenkins build maven-plugins #7351 (See [https://builds.apache.org/job/maven-plugins/7351/]) [MJAVADOC-474] Deprecate parameter additionalparam (michaelo: [http://svn.apache.org/viewvc/?view=rev&rev=1765098]) * (edit) maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java > Deprecate parameter additionalparam > --- > > Key: MJAVADOC-474 > URL: https://issues.apache.org/jira/browse/MJAVADOC-474 > Project: Maven Javadoc Plugin > Issue Type: Task > Components: javadoc >Affects Versions: 2.10.4 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.0.0 > > > Due to the revealings in MJAVADOC-368: bad naming, unpredictable behavior, > etc. it is best to deprecate this parameter in favor of a better one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-770) Concurrent modification exception when running maven site report
[
https://issues.apache.org/jira/browse/MSITE-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-770.
Resolution: Incomplete
No minimal project provided.
> Concurrent modification exception when running maven site report
>
>
> Key: MSITE-770
> URL: https://issues.apache.org/jira/browse/MSITE-770
> Project: Maven Site Plugin
> Issue Type: Bug
>Reporter: David J. M. Karlsen
>
> {noformat}
> 10:28:35 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.5:site (default-site) on project
> jfr-srv: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.5:site failed.
> ConcurrentModificationException -> [Help 1]
> 10:28:35 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-site-plugin:3.5:site
> (default-site) on project jfr-srv: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.5:site failed.
> 10:28:35 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 10:28:35 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 10:28:35 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 10:28:35 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 10:28:35 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> 10:28:35 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> 10:28:35 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 10:28:35 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 10:28:35 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 10:28:35 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 10:28:35 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 10:28:35 at java.lang.Thread.run(Thread.java:745)
> 10:28:35 Caused by: org.apache.maven.plugin.PluginExecutionException:
> Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.5:site failed.
> 10:28:35 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> 10:28:35 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> 10:28:35 ... 11 more
> 10:28:35 Caused by: java.util.ConcurrentModificationException
> 10:28:35 at
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> 10:28:35 at java.util.ArrayList$Itr.next(ArrayList.java:851)
> 10:28:35 at
> org.apache.maven.report.projectinfo.PluginManagementReport$PluginManagementRenderer.renderSectionPluginManagement(PluginManagementReport.java:204)
> 10:28:35 at
> org.apache.maven.report.projectinfo.PluginManagementReport$PluginManagementRenderer.renderBody(PluginManagementReport.java:189)
> 10:28:35 at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:83)
> 10:28:35 at
> org.apache.maven.report.projectinfo.PluginManagementReport.executeReport(PluginManagementReport.java:83)
> 10:28:35 at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> 10:28:35 at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:227)
> 10:28:35 at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:330)
> 10:28:35 at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:181)
> 10:28:35 at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:135)
> 10:28:35 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 10:28:35 ... 12 more
> 10:28:35 [ERROR]
> 10:28:35 [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> 10:28:35 [ERROR]
> 10:28:35 [ERROR] For more information about the errors and possible
> solutions, please read the following articles:
> 10:28:35 [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {noformat}
> My pom:
> {noformat}
>
>
> parent-reports
>
>
>
>
>
> org.apache.maven.plugins
>
[jira] [Updated] (MCHANGELOG-142) UTF-8 Encoding doubled
[
https://issues.apache.org/jira/browse/MCHANGELOG-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MCHANGELOG-142:
--
Labels: sample-project-missing (was: )
> UTF-8 Encoding doubled
> --
>
> Key: MCHANGELOG-142
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-142
> Project: Maven Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Jukka Harkki
> Labels: sample-project-missing
>
> Creating changelog.xml file doubles UTF-8 encoding if the git comment
> information is already UTF-8 format. For example: if property outputEncoding
> is set to ISO-8859-1 the output is (shown as od dump):
> {code}
> 0004060 7375 7420 696f 696d 616d 6e61 6d20 c379
> u s t o i m i m a a n m y ├
> 0004100 73b6 6c20 7369 a4c3 6b79 6573 7373 a4c3
> Â s l i s ├ ñ y k s e s s ├ ñ
> {code}
> And when set to UTF-8 the output is:
> {code}
> 0004060 6d69 6d69 6161 206e 796d 83c3 b6c2 2073
> i m i m a a n m y ├ â ┬ Â s
> {code}
> The result of UTF-8 encoding is that scandinavian umlauts are garbled. Code
> C3 B6 is the right for the "ö"-letter.
> The ISO-8859-1 format would do for the site documentation but since the file
> changelog.xml header says ISO-8859-1 encoding, rest of the process fails to
> process umlauts.
> I modified class ChangeLogReport method writeChangelogXml() by commenting out
> issue MCHANGELOG-86 writer change:
> {code}
> PrintWriter pw = new PrintWriter(new BufferedOutputStream(new
> FileOutputStream(outputXML)));
> pw.write(changelogXml.toString());
> pw.flush();
> pw.close();
> // MCHANGELOG-86
> //Writer writer = WriterFactory.newWriter( new BufferedOutputStream(
> new FileOutputStream( outputXML ) ),
> // getOutputEncoding() );
> //writer.write(changelogXml.toString());
> //writer.flush();
> //writer.close();
> {code}
> It might be there is double escaping in Writer since couple of lines above
> the change set is created with encoding information:
> {code}
> String changeset = changelogSet.toXML(getOutputEncoding());
> {code}
> However, this is just a wild guess since I did not check out implementation
> of changelogSet.toXML() or writer.write(). It could be also something
> different in version control access since MCHANGELOG-86 was a SVN issue and
> here we got with GIT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHANGELOG-142) UTF-8 Encoding doubled
[
https://issues.apache.org/jira/browse/MCHANGELOG-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578622#comment-15578622
]
Michael Osipov commented on MCHANGELOG-142:
---
Please provide a minimal sample project.
> UTF-8 Encoding doubled
> --
>
> Key: MCHANGELOG-142
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-142
> Project: Maven Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Jukka Harkki
> Labels: sample-project-missing
>
> Creating changelog.xml file doubles UTF-8 encoding if the git comment
> information is already UTF-8 format. For example: if property outputEncoding
> is set to ISO-8859-1 the output is (shown as od dump):
> {code}
> 0004060 7375 7420 696f 696d 616d 6e61 6d20 c379
> u s t o i m i m a a n m y ├
> 0004100 73b6 6c20 7369 a4c3 6b79 6573 7373 a4c3
> Â s l i s ├ ñ y k s e s s ├ ñ
> {code}
> And when set to UTF-8 the output is:
> {code}
> 0004060 6d69 6d69 6161 206e 796d 83c3 b6c2 2073
> i m i m a a n m y ├ â ┬ Â s
> {code}
> The result of UTF-8 encoding is that scandinavian umlauts are garbled. Code
> C3 B6 is the right for the "ö"-letter.
> The ISO-8859-1 format would do for the site documentation but since the file
> changelog.xml header says ISO-8859-1 encoding, rest of the process fails to
> process umlauts.
> I modified class ChangeLogReport method writeChangelogXml() by commenting out
> issue MCHANGELOG-86 writer change:
> {code}
> PrintWriter pw = new PrintWriter(new BufferedOutputStream(new
> FileOutputStream(outputXML)));
> pw.write(changelogXml.toString());
> pw.flush();
> pw.close();
> // MCHANGELOG-86
> //Writer writer = WriterFactory.newWriter( new BufferedOutputStream(
> new FileOutputStream( outputXML ) ),
> // getOutputEncoding() );
> //writer.write(changelogXml.toString());
> //writer.flush();
> //writer.close();
> {code}
> It might be there is double escaping in Writer since couple of lines above
> the change set is created with encoding information:
> {code}
> String changeset = changelogSet.toXML(getOutputEncoding());
> {code}
> However, this is just a wild guess since I did not check out implementation
> of changelogSet.toXML() or writer.write(). It could be also something
> different in version control access since MCHANGELOG-86 was a SVN issue and
> here we got with GIT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNGSITE-261) .htaccess file forces http: for several redirects
[ https://issues.apache.org/jira/browse/MNGSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578628#comment-15578628 ] Michael Osipov commented on MNGSITE-261: [~hboutemy], we can safely do that. [Documentation|https://httpd.apache.org/docs/current/mod/mod_alias.html#redirect] says: bq. The new URL may be either an absolute URL beginning with a scheme and hostname, or a URL-path beginning with a slash. In this latter case the scheme and hostname of the current server will be added. > .htaccess file forces http: for several redirects > - > > Key: MNGSITE-261 > URL: https://issues.apache.org/jira/browse/MNGSITE-261 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Sebb > > The Maven site .htaccess file [1] has a lot of Redirect entries that force > the use of http: even for URLs that were originally https: > That seems wrong; the redirect should use the same scheme as the original URL. > [1] > https://svn-master.apache.org/repos/infra/websites/production/maven/content/.htaccess -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MNGSITE-261) .htaccess file forces http: for several redirects
[ https://issues.apache.org/jira/browse/MNGSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNGSITE-261: -- Assignee: Michael Osipov > .htaccess file forces http: for several redirects > - > > Key: MNGSITE-261 > URL: https://issues.apache.org/jira/browse/MNGSITE-261 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Sebb >Assignee: Michael Osipov > > The Maven site .htaccess file [1] has a lot of Redirect entries that force > the use of http: even for URLs that were originally https: > That seems wrong; the redirect should use the same scheme as the original URL. > [1] > https://svn-master.apache.org/repos/infra/websites/production/maven/content/.htaccess -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5529) Misuse of iterator.remove in DefaultModelBuilder
[ https://issues.apache.org/jira/browse/MNG-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578646#comment-15578646 ] Michael Osipov commented on MNG-5529: - Please provide a patch against current master. > Misuse of iterator.remove in DefaultModelBuilder > > > Key: MNG-5529 > URL: https://issues.apache.org/jira/browse/MNG-5529 > Project: Maven > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Christopher Hunt > Labels: patch-pending > > Line 905 of DefaultModelBuilder removes elements from the list of > dependencies for dependency management. The JDK states that the iterator's > remove operation is optional and when it is not present then an > UnsupportedOperationException will be thrown. > My recommendation is that the list of dependencies returned is composed into > an array list for working purposes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5529) Misuse of iterator.remove in DefaultModelBuilder
[ https://issues.apache.org/jira/browse/MNG-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5529: Labels: patch-pending (was: ) > Misuse of iterator.remove in DefaultModelBuilder > > > Key: MNG-5529 > URL: https://issues.apache.org/jira/browse/MNG-5529 > Project: Maven > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Christopher Hunt > Labels: patch-pending > > Line 905 of DefaultModelBuilder removes elements from the list of > dependencies for dependency management. The JDK states that the iterator's > remove operation is optional and when it is not present then an > UnsupportedOperationException will be thrown. > My recommendation is that the list of dependencies returned is composed into > an array list for working purposes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5706) Maven 3.0.4 and later versions cannot find artifact in repos declared in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5706.
---
Resolution: Works for Me
I can confirm that the sample project fails with 3.0.5 but it works with 3.2.5,
3.3.9 and 3.4.0-SNAPSHOT. Since nothing below 3.3.x is supported anymore,
closing as works for me.
> Maven 3.0.4 and later versions cannot find artifact in repos declared in
> settings.xml
> -
>
> Key: MNG-5706
> URL: https://issues.apache.org/jira/browse/MNG-5706
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.4, 3.0.5, 3.1.0, 3.1.1, 3.2.1, 3.2.2, 3.2.3
> Environment: bash-4.1$ echo $JAVA_HOME
> /developer/tools1/jdk1.7.0_45-Linux-x86_64
> bash-4.1$ which java
> /developer/tools1/jdk1.7.0_45-Linux-x86_64/bin/java
> bash-4.1$ uname -ra
> Linux klw1209.bridgewatersys.com 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10
> 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
> bash-4.1$
>Reporter: Fadel Wanssa
> Attachments: log-maven.3.0.3, log-maven.3.0.4, log-maven.3.2.3,
> pom.xml, settings.xml
>
>
> After upgrade from maven 3.0.3 to maven 3.0.4 (tried all versions after
> 3.0.4), maven cannot resolve dependencies on antlr-runtime.
> We are getting the following error:
> {noformat}
> [DEBUG] Skipped remote update check for org.antlr:ST4:jar:4.0.7, locally
> cached artifact up-to-date.
> [DEBUG] Using connector WagonRepositoryConnector with priority 0.0 for
> http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/
> [INFO] Downloading:
> http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/org/antlr/antlr-runtime/3.5/antlr-runtime-3.5.jar
> [INFO] Downloading:
> http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar
> [INFO] Downloading:
> http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/antlr/antlr/2.7.7/antlr-2.7.7.jar
> [INFO] Downloaded:
> http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/antlr/antlr/2.7.7/antlr-2.7.7.jar
> (0 B at 0.0 KB/sec)
> [DEBUG] Writing tracking file
> /users1/fadlw/maven-test/mvn_repo/org/antlr/antlr-runtime/3.5/antlr-runtime-3.5.jar.lastUpdated
> [DEBUG] Writing tracking file
> /users1/fadlw/maven-test/mvn_repo/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar.lastUpdated
> [DEBUG] Writing tracking file
> /users1/fadlw/maven-test/mvn_repo/antlr/antlr/2.7.7/antlr-2.7.7.jar.lastUpdated
> [DEBUG] Writing tracking file
> /users1/fadlw/maven-test/mvn_repo/antlr/antlr/2.7.7/_remote.repositories
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.452 s
> [INFO] Finished at: 2014-10-23T10:13:49-04:00
> [INFO] Final Memory: 6M/149M
> [INFO]
>
> [ERROR] Failed to execute goal org.antlr:antlr3-maven-plugin:3.5:antlr
> (default) on project test: Execution default of goal
> org.antlr:antlr3-maven-plugin:3.5:antlr failed: Plugin
> org.antlr:antlr3-maven-plugin:3.5 or one of its dependencies could not be
> resolved: The following artifacts could not be resolved:
> org.antlr:antlr-runtime:jar:3.5, org.antlr:stringtemplate:jar:3.2.1: Could
> not find artifact org.antlr:antlr-runtime:jar:3.5 in nexus-public
> (http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/) ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.antlr:antlr3-maven-plugin:3.5:antlr (default) on project test:
> Execution default of goal org.antlr:antlr3-maven-plugin:3.5:antlr failed:
> Plugin org.antlr:antlr3-maven-plugin:3.5 or one of its dependencies could not
> be resolved: The following artifacts could not be resolved:
> org.antlr:antlr-runtime:jar:3.5, org.antlr:stringtemplate:jar:3.2.1: Could
> not find artifact org.antlr:antlr-runtime:jar:3.5 in nexus-public
> (http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/)
> {noformat}
> We have a mirror defined in our pom.xml file:
> {noformat}
>
>
> nexus-public
>
> *,!bwc-nexus-snapshots,!bwc-nexus-artifacts,!bwc-nexus-plugins,!bwc-nexus-3rdParty
>
> http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party/
>
>
> {noformat}
> and it seems that maven 3.0.4 and later are not picking up the artifact from
> "bwc-nexus-artifacts" repo defined in the settings.xml, but it is defaulting
> to the http://nexus.bridgewatersys.com/nexus/content/groups/acb1-third-party
> repo declared in the mirror.
> i attached my pom.xml and settings.xml files, an
[jira] [Created] (MSHARED-596) Support for getting local metadata for RepositoryManager
Guillaume Boué created MSHARED-596:
--
Summary: Support for getting local metadata for RepositoryManager
Key: MSHARED-596
URL: https://issues.apache.org/jira/browse/MSHARED-596
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-artifact-transfer
Reporter: Guillaume Boué
Assignee: Guillaume Boué
Fix For: maven-artifact-transfer-3.0.0
The current RepositoryManager can only get the path to local artifacts, and not
local metadata. The patch attached adds this support, with a new
getPathForLocalMetadata method.
This method delegates to the Maven 3.0 or Maven 3.1 implementation using
Sonatype Aether or Eclipse Aether accordingly. In the special case of
ProjectArtifactMetadata, which isn't a metadata in Aether, this method calls
"getPathForLocalArtifact" by giving it the coordinate of the POM artifact.
I tested this with Maven 3.0.5, 3.3.9 and latest 3.4.0-SNAPSHOT, and it behaves
correctly. Can I have a review of this patch? This addition would allow to
simplify the current {{DefaultProjectInstaller}}, by having a single point of
entry through the {{RepositoryManager}} to set the local repository.
Also, is there a replacement for the deprecated {{ArtifactMetadata}}? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-596) Support for getting local metadata for RepositoryManager
[
https://issues.apache.org/jira/browse/MSHARED-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué updated MSHARED-596:
---
Attachment: MSHARED-596-patch.txt
> Support for getting local metadata for RepositoryManager
>
>
> Key: MSHARED-596
> URL: https://issues.apache.org/jira/browse/MSHARED-596
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: maven-artifact-transfer-3.0.0
>
> Attachments: MSHARED-596-patch.txt
>
>
> The current RepositoryManager can only get the path to local artifacts, and
> not local metadata. The patch attached adds this support, with a new
> getPathForLocalMetadata method.
> This method delegates to the Maven 3.0 or Maven 3.1 implementation using
> Sonatype Aether or Eclipse Aether accordingly. In the special case of
> ProjectArtifactMetadata, which isn't a metadata in Aether, this method calls
> "getPathForLocalArtifact" by giving it the coordinate of the POM artifact.
> I tested this with Maven 3.0.5, 3.3.9 and latest 3.4.0-SNAPSHOT, and it
> behaves correctly. Can I have a review of this patch? This addition would
> allow to simplify the current {{DefaultProjectInstaller}}, by having a single
> point of entry through the {{RepositoryManager}} to set the local repository.
> Also, is there a replacement for the deprecated {{ArtifactMetadata}}? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-4142) Maven doesn't try to download SNAPSHOT artifacts, if you've installed them locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-4142:
Summary: Maven doesn't try to download SNAPSHOT artifacts, if you've
installed them locally (was: Maven doesn't try to download a dependency when
it already exists a version with classifier locally)
> Maven doesn't try to download SNAPSHOT artifacts, if you've installed them
> locally
> --
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4142) Maven doesn't try to download SNAPSHOT artifacts, if you've installed them locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578743#comment-15578743
]
Michael Osipov commented on MNG-4142:
-
First of all, thank you [~carlspring] for the great analysis on the issue:
there is no conneciton to classifiers. I have tested the sample project with
3.0.5, 3.2.5, 3.3.9 and 3.4.0-SNAPSHOT. This issue still persists, now the bad
thing: this issue is not rooted in Maven but in Aether, it rejects to
redownload the snapshot. The root cause is the [update
policy|http://maven.apache.org/ref/3.3.9/maven-settings/settings.html#class_snapshots]
of the remote repository set in the POM. The first check is done
[here|https://github.com/eclipse/aether-core/blob/4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b/aether-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManager.java#L111]
which handles over to
[this|https://github.com/eclipse/aether-core/blob/4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b/aether-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L84].
My questions are:
1. Why are the snapshots arleady in the repo, usecase, state?
2. What is your expected behavior? If the artifact is not yet in the local repo
it has to pulled no matter what?
> Maven doesn't try to download SNAPSHOT artifacts, if you've installed them
> locally
> --
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578777#comment-15578777
]
Christian Schulte commented on MNG-6105:
Should work as well. You need to change the API that way.
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
> at
> org.apache.mav
[jira] [Commented] (MNG-4142) Maven doesn't try to download SNAPSHOT artifacts, if you've installed them locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578882#comment-15578882
]
Stéphane Landelle commented on MNG-4142:
Consider this use case:
* you use a library and you need the bleeding age, so you fetch from this lib's
CI repo
* you notice a bug, so you fork the repo, fix the bug, build and test locally,
so you end up with a local snapshot
* you contribute the fix and it gets merged upstream
* now, you want to go back on depending on the official upstream snapshots,
without having to maintain your local snapshot until the stable release
> Maven doesn't try to download SNAPSHOT artifacts, if you've installed them
> locally
> --
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-4142:
Summary: Maven doesn't try to download a dependency when it already exists
a version with classifier locally (was: Maven doesn't try to download SNAPSHOT
artifacts, if you've installed them locally)
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578899#comment-15578899
]
Michael Osipov commented on MNG-4142:
-
I need to revert my previous statement partially. I have found probably the
issue why this is caused. Initially I thought that this is MNG-4343, but it
isn't. It is the Clover Maven Plugin. First of all, I have updated to 4.1.2 to
reproduce with the attached usecase. The issue is located as well as in the
plugin but also in the sample project configuration. At runtime clover replaces
the main artifact with a classified one. This happens in {{pre-site}} phase.
Unfortunately, the author of the sample project added {{module1}} as a
dependency of {{module2}}, but forgot to add the classifier. If you now run
with added classifier, the stuff works. It can never ever work the way it is
configured now because there is no unclassified main artifact to depend upon
due to Clover plugin.
Upshot: this is a misconfiguration in your POMs.
If some one now still thinks that this will fail even if a main and a side
artifact exist, please create a proper sample project.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578899#comment-15578899
]
Michael Osipov edited comment on MNG-4142 at 10/15/16 11:11 PM:
I need to revert my previous statement partially. I have found probably the
issue why this is caused. Initially I thought that this is MNG-4343, but it
isn't. It is the Clover Maven Plugin. First of all, I have updated to 4.1.2 to
reproduce with the attached usecase. The issue is located as well as in the
plugin but also in the sample project configuration. At runtime [clover
replaces the main artifact with a classified
one|https://docs.atlassian.com/maven-clover2-plugin/latest/xref/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.html#467].
This happens in {{pre-site}} phase. Unfortunately, the author of the sample
project added {{module1}} as a dependency of {{module2}}, but forgot to add the
classifier. If you now run with added classifier, the stuff works. It can never
ever work the way it is configured now because there is no unclassified main
artifact to depend upon due to Clover plugin.
Upshot: this is a misconfiguration in your POMs.
If some one now still thinks that this will fail even if a main and a side
artifact exist, please create a proper sample project.
was (Author: michael-o):
I need to revert my previous statement partially. I have found probably the
issue why this is caused. Initially I thought that this is MNG-4343, but it
isn't. It is the Clover Maven Plugin. First of all, I have updated to 4.1.2 to
reproduce with the attached usecase. The issue is located as well as in the
plugin but also in the sample project configuration. At runtime clover replaces
the main artifact with a classified one. This happens in {{pre-site}} phase.
Unfortunately, the author of the sample project added {{module1}} as a
dependency of {{module2}}, but forgot to add the classifier. If you now run
with added classifier, the stuff works. It can never ever work the way it is
configured now because there is no unclassified main artifact to depend upon
due to Clover plugin.
Upshot: this is a misconfiguration in your POMs.
If some one now still thinks that this will fail even if a main and a side
artifact exist, please create a proper sample project.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
[jira] [Updated] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-4142:
Fix Version/s: (was: Issues to be reviewed for 3.x)
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578902#comment-15578902
]
Michael Osipov commented on MNG-4142:
-
Perfectly fine usecase and I am convinced that this works. See post below.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud HERITIER
>Priority: Critical
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6106) Remove maven.home setter from m2.conf
Michael Osipov created MNG-6106:
---
Summary: Remove maven.home setter from m2.conf
Key: MNG-6106
URL: https://issues.apache.org/jira/browse/MNG-6106
Project: Maven
Issue Type: Task
Components: Bootstrap & Build, core
Affects Versions: 3.3.9
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.4.0
The {{set maven.core default...}} seems to be a relic from ancient times. Even
if it would be used, it wouldn't work because {{user.home}} never contains
Maven's installation files.
This line can safely be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-6106) Remove maven.home setter from m2.conf
[
https://issues.apache.org/jira/browse/MNG-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6106.
---
Resolution: Fixed
Fixed with
[f7c1359cf4e3ed82b91b78688076ff684a4eb9a8|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=f7c1359cf4e3ed82b91b78688076ff684a4eb9a8].
> Remove maven.home setter from m2.conf
> -
>
> Key: MNG-6106
> URL: https://issues.apache.org/jira/browse/MNG-6106
> Project: Maven
> Issue Type: Task
> Components: Bootstrap & Build, core
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
>
> The {{set maven.core default...}} seems to be a relic from ancient times.
> Even if it would be used, it wouldn't work because {{user.home}} never
> contains Maven's installation files.
> This line can safely be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-3655) Allow multiple local repositories
[ https://issues.apache.org/jira/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578924#comment-15578924 ] Michael Osipov commented on MNG-3655: - Use a local Nexus instance to avoid downloading over and over again. > Allow multiple local repositories > - > > Key: MNG-3655 > URL: https://issues.apache.org/jira/browse/MNG-3655 > Project: Maven > Issue Type: New Feature > Components: Reactor and workspace >Reporter: Ittay Dror > Fix For: Issues to be reviewed for 4.x > > > In some environments, branches are rarely used. This means that if a > developer wishes to work in parallel on two features, he checks out HEAD into > two different locations. The problem is that using 'mvn install' in one > checkout will overwrite the result of 'mvn install' in another. Of course one > can write poms so that the version contains some classifier and then use 'mvn > -Dartifact-classifier=first-checkout install', or, read from a file. Both are > tedious. > Instead, it would be good to be able to tell maven to first consider some > path under the checkout before trying a global local repository (for external > artifacts). > To make this work when running mvn from a module subdir, maybe allow to write > settings.xml in the root directory of the checkout. Then, maven should climb > the directory structure until locating settings.xml (or reaching the global > root directory) and read there. Using settings.xml in such a way has other > benefits that it can be under version control. settings.xml will then be able > to specify a list of local repositories, some absolute paths, some relative > to it. > Another approach could be to allow this list of local repositories in the > global settings.xml file and have an entry in each module's pom indicating > where it is relative to the local repository (like the parent path attribute) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6106) Remove maven.home setter from m2.conf
[
https://issues.apache.org/jira/browse/MNG-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578936#comment-15578936
]
Hudson commented on MNG-6106:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1397 (See
[https://builds.apache.org/job/maven-3.x/1397/])
[MNG-6106] Remove maven.home setter from m2.conf (michaelo: rev
f7c1359cf4e3ed82b91b78688076ff684a4eb9a8)
* (edit) apache-maven/src/bin/m2.conf
> Remove maven.home setter from m2.conf
> -
>
> Key: MNG-6106
> URL: https://issues.apache.org/jira/browse/MNG-6106
> Project: Maven
> Issue Type: Task
> Components: Bootstrap & Build, core
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
>
> The {{set maven.core default...}} seems to be a relic from ancient times.
> Even if it would be used, it wouldn't work because {{user.home}} never
> contains Maven's installation files.
> This line can safely be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5950) Only first active proxy considered
[ https://issues.apache.org/jira/browse/MNG-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5950. --- Resolution: Incomplete no information given after a long period. > Only first active proxy considered > -- > > Key: MNG-5950 > URL: https://issues.apache.org/jira/browse/MNG-5950 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.0.5 > Environment: windows 7 ,jdk 1.8 >Reporter: Jiahongchao > > only http proxy or https proxy can be used at the same time,however,only one > proxy should be used for both http and https -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5318) mvn.bat fail on TTC/LE when -Dkey=value parameters are not quoted
[ https://issues.apache.org/jira/browse/MNG-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5318. --- Resolution: Not A Problem The startup scripts have been completely rewritten. You patch/usecase does not apply anymore. If this issue still persists, provide a usecase for 3.3.9. > mvn.bat fail on TTC/LE when -Dkey=value parameters are not quoted > - > > Key: MNG-5318 > URL: https://issues.apache.org/jira/browse/MNG-5318 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.0.4 > Environment: windows-7, tccle.ex >Reporter: zart colwing > Attachments: mvn_bat.patch, mvn_bat.patch > > > When the mvn command contains an unquoted -Dkey=value parameter then mvn fail > with a: > [ERROR] Unknown lifecycle phase "". You must specify a valid lifecycle > phase or a goal in the format : or... > The problem is that the bat file execute: > set MAVEN_CMD_LINE_ARGS=%$ (on line 129) > instead of > set MAVEN_CMD_LINE_ARGS=%* (on line 124) > when it detect TCC/LE (on line 121) > from http://www.robvanderwoude.com/parameters.php > %$ replace '=' by space unless they are part of a string in doublequotes. > %* will leave all delimiters intact > A possible fix is to use %* in both case. > Another possible fix is to remove (or comment out) the TCC/LE detection on > line 121 and let the script fall-through to the "Regular WinNT" case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-6091) Failing on upload of some artifacts.
[ https://issues.apache.org/jira/browse/MNG-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6091. --- Resolution: Invalid This is not a support forum. Seek help on the users mailing list or Stackoverflow. > Failing on upload of some artifacts. > > > Key: MNG-6091 > URL: https://issues.apache.org/jira/browse/MNG-6091 > Project: Maven > Issue Type: Bug >Reporter: Mariana Ciumac > > When I run "mvn deploy" to upload the artifact to Nexus repository (locally) > sometimes the command is success and sometimes it fails the exception is > below. In caseof failure some of the files are uploaded and some most of > the time jar file it is not, but sometimes jar is uploaded but pom file does > not. > I tried to find the pattern, but there is no partten that I can see, it is > random. > I contacted Nexus and from their log they are saying that there is no error > in their logs. What they see is that for the file that is failed to upload > the request does not come back when challenged with 401 response, while the > requests for other files comes back with credentials. Let me know if you need > more info. > Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on > project service-security: Failed to deploy artifacts: Could not transfer > artifact com.brick:service-security:jar:2.4-20160916.144123-22 from/to > maven-snapshots (http://localhost:8083/repository/maven-snapshots/): Remotely > Closed [id: 0xcb3e29be, /127.0.0.1:57273 :> localhost/127.0.0.1:8083] -> > [Help 1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6064) Add "dev" string item into ComparableVersion
[
https://issues.apache.org/jira/browse/MNG-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578955#comment-15578955
]
Michael Osipov commented on MNG-6064:
-
I absolutely do not see a difference between {{dev}} and {{SNAPSHOT}}. Can
someone enlighten me?
> Add "dev" string item into ComparableVersion
>
>
> Key: MNG-6064
> URL: https://issues.apache.org/jira/browse/MNG-6064
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
> Environment: Any operating Systems
>Reporter: Hui Wang
>Priority: Minor
> Labels: maven
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We're using a popular Gradle plugin "gradle-git" ( from Andrew Oberstar ) to
> implement Semantic Versioning with Continuous Deployment. There's a strategy
> supported by gradle-git that defines a "dev" stage when we have something
> uncommitted on a developer branch, which is very useful. Some examples to
> demonstrate the "dev" scenario can be found here:
> https://github.com/ajoberstar/gradle-git/wiki/Release%20Plugins#how-do-i-use-the-opinion-plugin
> However, current version of
> org.apache.maven.artifact.versioning.ComparableVersion does not support "dev"
> stage since there's no item "dev" in the field _QUALIFIERS of nested class
> StringItem. And since this is a private static final field, it is not able to
> be overwritten by inheritance. Can we add the "dev" item into _QUALIFIERS ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5860) Maven ${id} property leaking into other build tool
[
https://issues.apache.org/jira/browse/MNG-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5860:
Labels: sample-project-missing (was: )
> Maven ${id} property leaking into other build tool
> --
>
> Key: MNG-5860
> URL: https://issues.apache.org/jira/browse/MNG-5860
> Project: Maven
> Issue Type: Question
> Components: Errors
>Affects Versions: 3.0.5
> Environment: Windows 7
>Reporter: Shaun Parry
>Priority: Minor
> Labels: sample-project-missing
>
> There seems to be a problem that, occasionally, the ${id} property seems to
> be leaking across from Maven into a Dojo build, run through maven-antrun. The
> details are on stackoverflow:
> http://stackoverflow.com/questions/31387310/dojo-build-shrinksafe-using-maven-project-id-in-embedded-html
> It doesn't always happen, but we've recently changed our repository setting
> to change the EOL characters to CRLF on commit. Has anyone come across this
> problem and found a solution
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5860) Maven ${id} property leaking into other build tool
[
https://issues.apache.org/jira/browse/MNG-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578958#comment-15578958
]
Michael Osipov commented on MNG-5860:
-
Please provide a sample project.
> Maven ${id} property leaking into other build tool
> --
>
> Key: MNG-5860
> URL: https://issues.apache.org/jira/browse/MNG-5860
> Project: Maven
> Issue Type: Question
> Components: Errors
>Affects Versions: 3.0.5
> Environment: Windows 7
>Reporter: Shaun Parry
>Priority: Minor
> Labels: sample-project-missing
>
> There seems to be a problem that, occasionally, the ${id} property seems to
> be leaking across from Maven into a Dojo build, run through maven-antrun. The
> details are on stackoverflow:
> http://stackoverflow.com/questions/31387310/dojo-build-shrinksafe-using-maven-project-id-in-embedded-html
> It doesn't always happen, but we've recently changed our repository setting
> to change the EOL characters to CRLF on commit. Has anyone come across this
> problem and found a solution
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5825) Command line fails if jvm.config and MAVEN_OPTS has duplicates
[ https://issues.apache.org/jira/browse/MNG-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5825: Description: MNG-5790 introduced jvm.config (+1) but how it currently handles MAVEN_OPTS and jvm.config is quite simple, in that it just concats the two values together. The problem being, if you have: export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m" jvm.config = -Xmx2048m -Xms2048m -XX:MaxPermSize=512m -Djava.awt.headless=true You get a Java issue: localhost:project garethah$ mvn clean install Error occurred during initialization of VM Incompatible minimum and maximum heap sizes specified Do to the fact that the command line has multiple options for the same JVM option. Can this be improved, so it takes the higher of the values? was: MNG-5790 introduced jvm.config (+1) but how it currently handles MAVEN_OPTS and jvm.config is quite simple, in that it just concats the two values together. The problem being, if you have: export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m" jvm.config = -Xmx2048m -Xms2048m -XX:MaxPermSize=512m -Djava.awt.headless=true You get a JAVA issue: localhost:project garethah$ mvn clean install Error occurred during initialization of VM Incompatible minimum and maximum heap sizes specified Do to the fact that the command line has multiple options for the same JVM option. Can this be improved, so it takes the higher of the values? > Command line fails if jvm.config and MAVEN_OPTS has duplicates > -- > > Key: MNG-5825 > URL: https://issues.apache.org/jira/browse/MNG-5825 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.3 >Reporter: Gareth Healy >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > MNG-5790 introduced jvm.config (+1) but how it currently handles MAVEN_OPTS > and jvm.config is quite simple, in that it just concats the two values > together. > The problem being, if you have: > export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m" > jvm.config = -Xmx2048m -Xms2048m -XX:MaxPermSize=512m -Djava.awt.headless=true > You get a Java issue: > localhost:project garethah$ mvn clean install > Error occurred during initialization of VM > Incompatible minimum and maximum heap sizes specified > Do to the fact that the command line has multiple options for the same JVM > option. > Can this be improved, so it takes the higher of the values? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578964#comment-15578964
]
Hudson commented on MNG-6105:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1398 (See
[https://builds.apache.org/job/maven-3.x/1398/])
[MNG-6105] properties.internal.SystemProperties.addSystemProperties() is
(gboue: rev ace448158131285e5ef8fb54b96dfb3d8d05f37e)
* (edit)
maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuildingRequest.java
* (edit)
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingRequest.java
* (edit)
maven-settings-builder/src/main/java/org/apache/maven/settings/building/DefaultSettingsBuildingRequest.java
* (edit)
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
* (edit)
maven-core/src/main/java/org/apache/maven/properties/internal/SystemProperties.java
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 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:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.
[jira] [Commented] (MNGSITE-261) .htaccess file forces http: for several redirects
[ https://issues.apache.org/jira/browse/MNGSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15579175#comment-15579175 ] Hervé Boutemy commented on MNGSITE-261: --- cool, the .htaccess can then be simplified and be more consistent > .htaccess file forces http: for several redirects > - > > Key: MNGSITE-261 > URL: https://issues.apache.org/jira/browse/MNGSITE-261 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Sebb >Assignee: Michael Osipov > > The Maven site .htaccess file [1] has a lot of Redirect entries that force > the use of http: even for URLs that were originally https: > That seems wrong; the redirect should use the same scheme as the original URL. > [1] > https://svn-master.apache.org/repos/infra/websites/production/maven/content/.htaccess -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-782) Support for custom Velocity tools has disappeared
[ https://issues.apache.org/jira/browse/MSITE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSITE-782. --- Resolution: Fixed IT updated thank you > Support for custom Velocity tools has disappeared > - > > Key: MSITE-782 > URL: https://issues.apache.org/jira/browse/MSITE-782 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.5, 3.5.1 >Reporter: Bernardo >Assignee: Michael Osipov > Fix For: 3.6 > > > Since the version 3.5 any skin using custom velocity tools is no longer > working. > This can be seen on the Reflow maven skin, and also on my own skin, which was > developed from the Reflow one. > The Reflow skin, along its Velocity tools, can be found here: > https://github.com/andriusvelykis/reflow-maven-skin > My Maven skin can be found here: > https://github.com/Bernardo-MG/docs-maven-skin > My custom velocity tools: > https://github.com/Bernardo-MG/maven-site-fixer > All these projects are available through Maven central, making them easy to > test. > To see this problem just use the Reflow skin, which won't print the content > of any page. In the case of my own skin, there will be several errors in the > HTML code, the most visible being the broken headers. > It may be actually a Doxia problem, related to this issue: > https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Additionally, there is a related link commenting this problem: > http://maven.40175.n5.nabble.com/New-maven-site-and-doxia-with-custom-velocity-doxia-td5865376.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
