[jira] [Updated] (MPMD-304) maven-pmd-plugin should be toolchains-aware
[ https://issues.apache.org/jira/browse/MPMD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated MPMD-304: Description: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. The switch is handled using toolchains.xml. PMD seemingly cannot cope with 11 code when maven is running under 1.8. We are forced to set `pmd.typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. These false errors do not occur when maven itself runs under JDK 11, with `pmd.typeResolution=true`. was: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when maven is running under 1.8. We are forced to set `pmd.typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. These false errors do not occur when maven itself runs under JDK 11, with `pmd.typeResolution=true`. > maven-pmd-plugin should be toolchains-aware > --- > > Key: MPMD-304 > URL: https://issues.apache.org/jira/browse/MPMD-304 > Project: Maven PMD Plugin > Issue Type: Bug >Affects Versions: 3.13.0 > Environment: maven 3.6.3 > JDK 1.8 (maven) > JDK 11 (toolchains.xml) >Reporter: Ed Randall >Priority: Major > > maven-pmd-plugin should be > [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] > and pick up the correct JDK used for compilation. If toolchains is in use, > it should select that one, not use the same JDK that maven is running. > > We have an enterprise build system which runs maven under JDK 1.8. Some > projects target 1.8, others target 11. The switch is handled using > toolchains.xml. > PMD seemingly cannot cope with 11 code when maven is running under 1.8. We > are forced to set `pmd.typeResolution=false` to avoid all sorts of strange > errors (eg. 'unused private method' despite it being used 28 times in the > same class). > We do have `targetJdk=11`. > These false errors do not occur when maven itself runs under JDK 11, with > `pmd.typeResolution=true`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPMD-304) maven-pmd-plugin should be toolchains-aware
[ https://issues.apache.org/jira/browse/MPMD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated MPMD-304: Description: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when maven is running under 1.8. We are forced to set `pmd.typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. These false errors do not occur when maven itself runs under JDK 11, with `pmd.typeResolution=true`. was: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when it's running under 8. We are forced to set `pmd.typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. These false errors do not occur when maven itself runs under JDK 11, with `pmd.typeResolution=true`. > maven-pmd-plugin should be toolchains-aware > --- > > Key: MPMD-304 > URL: https://issues.apache.org/jira/browse/MPMD-304 > Project: Maven PMD Plugin > Issue Type: Bug >Affects Versions: 3.13.0 > Environment: maven 3.6.3 > JDK 1.8 (maven) > JDK 11 (toolchains.xml) >Reporter: Ed Randall >Priority: Major > > maven-pmd-plugin should be > [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] > and pick up the correct JDK used for compilation. If toolchains is in use, > it should select that one, not use the same JDK that maven is running. > > We have an enterprise build system which runs maven under JDK 1.8. Some > projects target 1.8, others target 11. > PMD seemingly cannot cope with 11 code when maven is running under 1.8. We > are forced to set `pmd.typeResolution=false` to avoid all sorts of strange > errors (eg. 'unused private method' despite it being used 28 times in the > same class). > We do have `targetJdk=11`. > These false errors do not occur when maven itself runs under JDK 11, with > `pmd.typeResolution=true`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPMD-304) maven-pmd-plugin should be toolchains-aware
[ https://issues.apache.org/jira/browse/MPMD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated MPMD-304: Description: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when it's running under 8. We are forced to set `pmd.typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. These false errors do not occur when maven itself runs under JDK 11, with `pmd.typeResolution=true`. was: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when it's running under 8. We are forced to set `typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. > maven-pmd-plugin should be toolchains-aware > --- > > Key: MPMD-304 > URL: https://issues.apache.org/jira/browse/MPMD-304 > Project: Maven PMD Plugin > Issue Type: Bug >Affects Versions: 3.13.0 > Environment: maven 3.6.3 > JDK 1.8 (maven) > JDK 11 (toolchains.xml) >Reporter: Ed Randall >Priority: Major > > maven-pmd-plugin should be > [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] > and pick up the correct JDK used for compilation. If toolchains is in use, > it should select that one, not use the same JDK that maven is running. > > We have an enterprise build system which runs maven under JDK 1.8. Some > projects target 1.8, others target 11. > PMD seemingly cannot cope with 11 code when it's running under 8. We are > forced to set `pmd.typeResolution=false` to avoid all sorts of strange errors > (eg. 'unused private method' despite it being used 28 times in the same > class). > We do have `targetJdk=11`. > These false errors do not occur when maven itself runs under JDK 11, with > `pmd.typeResolution=true`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPMD-304) maven-pmd-plugin should be toolchains-aware
[ https://issues.apache.org/jira/browse/MPMD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated MPMD-304: Description: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which runs maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when it's running under 8. We are forced to set `typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. was: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which run maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when it's running under 8. We are forced to set `typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. > maven-pmd-plugin should be toolchains-aware > --- > > Key: MPMD-304 > URL: https://issues.apache.org/jira/browse/MPMD-304 > Project: Maven PMD Plugin > Issue Type: Bug >Affects Versions: 3.13.0 > Environment: maven 3.6.3 > JDK 1.8 (maven) > JDK 11 (toolchains.xml) >Reporter: Ed Randall >Priority: Major > > maven-pmd-plugin should be > [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] > and pick up the correct JDK used for compilation. If toolchains is in use, > it should select that one, not use the same JDK that maven is running. > > We have an enterprise build system which runs maven under JDK 1.8. Some > projects target 1.8, others target 11. > PMD seemingly cannot cope with 11 code when it's running under 8. We are > forced to set `typeResolution=false` to avoid all sorts of strange errors > (eg. 'unused private method' despite it being used 28 times in the same > class). > We do have `targetJdk=11`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPMD-304) maven-pmd-plugin should be toolchains-aware
[ https://issues.apache.org/jira/browse/MPMD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated MPMD-304: Description: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system which run maven under JDK 1.8. Some projects target 1.8, others target 11. PMD seemingly cannot cope with 11 code when it's running under 8. We are forced to set `typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). We do have `targetJdk=11`. was: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system when maven runs under JDK 1.8. Some projects target 1.8, others target 11. PMD cannot cope with 11 code when it's running under 8. We are forced to set `typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). > maven-pmd-plugin should be toolchains-aware > --- > > Key: MPMD-304 > URL: https://issues.apache.org/jira/browse/MPMD-304 > Project: Maven PMD Plugin > Issue Type: Bug >Affects Versions: 3.13.0 > Environment: maven 3.6.3 > JDK 1.8 (maven) > JDK 11 (toolchains.xml) >Reporter: Ed Randall >Priority: Major > > maven-pmd-plugin should be > [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] > and pick up the correct JDK used for compilation. If toolchains is in use, > it should select that one, not use the same JDK that maven is running. > > We have an enterprise build system which run maven under JDK 1.8. Some > projects target 1.8, others target 11. > PMD seemingly cannot cope with 11 code when it's running under 8. We are > forced to set `typeResolution=false` to avoid all sorts of strange errors > (eg. 'unused private method' despite it being used 28 times in the same > class). > We do have `targetJdk=11`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MPMD-304) maven-pmd-plugin should be toolchains-aware
Ed Randall created MPMD-304: --- Summary: maven-pmd-plugin should be toolchains-aware Key: MPMD-304 URL: https://issues.apache.org/jira/browse/MPMD-304 Project: Maven PMD Plugin Issue Type: Bug Affects Versions: 3.13.0 Environment: maven 3.6.3 JDK 1.8 (maven) JDK 11 (toolchains.xml) Reporter: Ed Randall maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system when maven runs under JDK 1.8. Some projects target 1.8, others target 11. PMD cannot cope with 11 code when it's running under 8. We are forced to set `typeResolution=false` to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MPMD-39) Target JDK should default to configuration of the compiler plugin
[ https://issues.apache.org/jira/browse/MPMD-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143010#comment-17143010 ] Ed Randall edited comment on MPMD-39 at 6/23/20, 2:54 PM: -- maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system when maven runs under JDK 1.8. Some projects target 1.8, others target 11. PMD cannot cope with 11 code when it's running under 8 and when the target is 11, we are forced to set typeResolution=false, to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). was (Author: edrandall): maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should not use the same JDK that maven is running. We have an enterprise build system when maven runs under JDK 1.8. Some projects target 1.8, others target 11. PMD cannot cope with 11 code when it's running under 8 and when the target is 11, we are forced to set typeResolution=false, to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). > Target JDK should default to configuration of the compiler plugin > - > > Key: MPMD-39 > URL: https://issues.apache.org/jira/browse/MPMD-39 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Eric Bernstein >Assignee: Dennis Lundberg >Priority: Major > > It seems unnecessary to configure the target jdk twice; once for the > compiler, and once for pmd. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MPMD-39) Target JDK should default to configuration of the compiler plugin
[ https://issues.apache.org/jira/browse/MPMD-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated MPMD-39: --- Comment: was deleted (was: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should select that one, not use the same JDK that maven is running. We have an enterprise build system when maven runs under JDK 1.8. Some projects target 1.8, others target 11. PMD cannot cope with 11 code when it's running under 8 and when the target is 11, we are forced to set typeResolution=false, to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class).) > Target JDK should default to configuration of the compiler plugin > - > > Key: MPMD-39 > URL: https://issues.apache.org/jira/browse/MPMD-39 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Eric Bernstein >Assignee: Dennis Lundberg >Priority: Major > > It seems unnecessary to configure the target jdk twice; once for the > compiler, and once for pmd. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPMD-39) Target JDK should default to configuration of the compiler plugin
[ https://issues.apache.org/jira/browse/MPMD-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143010#comment-17143010 ] Ed Randall commented on MPMD-39: maven-pmd-plugin should be [toolchains-aware|https://maven.apache.org/guides/mini/guide-using-toolchains.html] and pick up the correct JDK used for compilation. If toolchains is in use, it should not use the same JDK that maven is running. We have an enterprise build system when maven runs under JDK 1.8. Some projects target 1.8, others target 11. PMD cannot cope with 11 code when it's running under 8 and when the target is 11, we are forced to set typeResolution=false, to avoid all sorts of strange errors (eg. 'unused private method' despite it being used 28 times in the same class). > Target JDK should default to configuration of the compiler plugin > - > > Key: MPMD-39 > URL: https://issues.apache.org/jira/browse/MPMD-39 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Eric Bernstein >Assignee: Dennis Lundberg >Priority: Major > > It seems unnecessary to configure the target jdk twice; once for the > compiler, and once for pmd. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MTOOLCHAINS-31) Not threadsafe for parallel execution
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128983#comment-17128983
]
Ed Randall edited comment on MTOOLCHAINS-31 at 6/9/20, 8:42 AM:
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in my-project-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
Goal is: {{maven-toolchains-plugin:3.0.0:toolchain (default)}}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, solution could be as simple as adding the {{@threadsafe}} annotation.
was (Author: edrandall):
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in my-project-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, solution could be as simple as adding the {{@threadsafe}} annotation.
> Not threadsafe for parallel execution
> -
>
> Key: MTOOLCHAINS-31
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-31
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: maven 3.6.1
>Reporter: Hüseyin Kartal
>Priority: Major
>
> Running maven in parallel mode result in following output which also includes
> TOOLCHAINS plugin.
> {noformat}
> *
> * Your build is requesting parallel execution, but project *
> * contains the following plugin(s) that have goals not marked *
> * as @threadSafe to support parallel building. *
> * While this /may/ work fine, please look for plugin updates*
> * and/or request plugins be made thread-safe. *
> * If reporting an issue, report it against the plugin in*
> * question, not against maven-core *
> *
> The following plugins are not marked @threadSafe in Application component:
> core:
> com.sun.xml.ws:jaxws-maven-plugin:2.3.2
> org.apache.maven.plugins:maven-jxr-plugin:3.0.0
> org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
> Enable debug to see more precisely which goals are not marked @threadSafe.
> *{noformat}
> Toolchains plugin should made and/or marked threadSafe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MTOOLCHAINS-31) Not threadsafe for parallel execution
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128983#comment-17128983
]
Ed Randall edited comment on MTOOLCHAINS-31 at 6/9/20, 8:38 AM:
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in my-project-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, solution could be as simple as adding the {{@threadsafe}} annotation.
was (Author: edrandall):
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in cloud-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, solution could be as simple as adding the {{@threadsafe}} annotation.
> Not threadsafe for parallel execution
> -
>
> Key: MTOOLCHAINS-31
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-31
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: maven 3.6.1
>Reporter: Hüseyin Kartal
>Priority: Major
>
> Running maven in parallel mode result in following output which also includes
> TOOLCHAINS plugin.
> {noformat}
> *
> * Your build is requesting parallel execution, but project *
> * contains the following plugin(s) that have goals not marked *
> * as @threadSafe to support parallel building. *
> * While this /may/ work fine, please look for plugin updates*
> * and/or request plugins be made thread-safe. *
> * If reporting an issue, report it against the plugin in*
> * question, not against maven-core *
> *
> The following plugins are not marked @threadSafe in Application component:
> core:
> com.sun.xml.ws:jaxws-maven-plugin:2.3.2
> org.apache.maven.plugins:maven-jxr-plugin:3.0.0
> org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
> Enable debug to see more precisely which goals are not marked @threadSafe.
> *{noformat}
> Toolchains plugin should made and/or marked threadSafe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MTOOLCHAINS-31) Not threadsafe for parallel execution
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128983#comment-17128983
]
Ed Randall edited comment on MTOOLCHAINS-31 at 6/9/20, 8:38 AM:
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in cloud-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, solution could be as simple as adding the {{@threadsafe}} annotation.
was (Author: edrandall):
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in cloud-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, it might be as simple as adding the {{@threadsafe}} annotation.
> Not threadsafe for parallel execution
> -
>
> Key: MTOOLCHAINS-31
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-31
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: maven 3.6.1
>Reporter: Hüseyin Kartal
>Priority: Major
>
> Running maven in parallel mode result in following output which also includes
> TOOLCHAINS plugin.
> {noformat}
> *
> * Your build is requesting parallel execution, but project *
> * contains the following plugin(s) that have goals not marked *
> * as @threadSafe to support parallel building. *
> * While this /may/ work fine, please look for plugin updates*
> * and/or request plugins be made thread-safe. *
> * If reporting an issue, report it against the plugin in*
> * question, not against maven-core *
> *
> The following plugins are not marked @threadSafe in Application component:
> core:
> com.sun.xml.ws:jaxws-maven-plugin:2.3.2
> org.apache.maven.plugins:maven-jxr-plugin:3.0.0
> org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
> Enable debug to see more precisely which goals are not marked @threadSafe.
> *{noformat}
> Toolchains plugin should made and/or marked threadSafe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MTOOLCHAINS-31) Not threadsafe for parallel execution
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128983#comment-17128983
]
Ed Randall edited comment on MTOOLCHAINS-31 at 6/9/20, 8:37 AM:
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{noformat}
07:57:54.243 [BuilderThread 0] [WARNING]
*
07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not marked
@threadSafe in cloud-build:
07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.
07:57:54.247 [BuilderThread 0] [WARNING]
*
{noformat}
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, it might be as simple as adding the {{@threadsafe}} annotation.
was (Author: edrandall):
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{{07:57:54.243 [BuilderThread 0] [WARNING]
*}}
{{ 07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not
marked @threadSafe in your-project-build:}}
{{ 07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0}}
{{ 07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.}}
{{ 07:57:54.247 [BuilderThread 0] [WARNING]
*}}
This is a pretty fundamental plugin for any build pipeline in 2020, the
warning is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, it might be as simple as adding the {{@threadsafe}} annotation.
> Not threadsafe for parallel execution
> -
>
> Key: MTOOLCHAINS-31
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-31
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: maven 3.6.1
>Reporter: Hüseyin Kartal
>Priority: Major
>
> Running maven in parallel mode result in following output which also includes
> TOOLCHAINS plugin.
> {noformat}
> *
> * Your build is requesting parallel execution, but project *
> * contains the following plugin(s) that have goals not marked *
> * as @threadSafe to support parallel building. *
> * While this /may/ work fine, please look for plugin updates*
> * and/or request plugins be made thread-safe. *
> * If reporting an issue, report it against the plugin in*
> * question, not against maven-core *
> *
> The following plugins are not marked @threadSafe in Application component:
> core:
> com.sun.xml.ws:jaxws-maven-plugin:2.3.2
> org.apache.maven.plugins:maven-jxr-plugin:3.0.0
> org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
> Enable debug to see more precisely which goals are not marked @threadSafe.
> *{noformat}
> Toolchains plugin should made and/or marked threadSafe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MTOOLCHAINS-31) Not threadsafe for parallel execution
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128983#comment-17128983
]
Ed Randall edited comment on MTOOLCHAINS-31 at 6/9/20, 8:09 AM:
Note that only maven-toolchains-plugin is of concern here, not the other 2
plugins listed in the description:
{{07:57:54.243 [BuilderThread 0] [WARNING]
*}}
{{ 07:57:54.245 [BuilderThread 0] [WARNING] The following plugins are not
marked @threadSafe in your-project-build:}}
{{ 07:57:54.246 [BuilderThread 0] [WARNING]
org.apache.maven.plugins:maven-toolchains-plugin:3.0.0}}
{{ 07:57:54.247 [BuilderThread 0] [WARNING] Enable debug to see more precisely
which goals are not marked @threadSafe.}}
{{ 07:57:54.247 [BuilderThread 0] [WARNING]
*}}
This is a pretty fundamental plugin for any build pipeline in 2020, the
warning is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, it might be as simple as adding the {{@threadsafe}} annotation.
was (Author: edrandall):
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, it might be as simple as adding the {{@threadsafe}} annotation.
> Not threadsafe for parallel execution
> -
>
> Key: MTOOLCHAINS-31
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-31
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: maven 3.6.1
>Reporter: Hüseyin Kartal
>Priority: Major
>
> Running maven in parallel mode result in following output which also includes
> TOOLCHAINS plugin.
> {noformat}
> *
> * Your build is requesting parallel execution, but project *
> * contains the following plugin(s) that have goals not marked *
> * as @threadSafe to support parallel building. *
> * While this /may/ work fine, please look for plugin updates*
> * and/or request plugins be made thread-safe. *
> * If reporting an issue, report it against the plugin in*
> * question, not against maven-core *
> *
> The following plugins are not marked @threadSafe in Application component:
> core:
> com.sun.xml.ws:jaxws-maven-plugin:2.3.2
> org.apache.maven.plugins:maven-jxr-plugin:3.0.0
> org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
> Enable debug to see more precisely which goals are not marked @threadSafe.
> *{noformat}
> Toolchains plugin should made and/or marked threadSafe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MTOOLCHAINS-31) Not threadsafe for parallel execution
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128983#comment-17128983
]
Ed Randall commented on MTOOLCHAINS-31:
---
This is a pretty fundamental plugin for any build pipeline in 2020, the warning
is quite alarming.
We havn't noticed any particular problems around it using --threads so I'm
guessing it might even be false.
It would be really handy if this could be analyzed and addressed in the next
release, it might be as simple as adding the {{@threadsafe}} annotation.
> Not threadsafe for parallel execution
> -
>
> Key: MTOOLCHAINS-31
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-31
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
> Environment: maven 3.6.1
>Reporter: Hüseyin Kartal
>Priority: Major
>
> Running maven in parallel mode result in following output which also includes
> TOOLCHAINS plugin.
> {noformat}
> *
> * Your build is requesting parallel execution, but project *
> * contains the following plugin(s) that have goals not marked *
> * as @threadSafe to support parallel building. *
> * While this /may/ work fine, please look for plugin updates*
> * and/or request plugins be made thread-safe. *
> * If reporting an issue, report it against the plugin in*
> * question, not against maven-core *
> *
> The following plugins are not marked @threadSafe in Application component:
> core:
> com.sun.xml.ws:jaxws-maven-plugin:2.3.2
> org.apache.maven.plugins:maven-jxr-plugin:3.0.0
> org.apache.maven.plugins:maven-toolchains-plugin:3.0.0
> Enable debug to see more precisely which goals are not marked @threadSafe.
> *{noformat}
> Toolchains plugin should made and/or marked threadSafe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 12:09 PM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present. And there's also the [relocation
mechanism|https://maven.apache.org/guides/mini/guide-encryption.html].
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Stalling this long-awaited feature on grounds of security becomes rather moot,
this is just a usability convenience.
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present. And there's also the [relocation
mechanism|https://maven.apache.org/guides/mini/guide-encryption.html].
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
Stalling this long-awaited feature on grounds of security becomes rather moot,
this is just a usability convenience.
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 12:08 PM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present. And there's also the [relocation
mechanism|https://maven.apache.org/guides/mini/guide-encryption.html].
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
Stalling this long-awaited feature on grounds of security becomes rather moot,
this is just a usability convenience.
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present. And there's also the [relocation
mechanism|https://maven.apache.org/guides/mini/guide-encryption.html].
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
Stalling this must-awaited feature on grounds of security becomes rather moot,
this is just a usability convenience.
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 12:08 PM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present. And there's also the [relocation
mechanism|https://maven.apache.org/guides/mini/guide-encryption.html].
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
Stalling this must-awaited feature on grounds of security becomes rather moot,
this is just a usability convenience.
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 11:57 AM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(accessible by CI user only).
This would allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 11:57 AM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be permitted to view settings.xml whilst storing
settings-security.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(maybe separate filesystem, hidden/accessible by CI user only). This would
allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 11:56 AM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become _less_ secure if we are forced to keep settings.xml
and settings-security.xml in the same directory (even if permissions are
tightened).
We would like the ability to keep them separate in different locations so the
permissions on settings-security.xml can be locked down rather more tightly
(accessible by CI user only).
This would allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become less secure if we are forced to keep settings.xml
and settings-security.xml in the same directory. We would like the ability to
keep them separate in different locations so the permissions on
settings-security.xml can be locked down rather more tightly (accessible by CI
user only).
This would allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall edited comment on MNG-5438 at 1/22/20 11:55 AM:
---
MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so
any security breach is already present.
The system actually become less secure if we are forced to keep settings.xml
and settings-security.xml in the same directory. We would like the ability to
keep them separate in different locations so the permissions on
settings-security.xml can be locked down rather more tightly (accessible by CI
user only).
This would allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
was (Author: edrandall):
MNG-4853 already gave us -Dsettings.security=path/to/security-settings.xml, so
any security breach is already present.
The system actually become less secure if we are forced to keep settings.xml
and security-settings.xml in the same directory. We would like the ability to
keep them separate in different locations so the permissions on
security-settings.xml can be locked down rather more tightly (accessible by CI
user only).
This would allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5438) cli parameter to use a custom path settings-security.xml
[
https://issues.apache.org/jira/browse/MNG-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020981#comment-17020981
]
Ed Randall commented on MNG-5438:
-
MNG-4853 already gave us -Dsettings.security=path/to/security-settings.xml, so
any security breach is already present.
The system actually become less secure if we are forced to keep settings.xml
and security-settings.xml in the same directory. We would like the ability to
keep them separate in different locations so the permissions on
security-settings.xml can be locked down rather more tightly (accessible by CI
user only).
This would allow developers to be allowed to view settings.xml whilst storing
security-settings.xml safely out of the way.
Even then, anyone wanting to see the passwords in the clear can always run this
job on the CI system:
{{mvn help:effective-settings -DshowPasswords=true}}
> cli parameter to use a custom path settings-security.xml
>
>
> Key: MNG-5438
> URL: https://issues.apache.org/jira/browse/MNG-5438
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.4, 3.0.5
>Reporter: Sarah Haselbauer
>Priority: Major
> Fix For: 3.7.0-candidate, 3.x / Backlog
>
> Attachments: MNG-5438-maven-embedder.patch,
> apache-maven-3.0.4-ssec-bin.tar.gz, apache-maven-3.0.4-ssec-bin.zip,
> maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch,
> maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch
>
>
> added -ssec as cli param, so that you have the same flexibility to place your
> settings-security.xml as you have to point to a custom settings.xml file
> mvn -s /path/to/my/custom/settings.xml -ssec
> /path/to/my/custom/settings-security.xml
> I attached to patches: one that can be run on the maven-3.0.4 tag and one
> that can be run on trunk (latest code state of today).
> I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the
> feature and test it yourself.
> if you like the idea, I would welcome to have this feature merged into one of
> the next releases. I need it to write a puppet-maven module that allows to
> download artifacts from maven repositories with encrypted passwords in the
> puppet recipe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062296#comment-16062296
]
Ed Randall edited comment on MCHECKSTYLE-287 at 6/25/17 4:47 PM:
-
Updated [^mcheckstyle-287-demo.tgz] with parent pom reference removed from
csrules submodule.
This now works correctly with a clean cache & reproduces the NPE with maven
3.3.9 and 3.5.0.
$ mvn -e clean install site
was (Author: edrandall):
Updated [^mcheckstyle-287-demo.tgz] with parent pom reference removed from
csrules submodule.
This now works with
$ mvn -e clean install site
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
>
[jira] [Comment Edited] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062296#comment-16062296
]
Ed Randall edited comment on MCHECKSTYLE-287 at 6/25/17 11:51 AM:
--
Updated [^mcheckstyle-287-demo.tgz] with parent pom reference removed from
csrules submodule.
This now works with
$ mvn -e clean install site
was (Author: edrandall):
Updated with parent pom reference removed from csrules submodule.
This now works with
$ mvn -e clean install site
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
>
[jira] [Updated] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Randall updated MCHECKSTYLE-287:
---
Attachment: mcheckstyle-287-demo.tgz
Updated with parent pom reference removed from csrules submodule.
This now works with
$ mvn -e clean install site
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> ...
[jira] [Updated] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Randall updated MCHECKSTYLE-287:
---
Attachment: (was: mcheckstyle-287-demo.tgz)
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> ... 20 more
> {noformat}
> Looking at the code, you see a null check is done for the list, bit not for
> elements of that list:
>
[jira] [Comment Edited] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062292#comment-16062292
]
Ed Randall edited comment on MCHECKSTYLE-287 at 6/25/17 11:49 AM:
--
Am trying to follow the documentation for multimodule configuration, should be
supported:
https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
OK I got it - the csrules sub-module can be there but must explicitly *not*
share the project parent pom, the reactor then builds correctly.
The demo project then illustrates the issue on a clean cache, will re-upload
was (Author: edrandall):
Am trying to follow the documentation for multimodule configuration, should be
supported:
https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
>
[jira] [Commented] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062292#comment-16062292
]
Ed Randall commented on MCHECKSTYLE-287:
Am trying to follow the documentation for multimodule configuration, should be
supported:
https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
>
[jira] [Commented] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062272#comment-16062272
]
Ed Randall commented on MCHECKSTYLE-287:
Never seen that, I'm on maven 3.3.9
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> ... 20 more
> {noformat}
> Looking at the code, you see a null check is done for
[jira] [Comment Edited] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062268#comment-16062268
]
Ed Randall edited comment on MCHECKSTYLE-287 at 6/25/17 9:15 AM:
-
New project mcheckstyle-287-demo.tgz attached - should reproduce the
MCHECKSTYLE-287 without any external parent pom dependency.
$ mvn clean install
... success ...
$ mvn -e site
...
{noformat}
... 20 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:876)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
at
org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:473)
at
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:154)
{noformat}
was (Author: edrandall):
New project should reproduce the MCHECKSTYLE-287 without any external parent
pom dependency.
{noformat}
... 20 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:876)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
at
org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:473)
at
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:154)
{noformat}
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
>
[jira] [Updated] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Randall updated MCHECKSTYLE-287:
---
Attachment: mcheckstyle-287-demo.tgz
New project should reproduce the MCHECKSTYLE-287 without any external parent
pom dependency.
{noformat}
... 20 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:876)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
at
org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:473)
at
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:154)
{noformat}
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: mcheckstyle-287-demo.tgz, patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
>
[jira] [Comment Edited] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062053#comment-16062053
]
Ed Randall edited comment on MCHECKSTYLE-287 at 6/24/17 4:37 PM:
-
Still affects 2.17 with maven 3.3.9 Google shows that quite a few users
have suffered this issue; Is there any chance we could have a release with the
quick tactical fix (catch NullPointerException in the offending Artifact loop)
so we can run 'mvn site' on a multimodule project without having to figure out
tedious workarounds?
You guys can then continue to research the root cause... it's been going on too
long. Thanks!
was (Author: edrandall):
Still affects 2.17 Google shows that quite a few users have suffered this
issue; Is there any chance we could have a release with the quick tactical fix
(catch NullPointerException in the offending Artifact loop) so we can run 'mvn
site' on a multimodule project without having to figure out tedious workarounds?
You guys can then continue to research the root cause... it's been going on too
long. Thanks!
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
>
[jira] [Comment Edited] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062053#comment-16062053
]
Ed Randall edited comment on MCHECKSTYLE-287 at 6/24/17 4:36 PM:
-
Still affects 2.17 Google shows that quite a few users have suffered this
issue; Is there any chance we could have a release with the quick tactical fix
(catch NullPointerException in the offending Artifact loop) so we can run 'mvn
site' on a multimodule project without having to figure out tedious workarounds?
You guys can then continue to research the root cause... it's been going on too
long. Thanks!
was (Author: edrandall):
Google shows that quite a few users have suffered this issue; Is there any
chance we could have a release with the quick tactical fix (catch
NullPointerException in the offending Artifact loop) so we can run 'mvn site'
on a multimodule project without having to figure out tedious workarounds?
You guys can then continue to research the root cause... it's been going on too
long. Thanks!
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
>
[jira] [Commented] (MCHECKSTYLE-287) checkstyle report throws NPE
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062053#comment-16062053
]
Ed Randall commented on MCHECKSTYLE-287:
Google shows that quite a few users have suffered this issue; Is there any
chance we could have a release with the quick tactical fix (catch
NullPointerException in the offending Artifact loop) so we can run 'mvn site'
on a multimodule project without having to figure out tedious workarounds?
You guys can then continue to research the root cause... it's been going on too
long. Thanks!
> checkstyle report throws NPE
>
>
> Key: MCHECKSTYLE-287
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-287
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13, 2.14
>Reporter: Thomas Scheffler
> Attachments: patch1.diff, projects.tar.gz
>
>
> I don't know what triggers this bug. Somehow
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.collectArtifacts(String)
> produces a List which contains the null object. And therefor an exception is
> thrown here (2.14):
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
> project oaipmh: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.configureResourceLocator(DefaultCheckstyleExecutor.java:852)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:102)
> at
> org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:474)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
>
