[jira] (ARCHETYPE-423) archetype:crawl goal fails with NPE
[
https://jira.codehaus.org/browse/ARCHETYPE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Evdokimov updated ARCHETYPE-423:
---
Attachment: ARCHETYPE-423-archetype-common.patch
Patch to fix this problem by checking for null before trying to close an
archetype zipFile.
> archetype:crawl goal fails with NPE
> ---
>
> Key: ARCHETYPE-423
> URL: https://jira.codehaus.org/browse/ARCHETYPE-423
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.2
> Environment: RHEL 5.8, JDK 1.6.24, Maven 3.0.3
>Reporter: Alexander Zobkov
> Attachments: ARCHETYPE-423-archetype-common.patch, maven-debug.txt
>
>
> archetype:crawl goal fails with NPE and does not provide error
> details/explanations when during repository scanning process it tries to open
> broken artifact. A broken artifacts contain a plain text (usually html which
> tells that artifact or repository was moved or deleted) but not zip archives
> inside a jar file.
> {noformat}
> [INFO] Scanning /home/zobkov/.m2/repository/asm/asm/3.0/asm-3.0.jar
> [INFO] Scanning /home/zobkov/.m2/repository/asm/asm/3.1/asm-3.1-sources.jar
> [INFO] Scanning /home/zobkov/.m2/repository/asm/asm/3.1/asm-3.1.jar
> [INFO] Scanning /home/zobkov/.m2/repository/asm/asm/2.2.3/asm-2.2.3.jar
> [INFO] Scanning /home/zobkov/.m2/repository/asm/asm/2.2/asm-2.2.jar
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.580s
> [INFO] Finished at: Mon Nov 19 12:11:33 MSK 2012
> [INFO] Final Memory: 6M/148M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:2.2:crawl (default-cli) on
> project standalone-pom: Execution default-cli of goal
> org.apache.maven.plugins:maven-archetype-plugin:2.2:crawl failed.
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-391) excludePackageNames doesn't work if source path is not specified
[
https://jira.codehaus.org/browse/MJAVADOC-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roberto Andrade updated MJAVADOC-391:
-
Description:
I just learned by looking at the plugin's source code that the
{{excludePackageNames}} configuration only works if I specify a {{sourcepath}}
configuration but could not find that documented anywhere.
I was assuming (perhaps incorrectly) that my project's source folders would be
considered by default as the value of {{sourcepath}} given when I run the
plugin without exclusions it actually finds the source in the right place to be
able to generate the javadoc (more specifically, I was assuming the default
value of it to be the same as {{project.build.sourceDirectory}}).
was:
I just learned by looking at the plugin's source code that the
{{excludePackageNames}} configuration only works if I specify a {{sourcepath}}
configuration but could not find that documented anywhere.
I was assuming (perhaps incorrectly) that my project's source folders would be
considered by default as the value of {{sourcepath}} given when I run the
plugin without exclusions it actually finds the source in the right place to be
able to generate the javadoc.
> excludePackageNames doesn't work if source path is not specified
>
>
> Key: MJAVADOC-391
> URL: https://jira.codehaus.org/browse/MJAVADOC-391
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: OSX 10.9, Maven 3.1
>Reporter: Roberto Andrade
>
> I just learned by looking at the plugin's source code that the
> {{excludePackageNames}} configuration only works if I specify a
> {{sourcepath}} configuration but could not find that documented anywhere.
> I was assuming (perhaps incorrectly) that my project's source folders would
> be considered by default as the value of {{sourcepath}} given when I run the
> plugin without exclusions it actually finds the source in the right place to
> be able to generate the javadoc (more specifically, I was assuming the
> default value of it to be the same as {{project.build.sourceDirectory}}).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-391) excludePackageNames doesn't work if source path is not specified
Roberto Andrade created MJAVADOC-391:
Summary: excludePackageNames doesn't work if source path is not
specified
Key: MJAVADOC-391
URL: https://jira.codehaus.org/browse/MJAVADOC-391
Project: Maven Javadoc Plugin
Issue Type: Improvement
Affects Versions: 2.9.1
Environment: OSX 10.9, Maven 3.1
Reporter: Roberto Andrade
I just learned by looking at the plugin's source code that the
{{excludePackageNames}} configuration only works if I specify a {{sourcepath}}
configuration but could not find that documented anywhere.
I was assuming (perhaps incorrectly) that my project's source folders would be
considered by default as the value of {{sourcepath}} given when I run the
plugin without exclusions it actually finds the source in the right place to be
able to generate the javadoc.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-874) Improve doc about specifying version of plugin could sometimes be required on command-line
[
https://jira.codehaus.org/browse/MRELEASE-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344424#comment-344424
]
Robert Scholte commented on MRELEASE-874:
-
I agree. And it's probably better to use a different URL, one that is not
related to the maven-release-plugin. Something like
{noformat}scm:svn:https://svn.mycompany.com/repos/path/to/myproject/tags/myproject-1.2.3{noformat}
> Improve doc about specifying version of plugin could sometimes be required on
> command-line
> --
>
> Key: MRELEASE-874
> URL: https://jira.codehaus.org/browse/MRELEASE-874
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
> Environment: online docs
>Reporter: Anders Hammar
>
> On the page
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
> it states the following command to execute when specifying a tag as well:
> {quote}
> mvn release:perform
> -DconnectionUrl=scm:svn:https://svn.apache.org/repos/asf/maven/plugins/tags/maven-release-plugin-2.0
> {quote}
> IMHO, in most scenarios when doing this one would do this outside of the
> project and Maven would then use the version om m-release-p specified in the
> super-POM of the executing Maven. Which could be an old version (Maven 3.0.4
> specifies v2.0 of m-release-p for example).
> I suggest clearly explain this and also the command to use the latest version
> of the plugin, i.e.:
> {quote}
> mvn org.apache.maven.plugins:maven-release-plugin::perform
> -DconnectionUrl=scm:svn:https://svn.apache.org/repos/asf/maven/plugins/tags/maven-release-plugin-2.0
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-873) Remove possibly confusing non-standard goals from example
[
https://jira.codehaus.org/browse/MRELEASE-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Hammar closed MRELEASE-873.
--
Resolution: Fixed
Fix Version/s: 3.0
Fixed in [r1585825|http://svn.apache.org/r1585825]
> Remove possibly confusing non-standard goals from example
> -
>
> Key: MRELEASE-873
> URL: https://jira.codehaus.org/browse/MRELEASE-873
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
> Environment: online docs
>Reporter: Anders Hammar
>Assignee: Anders Hammar
>Priority: Trivial
> Fix For: 3.0
>
>
> In the perform goal example page
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
> the following example configuration is found:
> {quote}
> deploy assembly:single
> {quote}
> I think this should be removed as it has nothing to do with the subject being
> explained (specifying profiles) and the "assembly:single" goal should be
> considered a nonstandard goal for a release (it should be bound to the build
> lifecycle instead). It could confuse people and also possibly make someone
> think that this is a good practice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-873) Remove possibly confusing non-standard goals from example
[
https://jira.codehaus.org/browse/MRELEASE-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Hammar reassigned MRELEASE-873:
--
Assignee: Anders Hammar
> Remove possibly confusing non-standard goals from example
> -
>
> Key: MRELEASE-873
> URL: https://jira.codehaus.org/browse/MRELEASE-873
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
> Environment: online docs
>Reporter: Anders Hammar
>Assignee: Anders Hammar
>Priority: Trivial
> Fix For: 3.0
>
>
> In the perform goal example page
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
> the following example configuration is found:
> {quote}
> deploy assembly:single
> {quote}
> I think this should be removed as it has nothing to do with the subject being
> explained (specifying profiles) and the "assembly:single" goal should be
> considered a nonstandard goal for a release (it should be bound to the build
> lifecycle instead). It could confuse people and also possibly make someone
> think that this is a good practice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344412#comment-344412 ] Gray commented on MNG-5605: --- I seemed to have worked around this problem by switching to use sftp URLs as opposed to using scp. In looking at the code, it sure seems to be that this is some incompatibility issue between jsch and wagon-ssh. > ssh-wagon hangs > --- > > Key: MNG-5605 > URL: https://jira.codehaus.org/browse/MNG-5605 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Deployment >Affects Versions: 3.2.1 >Reporter: Frank Cornelis >Priority: Blocker > > When releasing (using maven-release-plugin) via Maven 3.1.1 everything works > as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden > hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344408#comment-344408
]
Gray edited comment on MNG-5605 at 4/8/14 12:07 PM:
I'm having a similar problem with maven downloads that hang -- typically on
very small files like poms. If I log into the repo box I see the following
process:
{{maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p -f
/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
If I then kill the process on the server, the client continues without an error.
{{Downloading:
scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom
401/400 B}}
It seems to me to be very small files that have the problem. Possibly smaller
than some sort of packet? 2k, 400B, etc..
was (Author: graywatson):
I'm having a similar problem with maven downloads that hang -- typically on
very small files like poms. If I log into the repo box I see the following
process:
maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p -f
/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom
If I then kill the process on the server, the client continues without an error.
Downloading:
scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom
401/400 B
It seems to me to be very small files that have the problem. Possibly smaller
than some sort of packet? 2k, 400B, etc..
> ssh-wagon hangs
> ---
>
> Key: MNG-5605
> URL: https://jira.codehaus.org/browse/MNG-5605
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.2.1
>Reporter: Frank Cornelis
>Priority: Blocker
>
> When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
> as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
> hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344408#comment-344408
]
Gray edited comment on MNG-5605 at 4/8/14 12:08 PM:
I'm having a similar problem with maven downloads that hang -- typically on
very small files like poms. If I log into the repo box I see the following
process:
bq. {{maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p
-f /var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
If I then kill the process on the server, the client continues without an error.
{quote}
{{Downloading:
scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
{{401/400 B}}
{quote}
It seems to me to be very small files that have the problem. Possibly smaller
than some sort of packet? 2k, 400B, etc..
was (Author: graywatson):
I'm having a similar problem with maven downloads that hang -- typically on
very small files like poms. If I log into the repo box I see the following
process:
bq. {{maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p
-f /var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
If I then kill the process on the server, the client continues without an error.
{quote}
{{Downloading:
scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
{{ 401/400 B}}
{quote}
It seems to me to be very small files that have the problem. Possibly smaller
than some sort of packet? 2k, 400B, etc..
> ssh-wagon hangs
> ---
>
> Key: MNG-5605
> URL: https://jira.codehaus.org/browse/MNG-5605
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.2.1
>Reporter: Frank Cornelis
>Priority: Blocker
>
> When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
> as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
> hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344408#comment-344408 ] Gray edited comment on MNG-5605 at 4/8/14 12:06 PM: I'm having a similar problem with maven downloads that hang -- typically on very small files like poms. If I log into the repo box I see the following process: maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p -f /var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom If I then kill the process on the server, the client continues without an error. Downloading: scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom 401/400 B It seems to me to be very small files that have the problem. Possibly smaller than some sort of packet? 2k, 400B, etc.. was (Author: graywatson): Same for me. If I log into the repo box I see the following process: maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p -f /var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom If I then kill the process on the server, the client continues without an error. Downloading: scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom 401/400 B It seems to me to be very small files that have the problem. Possibly smaller than some sort of packet? 2k, 400B, etc.. > ssh-wagon hangs > --- > > Key: MNG-5605 > URL: https://jira.codehaus.org/browse/MNG-5605 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Deployment >Affects Versions: 3.2.1 >Reporter: Frank Cornelis >Priority: Blocker > > When releasing (using maven-release-plugin) via Maven 3.1.1 everything works > as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden > hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344408#comment-344408
]
Gray edited comment on MNG-5605 at 4/8/14 12:08 PM:
I'm having a similar problem with maven downloads that hang -- typically on
very small files like poms. If I log into the repo box I see the following
process:
bq. {{maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p
-f /var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
If I then kill the process on the server, the client continues without an error.
{quote}
{{Downloading:
scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
{{ 401/400 B}}
{quote}
It seems to me to be very small files that have the problem. Possibly smaller
than some sort of packet? 2k, 400B, etc..
was (Author: graywatson):
I'm having a similar problem with maven downloads that hang -- typically on
very small files like poms. If I log into the repo box I see the following
process:
{{maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p -f
/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom}}
If I then kill the process on the server, the client continues without an error.
{{Downloading:
scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom
401/400 B}}
It seems to me to be very small files that have the problem. Possibly smaller
than some sort of packet? 2k, 400B, etc..
> ssh-wagon hangs
> ---
>
> Key: MNG-5605
> URL: https://jira.codehaus.org/browse/MNG-5605
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.2.1
>Reporter: Frank Cornelis
>Priority: Blocker
>
> When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
> as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
> hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344408#comment-344408 ] Gray commented on MNG-5605: --- Same for me. If I log into the repo box I see the following process: maven20954 0.0 0.0 2388 736 ?Ss 16:45 0:00 scp -p -f /var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom If I then kill the process on the server, the client continues without an error. Downloading: scp://dev.achievementnetwork.org/var/maven/org/moxieapps/gwt-highcharts/1.5.0/gwt-highcharts-1.5.0.pom 401/400 B It seems to me to be very small files that have the problem. Possibly smaller than some sort of packet? 2k, 400B, etc.. > ssh-wagon hangs > --- > > Key: MNG-5605 > URL: https://jira.codehaus.org/browse/MNG-5605 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Deployment >Affects Versions: 3.2.1 >Reporter: Frank Cornelis >Priority: Blocker > > When releasing (using maven-release-plugin) via Maven 3.1.1 everything works > as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden > hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-874) Improve doc about specifying version of plugin could sometimes be required on command-line
Anders Hammar created MRELEASE-874:
--
Summary: Improve doc about specifying version of plugin could
sometimes be required on command-line
Key: MRELEASE-874
URL: https://jira.codehaus.org/browse/MRELEASE-874
Project: Maven Release Plugin
Issue Type: Improvement
Components: documentation
Affects Versions: 2.5
Environment: online docs
Reporter: Anders Hammar
On the page
http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
it states the following command to execute when specifying a tag as well:
{quote}
mvn release:perform
-DconnectionUrl=scm:svn:https://svn.apache.org/repos/asf/maven/plugins/tags/maven-release-plugin-2.0
{quote}
IMHO, in most scenarios when doing this one would do this outside of the
project and Maven would then use the version om m-release-p specified in the
super-POM of the executing Maven. Which could be an old version (Maven 3.0.4
specifies v2.0 of m-release-p for example).
I suggest clearly explain this and also the command to use the latest version
of the plugin, i.e.:
{quote}
mvn org.apache.maven.plugins:maven-release-plugin::perform
-DconnectionUrl=scm:svn:https://svn.apache.org/repos/asf/maven/plugins/tags/maven-release-plugin-2.0
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-873) Remove possibly confusing non-standard goals from example
[
https://jira.codehaus.org/browse/MRELEASE-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Hammar updated MRELEASE-873:
---
Affects Version/s: 2.5
> Remove possibly confusing non-standard goals from example
> -
>
> Key: MRELEASE-873
> URL: https://jira.codehaus.org/browse/MRELEASE-873
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
> Environment: online docs
>Reporter: Anders Hammar
>Priority: Trivial
>
> In the perform goal example page
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
> the following example configuration is found:
> {quote}
> deploy assembly:single
> {quote}
> I think this should be removed as it has nothing to do with the subject being
> explained (specifying profiles) and the "assembly:single" goal should be
> considered a nonstandard goal for a release (it should be bound to the build
> lifecycle instead). It could confuse people and also possibly make someone
> think that this is a good practice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-873) Remove possibly confusing non-standard goals from example
Anders Hammar created MRELEASE-873:
--
Summary: Remove possibly confusing non-standard goals from example
Key: MRELEASE-873
URL: https://jira.codehaus.org/browse/MRELEASE-873
Project: Maven Release Plugin
Issue Type: Improvement
Components: documentation
Environment: online docs
Reporter: Anders Hammar
Priority: Trivial
In the perform goal example page
http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
the following example configuration is found:
{quote}
deploy assembly:single
{quote}
I think this should be removed as it has nothing to do with the subject being
explained (specifying profiles) and the "assembly:single" goal should be
considered a nonstandard goal for a release (it should be bound to the build
lifecycle instead). It could confuse people and also possibly make someone
think that this is a good practice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-168) ManifestResourceTransformer manifestEntries map declares wrong generic type
Stuart McCulloch created MSHADE-168: --- Summary: ManifestResourceTransformer manifestEntries map declares wrong generic type Key: MSHADE-168 URL: https://jira.codehaus.org/browse/MSHADE-168 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Stuart McCulloch Attachments: ManifestResourceTransformer_manifestEntries.patch The ManifestResourceTransformer class declares a map called manifestEntries with a signature of Map. This is incorrect because at runtime this map is actually only ever populated with String values. Furthermore the only place where these map values are used is: https://github.com/apache/maven-plugins/blob/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/ManifestResourceTransformer.java#L106 and while the signature of Attributes.put accepts values of any type, the javadoc states that values are checked that they are Strings at runtime: http://docs.oracle.com/javase/7/docs/api/java/util/jar/Attributes.html#put(java.lang.Object,%20java.lang.Object) In fact it turns out that you can change the manifestEntries Map signature to use any type for the value without getting a compile error - and at runtime it's ignored by the code populating the configuration. I only happened to notice this discrepancy when investigating a related issue involving a stricter version of the plexus MapConverter that checks generic bounds when populating maps: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429369 The correct signature of manifestEntries should be Map -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-226) NoClassDefFoundError with checkstyle-aggregate
[ https://jira.codehaus.org/browse/MCHECKSTYLE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344384#comment-344384 ] Dennis Lundberg commented on MCHECKSTYLE-226: - Thanks, no I haven't tried it yet. > NoClassDefFoundError with checkstyle-aggregate > -- > > Key: MCHECKSTYLE-226 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-226 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11, 2.12 >Reporter: Lefebvre JF > Attachments: Sans titre.png, wsSample.zip > > > When I launch checkstyle-aggregate on parent, I Have error > NoClassDefFoundError on rules RedundantThrows (Exeptions classes ar in an > artifact imported as scope compile) > Any Idea ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-226) NoClassDefFoundError with checkstyle-aggregate
[ https://jira.codehaus.org/browse/MCHECKSTYLE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHECKSTYLE-226: Affects Version/s: 2.11 > NoClassDefFoundError with checkstyle-aggregate > -- > > Key: MCHECKSTYLE-226 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-226 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11, 2.12 >Reporter: Lefebvre JF > Attachments: Sans titre.png, wsSample.zip > > > When I launch checkstyle-aggregate on parent, I Have error > NoClassDefFoundError on rules RedundantThrows (Exeptions classes ar in an > artifact imported as scope compile) > Any Idea ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-872) NPE in release:perform when specifying svn tag as param
[
https://jira.codehaus.org/browse/MRELEASE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344383#comment-344383
]
Anders Hammar commented on MRELEASE-872:
Not sure if this is related to MRELEASE-839. The description in that ticket
indicates otherwise and the comments are talking about git.
> NPE in release:perform when specifying svn tag as param
> ---
>
> Key: MRELEASE-872
> URL: https://jira.codehaus.org/browse/MRELEASE-872
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.5
> Environment: Windows 7, Maven 3.0.4, IBM JDK 1.6.0
>Reporter: Anders Hammar
>
> When executing release:perform and specifying the Svn tag via the
> 'connectionUrl' parameter, the execution fails with a NullPointerException.
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.5:perform (default-cli) on
> project standalone-pom: Execution default-cli of goal
> org.apache.maven.plugins:maven-release-plugin:2.5:perform failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.5:perform (default-cli)
> on project standalone-pom: Execution default-cli
> of goal org.apache.maven.plugins:maven-release-plugin:2.5:perform failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.5:perform
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:210)
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:200)
> at
> org.apache.maven.shared.release.phase.CheckoutProjectFromScm.performCheckout(CheckoutProjectFromScm.java:230)
> at
> org.apache.maven.shared.release.phase.CheckoutProjectFromScm.execute(CheckoutProjectFromScm.java:131)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:429)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:381)
> at
> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:177)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-872) NPE in release:perform when specifying svn tag as param
Anders Hammar created MRELEASE-872:
--
Summary: NPE in release:perform when specifying svn tag as param
Key: MRELEASE-872
URL: https://jira.codehaus.org/browse/MRELEASE-872
Project: Maven Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.5
Environment: Windows 7, Maven 3.0.4, IBM JDK 1.6.0
Reporter: Anders Hammar
When executing release:perform and specifying the Svn tag via the
'connectionUrl' parameter, the execution fails with a NullPointerException.
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5:perform (default-cli) on
project standalone-pom: Execution default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.5:perform failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5:perform (default-cli) on
project standalone-pom: Execution default-cli
of goal org.apache.maven.plugins:maven-release-plugin:2.5:perform failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.5:perform
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:210)
at
org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:200)
at
org.apache.maven.shared.release.phase.CheckoutProjectFromScm.performCheckout(CheckoutProjectFromScm.java:230)
at
org.apache.maven.shared.release.phase.CheckoutProjectFromScm.execute(CheckoutProjectFromScm.java:131)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:429)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:381)
at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:177)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-226) NoClassDefFoundError with checkstyle-aggregate
[ https://jira.codehaus.org/browse/MCHECKSTYLE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344377#comment-344377 ] Lefebvre JF commented on MCHECKSTYLE-226: - Yes same problem with 2.11 Do you reproduce with my sample ? > NoClassDefFoundError with checkstyle-aggregate > -- > > Key: MCHECKSTYLE-226 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-226 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Lefebvre JF > Attachments: Sans titre.png, wsSample.zip > > > When I launch checkstyle-aggregate on parent, I Have error > NoClassDefFoundError on rules RedundantThrows (Exeptions classes ar in an > artifact imported as scope compile) > Any Idea ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344376#comment-344376
]
Dennis Lundberg commented on MCHECKSTYLE-225:
-
I have added an IT that fails with trunk version, but that works with 2.11.
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-226) NoClassDefFoundError with checkstyle-aggregate
[ https://jira.codehaus.org/browse/MCHECKSTYLE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344371#comment-344371 ] Dennis Lundberg commented on MCHECKSTYLE-226: - Does this happen in version 2.11 or earlier as well? > NoClassDefFoundError with checkstyle-aggregate > -- > > Key: MCHECKSTYLE-226 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-226 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Lefebvre JF > Attachments: Sans titre.png, wsSample.zip > > > When I launch checkstyle-aggregate on parent, I Have error > NoClassDefFoundError on rules RedundantThrows (Exeptions classes ar in an > artifact imported as scope compile) > Any Idea ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344370#comment-344370
]
Dennis Lundberg commented on MCHECKSTYLE-225:
-
Having looked at it, I think that the implementation of the new
LicenseResourceManager is wrong. Lines 60-66:
{code:java}
if ( resourceLoader instanceof ThreadContextClasspathResourceLoader
&& !"config/maven-header.txt".equals( name ) )
{
// MCHECKSTYLE-219: Don't load the license from the plugin
// classloader, only allow config/maven-header.txt
continue;
}
{code}
Shouldn't it be:
{code:java}
if ( resourceLoader instanceof ThreadContextClasspathResourceLoader
&& "config/maven-header.txt".equals( name ) )
{
// MCHECKSTYLE-219: Don't load the license from the plugin
// classloader, only allow config/maven-header.txt
continue;
}
{code}
Robert, could you comment on that?
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344369#comment-344369
]
Dennis Lundberg commented on MCHECKSTYLE-225:
-
It seems that this was caused by the fix for MCHECKSTYLE-219.
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-224) Warning about missing XRef for module with no files to check
[
https://jira.codehaus.org/browse/MCHECKSTYLE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHECKSTYLE-224:
Description:
If you run {{mvn jxr:jxr checkstyle:checkstyle}} on a project that does not
have any source files that should be checked, the following warning is issued:
[WARNING] Unable to locate Source XRef to link to - DISABLED
This warning can only be suppressed through configuration if we skip checkstyle
for that particular project/module.
The warning is bogus though, because there are no files that Checkstyle will
check, so there is no need to check for any XRef to start with.
It should be possible to delay checking for XRef until it has been determined
that there are any files to be checked.
was:
If you run {{mvn jxr:jxr checkstyle:checkstyle}} on a project that does not
have any source files that should be checked, the following warning is issued:
[WARNING] Unable to locate Source XRef to link to - DISABLED
This warning can only be suppressed through configuration if we skip checkstyle
for that particular project/module.
The warning is bogus though, because there are files that Checkstyle will
check, so there is no need to check for any XRef to start with.
It should be possible to delay checking for XRef until it has been determined
that there are any files to be checked.
> Warning about missing XRef for module with no files to check
>
>
> Key: MCHECKSTYLE-224
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-224
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.13
>
>
> If you run {{mvn jxr:jxr checkstyle:checkstyle}} on a project that does not
> have any source files that should be checked, the following warning is issued:
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> This warning can only be suppressed through configuration if we skip
> checkstyle for that particular project/module.
> The warning is bogus though, because there are no files that Checkstyle will
> check, so there is no need to check for any XRef to start with.
> It should be possible to delay checking for XRef until it has been determined
> that there are any files to be checked.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
