[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[ https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352986#comment-352986 ] Mirko Friedenhagen commented on MCHANGES-341: - I took a look into the Github and Trac downloaders and there does not seem to be a simple way set timeouts, the clients are set up in depending libraries, so I committed http://svn.apache.org/viewvc?view=revision&revision=1626681. Thanks for your feedback, Dennis. > Externalize JIRA server timeout values to the configuration section > --- > > Key: MCHANGES-341 > URL: https://jira.codehaus.org/browse/MCHANGES-341 > Project: Maven Changes Plugin > Issue Type: Improvement >Reporter: Boris Pavlovic >Assignee: Mirko Friedenhagen > Fix For: 2.11 > > > [Based on the StackOverflow > Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583] > > QUESTION: > I have a maven-changes-plugin configured for a build process. Sometimes, JIRA > intranet server is down and the build takes ages waiting for a long timeout > on JIRA. > Is there a way to configure the timeout? > ANSWER: > It does not appear so. The source for the RestJiraDownloader, the class that > queries JIRA for issues, has hard-coded timeout values. Lines 562-566 > indicate a connection timeout of 36 seconds and a receive timeout of 32 > seconds. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[ https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352986#comment-352986 ] Mirko Friedenhagen edited comment on MCHANGES-341 at 9/22/14 3:10 AM: -- I took a look into the Github and Trac downloaders and there does not seem to be a simple way set timeouts, the clients are set up in depending libraries, so I committed http://svn.apache.org/viewvc?view=revision&revision=1626681. Thanks for your feedback, Dennis. Uploaded new SNAPSHOT https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-changes-plugin/2.11-SNAPSHOT/maven-changes-plugin-2.11-20140922.080939-195.pom was (Author: mfriedenhagen): I took a look into the Github and Trac downloaders and there does not seem to be a simple way set timeouts, the clients are set up in depending libraries, so I committed http://svn.apache.org/viewvc?view=revision&revision=1626681. Thanks for your feedback, Dennis. > Externalize JIRA server timeout values to the configuration section > --- > > Key: MCHANGES-341 > URL: https://jira.codehaus.org/browse/MCHANGES-341 > Project: Maven Changes Plugin > Issue Type: Improvement >Reporter: Boris Pavlovic >Assignee: Mirko Friedenhagen > Fix For: 2.11 > > > [Based on the StackOverflow > Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583] > > QUESTION: > I have a maven-changes-plugin configured for a build process. Sometimes, JIRA > intranet server is down and the build takes ages waiting for a long timeout > on JIRA. > Is there a way to configure the timeout? > ANSWER: > It does not appear so. The source for the RestJiraDownloader, the class that > queries JIRA for issues, has hard-coded timeout values. Lines 562-566 > indicate a connection timeout of 36 seconds and a receive timeout of 32 > seconds. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
jeff porter created MJAVADOC-407:
Summary: cannot parse annotations : when generating javadoc
Key: MJAVADOC-407
URL: https://jira.codehaus.org/browse/MJAVADOC-407
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux and windows.
Maven 3.0.4 , JDK 1.6.0.43
Reporter: jeff porter
See full issue text at :
http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
I'm getting the following error when I do
mvn clean deploy -DperformRelease=true
[ERROR] Exit code: 1 - .java:3: package javax.inject does not exist [ERROR]
import javax.inject.Named; [ERROR] ^ [ERROR]
TransactionServiceExternalImpl.java:5: cannot find symbol [ERROR] symbol: class
Named [ERROR] @Named("transactionServiceExternal") [ERROR] ^ [ERROR]
java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be cast
to com.sun.javadoc.AnnotationTypeDoc
The POM is this...
com.xxx
ts-impl/artifactId>
2.4.0-SNAPSHOT
javax.inject
javax.inject
1
There is only one class...
import javax.inject.Named;
@Named("transactionServiceExternal")
public class TransactionServiceExternalImpl
{
}
I get the error with
jdk1.5.0_22
jdk1.6.0_29
jdk1.6.0_43
jdk1.6.0_43_32bit
But NOT with...
jdk1.7.0_05
Anyone have any ideas?
Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
I now know that the reason is that the Maven Javadoc Plugin has changed from
2.9.1 to 2.10. and this is the cause of the problem.
I can see this warning...
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin
is missing.
By setting the following in my pom
org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-250) NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
[
https://jira.codehaus.org/browse/MCHECKSTYLE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Pokrovsky updated MCHECKSTYLE-250:
-
Summary: NPE on tying to load LICENSE.txt resource from non-jar plugin
dependencies (was: NPE on loading default LICENSE.txt from non-jar plugin
dependencies)
> NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
> --
>
> Key: MCHECKSTYLE-250
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-250
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Konstantin Pokrovsky
>
> *Steps to reproduce:*
> * Add non jar (XML for example) artifact dependency to plugin dependencies
> section:
> {code:xml}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.13
>
>
> anygroup
> anyfile
> xml
>
>
>
> {code}
> * Run _checkstyle:check_
> Result:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
> project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
> (default-cli) on project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check 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: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:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 common frames omitted
> Caused by: java.lang.NullPointerException: null
> at
> org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
> at
> org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:75)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:520)
> at
> org.apache.maven.plugin.checkstyle.exec.Def
[jira] (MCHECKSTYLE-250) NPE on loading default LICENSE.txt from non-jar plugin dependencies
Konstantin Pokrovsky created MCHECKSTYLE-250:
Summary: NPE on loading default LICENSE.txt from non-jar plugin
dependencies
Key: MCHECKSTYLE-250
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-250
Project: Maven Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.13
Reporter: Konstantin Pokrovsky
*Steps to reproduce:*
* Add non jar (XML for example) artifact dependency to plugin dependencies
section:
{code:xml}
org.apache.maven.plugins
maven-checkstyle-plugin
2.13
anygroup
anyfile
xml
{code}
* Run _checkstyle:check_
Result:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
project rt: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
project rt: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check 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: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:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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-cli of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 common frames omitted
Caused by: java.lang.NullPointerException: null
at
org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
at
org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:75)
at
org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:520)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:347)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:220)
at
org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:532)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
... 20 common frames omitted
{noformat}
*Investigation:*
* _CheckstyleViolationCheckMoj
[jira] (MCHECKSTYLE-250) NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
[
https://jira.codehaus.org/browse/MCHECKSTYLE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Pokrovsky updated MCHECKSTYLE-250:
-
Description:
*Steps to reproduce:*
* Add non jar (XML for example) artifact dependency to plugin dependencies
section:
{code:xml}
org.apache.maven.plugins
maven-checkstyle-plugin
2.13
anygroup
anyfile
xml
{code}
* Run _checkstyle:check_
Result:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
project rt: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
project rt: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check 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: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:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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-cli of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 common frames omitted
Caused by: java.lang.NullPointerException: null
at
org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
at
org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:75)
at
org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:520)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:347)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:220)
at
org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:532)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
... 20 common frames omitted
{noformat}
*Investigation:*
* _CheckstyleViolationCheckMojo_ forms _CheckstyleExecutorRequest_ for the
executor by initializing _licenseArtifacts_ property with all plugin's
dependencies.
{code:java|title=CheckstyleViolationCheckMojo.java:516}
[jira] (SCM-781) Add a goal to recursively validate SCM url
Baptiste Mathus created SCM-781: --- Summary: Add a goal to recursively validate SCM url Key: SCM-781 URL: https://jira.codehaus.org/browse/SCM-781 Project: Maven SCM Issue Type: Improvement Components: maven-plugin Affects Versions: 1.9.2 Reporter: Baptiste Mathus This is a followup on SCM-741 which adds a feature to validate that the *SVN* url specified in the is indeed matching the working copy URL. The issue is that the validate goal is a requiresProject=false one (require, and so won't recurse into submodules. Our setup requires that each submodule tag is validated since some releases are triggered from SVN "subdirectories". This would be cool to add a validate-recursive goal that would simply override the requiresProject=false to true so that it can run automatically on all modules of a multimodules project. See also http://mail-archives.apache.org/mod_mbox/maven-dev/201406.mbox/%3ccanwgjs6uepc1e96buha1eakvo69l6but-n9sab-9o9twrhq...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-176) Suppress warning output
[ https://jira.codehaus.org/browse/MSHADE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352994#comment-352994 ] Taylor Jones commented on MSHADE-176: - Haven't heard anything in a while, is there anything more I need to do here? > Suppress warning output > --- > > Key: MSHADE-176 > URL: https://jira.codehaus.org/browse/MSHADE-176 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Taylor Jones > Fix For: 2.4 > > Attachments: suppressWarnings_option.patch > > > The warnings Shade outputs are useful, but there are some cases where nothing > can actually be done about them. Recently, I encountered this with the Neo4j > libraries; there is one overlapping class between two critical JARs (kernel > and rest), and no way to resolve this via exclusions. > In these cases, everything works just fine. At best, the warnings are just > noise, but we also have some build processes in place that will fail on Maven > warnings. I figured this would be a pretty simple thing to just suppress, but > Shade doesn't seem to have a way to do this. > I've included a simple patchset to address this which adds a new option to > the configuration called . There isn't a unit test > attached, unfortunately. I'm not quite sure how to unit test logging output > in this fashion without something akin to Mockito. I figured you guys > wouldn't appreciate me adding dependencies out of the blue but if a unit test > is required, I can give it a shot. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-176) Suppress warning output
[ https://jira.codehaus.org/browse/MSHADE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352999#comment-352999 ] Karl-Heinz Marbaise commented on MSHADE-176: First thanks for your support. And no you don't need to do anything at the moment. One of the devs needs time to pick up your patch and integrated into the plugin and do some testing. > Suppress warning output > --- > > Key: MSHADE-176 > URL: https://jira.codehaus.org/browse/MSHADE-176 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Taylor Jones > Fix For: 2.4 > > Attachments: suppressWarnings_option.patch > > > The warnings Shade outputs are useful, but there are some cases where nothing > can actually be done about them. Recently, I encountered this with the Neo4j > libraries; there is one overlapping class between two critical JARs (kernel > and rest), and no way to resolve this via exclusions. > In these cases, everything works just fine. At best, the warnings are just > noise, but we also have some build processes in place that will fail on Maven > warnings. I figured this would be a pretty simple thing to just suppress, but > Shade doesn't seem to have a way to do this. > I've included a simple patchset to address this which adds a new option to > the configuration called . There isn't a unit test > attached, unfortunately. I'm not quite sure how to unit test logging output > in this fashion without something akin to Mockito. I figured you guys > wouldn't appreciate me adding dependencies out of the blue but if a unit test > is required, I can give it a shot. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-165) target/site/pmd.html created with invalid charset=${outputEncoding}
[
https://jira.codehaus.org/browse/MPMD-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353001#comment-353001
]
Robert Kish commented on MPMD-165:
--
I just saw a similar issue as this get resolved:
http://jira.codehaus.org/browse/MCHECKSTYLE-126. Perhaps something there can be
applied here.
> target/site/pmd.html created with invalid charset=${outputEncoding}
> ---
>
> Key: MPMD-165
> URL: https://jira.codehaus.org/browse/MPMD-165
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0
> Environment: Maven 3.0.5, Java 6.0.43 on Windows XP
>Reporter: Robert Kish
>
> This problem also occurs for me with 3.1-SNAPSHOT. And it's also occurring
> for me using maven-jxr-plugin in the index.html file only (not
> allclasses-frame.html for example). So I am theorizing something in common
> with both of those plugins has the same issue.
> I have configured as a build plugin,
> {code}
> :
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.1-SNAPSHOT
>
> true
> 1.6
> ruleset.xml
>
>
> :
> {code}
> I have the following properties:
> {code}
>
>
> UTF-8
>
> UTF-8
>
> {code}
> From mvn -e -X output
> {code}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-pmd-plugin:3.1-SNAPSHOT:pmd' with basic
> configurator -->
> [DEBUG] (f) aggregate = false
> [DEBUG] (f) compileSourceRoots =
> [C:\NCP\NCOServer2\crs-data-crs\src\main\java]
> [DEBUG] (f) excludes = [**/com/crs/c/*.java]
> [DEBUG] (f) format = xml
> [DEBUG] (f) includeTests = false
> [DEBUG] (f) includeXmlInSite = false
> [DEBUG] (f) language = java
> [DEBUG] (f) linkXRef = true
> [DEBUG] (f) minimumPriority = 5
> [DEBUG] (f) outputDirectory = C:\NCP\NCOServer2\crs-data-crs\target\site
> [DEBUG] (f) outputEncoding = UTF-8
> [DEBUG] (f) reactorProjects = [MavenProject:
> com.cr.crs:crs-data-crs:1.0-SNAPSHOT @ C:\NCP\NCOServer2\crs-data-crs\pom.xml]
> [DEBUG] (s) rulesets = [C:\NCP\NCOServer2\ruleset.xml]
> [DEBUG] (f) skip = false
> [DEBUG] (f) sourceEncoding = UTF-8
> [DEBUG] (f) targetDirectory = C:\NCP\NCOServer2\crs-data-crs\target
> [DEBUG] (f) targetJdk = 1.6
> [DEBUG] (f) testSourceRoots = [C:\NCP\NCOServer2\crs-data-crs\src\test\java]
> [DEBUG] (f) typeResolution = false
> [DEBUG] (f) xrefLocation = C:\NCP\NCOServer2\crs-data-crs\target\site\xref
> [DEBUG] (f) xrefTestLocation =
> C:\NCP\NCOServer2\crs-data-crs\target\site\xref-test
> [DEBUG] (f) project = MavenProject: com.cr.crs:crs-data-crs:1.0-SNAPSHOT @
> C:\NCP\NCOServer2\crs-data-crs\pom.xml
> [DEBUG] -- end configuration --
> {code}
> As you can see output encoding is set to UTF-8.
> The top of the pmd.html:
> {code}
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>
> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
>
>
> :
> {code}
> The outputEncoding just doesn't belong there untranslated and I can't figure
> out what I'm doing wrong, if it's something I'm doing wrong!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
Volker Seibt created MJAVADOC-408:
-
Summary: changing maven-javadoc-plugin from version 2.9.1 to 2.10
breaks the build
Key: MJAVADOC-408
URL: https://jira.codehaus.org/browse/MJAVADOC-408
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
Reporter: Volker Seibt
Priority: Blocker
Attachments: console.log, pom.xml, pom.xml
build is startet with {{mvn -U clean deploy -DperformRelease=true}}
and worked fine for several weeks without any changes.
>From today it produces the content of the attached console.log.
We did not specify a version for maven-javadoc-plugin. After secifying
maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
(first pom.xml - parent-pom, second pom.xml of project which breaks the build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Seibt updated MJAVADOC-408:
--
Description:
build is startet with {{mvn -U clean deploy -DperformRelease=true}}
and worked fine for several weeks without any changes.
>From today it produces the content of the attached console.log.
We did not specify a version for maven-javadoc-plugin. After secifying
maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
(pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
build
was:
build is startet with {{mvn -U clean deploy -DperformRelease=true}}
and worked fine for several weeks without any changes.
>From today it produces the content of the attached console.log.
We did not specify a version for maven-javadoc-plugin. After secifying
maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
(first pom.xml - parent-pom, second pom.xml of project which breaks the build
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Blocker
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Seibt updated MJAVADOC-408:
--
Priority: Critical (was: Blocker)
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Critical
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPH-101) API incompatibility while executing maven-help-plugin:effective-settings
[
https://jira.codehaus.org/browse/MPH-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353006#comment-353006
]
Robert Baker commented on MPH-101:
--
No - I am not able to reproduce this issue using maven-help-plugin-2.2 with the
attached pom.xml (modified to use the later version of the help plugin):
[INFO] --- maven-help-plugin:2.2:effective-settings (default-cli) @
test-artifact ---
[INFO] Effective-settings written to: C:\\target\effective-settings.xml
[INFO]
[INFO] BUILD SUCCESS
[INFO]
It only appears to fail with maven-help-plugin-2.1.1.
> API incompatibility while executing maven-help-plugin:effective-settings
>
>
> Key: MPH-101
> URL: https://jira.codehaus.org/browse/MPH-101
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: effective-settings
>Affects Versions: 2.1.1, 2.2
> Environment: Apache Maven 3.2.3
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
> Maven home: C:\\CommonFiles\apache-maven-3.2.3
> Java version: 1.6.0_43, vendor: Sun Microsystems Inc.
> Java home: C:\\CommonFiles\Java\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Robert Baker
>Priority: Minor
> Attachments: pom.xml
>
>
> Running {{mvn help:effective-settings}} works fine whether or not there is a
> {{pom.xml}} in the project directory. However, if the {{pom.xml}} in the
> project directory includes a specific plugin configuration, then this command
> throws an error "An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-help-plugin:2.1.1:effective-settings:
> java.lang.NoSuchMethodError:
> org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;".
> The plugin configuration that causes this error appears to be:
> {code:xml}
>
> org.apache.maven.plugins
> maven-help-plugin
> 2.1.1
>
> ${basedir}/target/effective-settings.xml
>
>
>
> initialize
>
> effective-pom
>
>
>
>
> {code}
> The failure does not occur with Maven 3.1.1, but does occur with Maven 3.2.3.
> To recreate the problem place the attached pom.xml into a directory,
> navigate to the directory and run the command {{"mvn
> help:effective-settings"}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-176) Suppress warning output
[ https://jira.codehaus.org/browse/MSHADE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353009#comment-353009 ] Taylor Jones commented on MSHADE-176: - Awesome! Thanks for the update. > Suppress warning output > --- > > Key: MSHADE-176 > URL: https://jira.codehaus.org/browse/MSHADE-176 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Taylor Jones > Fix For: 2.4 > > Attachments: suppressWarnings_option.patch > > > The warnings Shade outputs are useful, but there are some cases where nothing > can actually be done about them. Recently, I encountered this with the Neo4j > libraries; there is one overlapping class between two critical JARs (kernel > and rest), and no way to resolve this via exclusions. > In these cases, everything works just fine. At best, the warnings are just > noise, but we also have some build processes in place that will fail on Maven > warnings. I figured this would be a pretty simple thing to just suppress, but > Shade doesn't seem to have a way to do this. > I've included a simple patchset to address this which adds a new option to > the configuration called . There isn't a unit test > attached, unfortunately. I'm not quite sure how to unit test logging output > in this fashion without something akin to Mockito. I figured you guys > wouldn't appreciate me adding dependencies out of the blue but if a unit test > is required, I can give it a shot. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353010#comment-353010
]
Sergiu Dumitriu commented on MJAVADOC-408:
--
I can confirm the issue, just noticed the same problem.
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Critical
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-454) copy-dependencies with does NOT copy transitive deps
[
https://jira.codehaus.org/browse/MDEP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353012#comment-353012
]
Tejas Mulay commented on MDEP-454:
--
Hi Robert,
Could you please check now?
> copy-dependencies with does NOT copy transitive deps
> -
>
> Key: MDEP-454
> URL: https://jira.codehaus.org/browse/MDEP-454
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 2.8
> Environment: 1. RHEL 6.5,
> 2. mvn -version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T09:37:52-08:00)
> Maven home: /abc/apache-maven-3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /xyz/jdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-358.14.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Tejas Mulay
>Assignee: Karl-Heinz Marbaise
>Priority: Blocker
> Attachments: console.txt, consumerBanking.zip
>
>
> I would like to copy transitive deps of specific artifacts into a custom
> directory. For that I am using {{copy-dependencies}} goal of dep plugin.
> But the plugin copies only the artifacts which are mentioned in
> {{}} tag and not its transitive deps.
> POM section for reference->
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
> Copying dependencies into ${stage}/${pkg_name_ss}/jars
> package
>
> copy-dependencies
>
>
> false
>
> jbpm-executor,jbpm-runtime-manager
> ${stage}/${pkg_name_ss}/jars
> false
> false
> true
>
>
>
>
> {code}
> It is a blocker for me.
> -Tejas.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-454) copy-dependencies with does NOT copy transitive deps
[
https://jira.codehaus.org/browse/MDEP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tejas Mulay updated MDEP-454:
-
Attachment: consumerBanking.zip
console.txt
Created a test project with spring-rabbit as dep. Added a copy-dep plugin to
copy the artifact to a dir.
Attaching console output as text and entire project in zip file
> copy-dependencies with does NOT copy transitive deps
> -
>
> Key: MDEP-454
> URL: https://jira.codehaus.org/browse/MDEP-454
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
>Affects Versions: 2.8
> Environment: 1. RHEL 6.5,
> 2. mvn -version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T09:37:52-08:00)
> Maven home: /abc/apache-maven-3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /xyz/jdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-358.14.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Tejas Mulay
>Assignee: Karl-Heinz Marbaise
>Priority: Blocker
> Attachments: console.txt, consumerBanking.zip
>
>
> I would like to copy transitive deps of specific artifacts into a custom
> directory. For that I am using {{copy-dependencies}} goal of dep plugin.
> But the plugin copies only the artifacts which are mentioned in
> {{}} tag and not its transitive deps.
> POM section for reference->
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
> Copying dependencies into ${stage}/${pkg_name_ss}/jars
> package
>
> copy-dependencies
>
>
> false
>
> jbpm-executor,jbpm-runtime-manager
> ${stage}/${pkg_name_ss}/jars
> false
> false
> true
>
>
>
>
> {code}
> It is a blocker for me.
> -Tejas.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353013#comment-353013
]
Olivier Lemasle commented on MJAVADOC-408:
--
I have the same problem: the build is ok with maven-javadoc-plugin 2.9.1 and
breaks with 2.10; error message refers to 3rd-party annotations. It seems
exactly the same problem than MJAVADOC-407.
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Critical
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-407) cannot parse annotations : when generating javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353014#comment-353014
]
Olivier Lemasle commented on MJAVADOC-407:
--
I have the same problem and it seems that MJAVADOC-408 duplicates this issue.
Looking to the error {{java.lang.ClassCastException:
com.sun.tools.javadoc.ClassDocImpl cannot be cast to
com.sun.javadoc.AnnotationTypeDoc}}, I've found this useful explanation:
http://stackoverflow.com/questions/44853/why-am-i-getting-a-classcastexception-when-generating-javadocs
Therefore, the regression comes from MJAVADOC-398: build classes (including
3rd-parties dependencies) are not on javadoc classpath anymore.
> cannot parse annotations : when generating javadoc
> ---
>
> Key: MJAVADOC-407
> URL: https://jira.codehaus.org/browse/MJAVADOC-407
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux and windows.
> Maven 3.0.4 , JDK 1.6.0.43
>Reporter: jeff porter
>
> See full issue text at :
> http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
> I'm getting the following error when I do
> mvn clean deploy -DperformRelease=true
> [ERROR] Exit code: 1 - .java:3: package javax.inject does not exist [ERROR]
> import javax.inject.Named; [ERROR] ^ [ERROR]
> TransactionServiceExternalImpl.java:5: cannot find symbol [ERROR] symbol:
> class Named [ERROR] @Named("transactionServiceExternal") [ERROR] ^ [ERROR]
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc
> The POM is this...
> com.xxx
> ts-impl/artifactId>
> 2.4.0-SNAPSHOT
>
>
> javax.inject
> javax.inject
> 1
>
>
> There is only one class...
> import javax.inject.Named;
> @Named("transactionServiceExternal")
> public class TransactionServiceExternalImpl
> {
> }
> I get the error with
> jdk1.5.0_22
> jdk1.6.0_29
> jdk1.6.0_43
> jdk1.6.0_43_32bit
> But NOT with...
> jdk1.7.0_05
> Anyone have any ideas?
> Notes: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
>
> I now know that the reason is that the Maven Javadoc Plugin has changed from
> 2.9.1 to 2.10. and this is the cause of the problem.
> I can see this warning...
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING]
> 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-deploy-plugin is missing.
> By setting the following in my pom
> org.apache.maven.plugins maven-javadoc-plugin 2.9.1 attach-javadocs jar
> I can fix the version back to the last release.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPH-101) API incompatibility while executing maven-help-plugin:effective-settings
[
https://jira.codehaus.org/browse/MPH-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-101:
---
Affects Version/s: (was: 2.2)
> API incompatibility while executing maven-help-plugin:effective-settings
>
>
> Key: MPH-101
> URL: https://jira.codehaus.org/browse/MPH-101
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: effective-settings
>Affects Versions: 2.1.1
> Environment: Apache Maven 3.2.3
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
> Maven home: C:\\CommonFiles\apache-maven-3.2.3
> Java version: 1.6.0_43, vendor: Sun Microsystems Inc.
> Java home: C:\\CommonFiles\Java\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Robert Baker
>Priority: Minor
> Attachments: pom.xml
>
>
> Running {{mvn help:effective-settings}} works fine whether or not there is a
> {{pom.xml}} in the project directory. However, if the {{pom.xml}} in the
> project directory includes a specific plugin configuration, then this command
> throws an error "An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-help-plugin:2.1.1:effective-settings:
> java.lang.NoSuchMethodError:
> org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;".
> The plugin configuration that causes this error appears to be:
> {code:xml}
>
> org.apache.maven.plugins
> maven-help-plugin
> 2.1.1
>
> ${basedir}/target/effective-settings.xml
>
>
>
> initialize
>
> effective-pom
>
>
>
>
> {code}
> The failure does not occur with Maven 3.1.1, but does occur with Maven 3.2.3.
> To recreate the problem place the attached pom.xml into a directory,
> navigate to the directory and run the command {{"mvn
> help:effective-settings"}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[ https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353018#comment-353018 ] Robert Scholte commented on MCHANGES-341: - I agree that we must be careful when specifying parameters, but a connection timeout sounds very general for me. So my choice would be to keep it as the original commit and add to the comments for which issue tracking systems it can be used, i.e just Jira for now. Otherwise we could end up with 5 connectionTimeouts for 5 different issue systems which actually refer to the same thing. > Externalize JIRA server timeout values to the configuration section > --- > > Key: MCHANGES-341 > URL: https://jira.codehaus.org/browse/MCHANGES-341 > Project: Maven Changes Plugin > Issue Type: Improvement >Reporter: Boris Pavlovic >Assignee: Mirko Friedenhagen > Fix For: 2.11 > > > [Based on the StackOverflow > Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583] > > QUESTION: > I have a maven-changes-plugin configured for a build process. Sometimes, JIRA > intranet server is down and the build takes ages waiting for a long timeout > on JIRA. > Is there a way to configure the timeout? > ANSWER: > It does not appear so. The source for the RestJiraDownloader, the class that > queries JIRA for issues, has hard-coded timeout values. Lines 562-566 > indicate a connection timeout of 36 seconds and a receive timeout of 32 > seconds. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPH-101) API incompatibility while executing maven-help-plugin:effective-settings
[
https://jira.codehaus.org/browse/MPH-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPH-101.
--
Resolution: Fixed
Fix Version/s: 2.2
Assignee: Robert Scholte
Fixed in version 2.2
> API incompatibility while executing maven-help-plugin:effective-settings
>
>
> Key: MPH-101
> URL: https://jira.codehaus.org/browse/MPH-101
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: effective-settings
>Affects Versions: 2.1.1
> Environment: Apache Maven 3.2.3
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
> Maven home: C:\\CommonFiles\apache-maven-3.2.3
> Java version: 1.6.0_43, vendor: Sun Microsystems Inc.
> Java home: C:\\CommonFiles\Java\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Robert Baker
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.2
>
> Attachments: pom.xml
>
>
> Running {{mvn help:effective-settings}} works fine whether or not there is a
> {{pom.xml}} in the project directory. However, if the {{pom.xml}} in the
> project directory includes a specific plugin configuration, then this command
> throws an error "An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-help-plugin:2.1.1:effective-settings:
> java.lang.NoSuchMethodError:
> org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;".
> The plugin configuration that causes this error appears to be:
> {code:xml}
>
> org.apache.maven.plugins
> maven-help-plugin
> 2.1.1
>
> ${basedir}/target/effective-settings.xml
>
>
>
> initialize
>
> effective-pom
>
>
>
>
> {code}
> The failure does not occur with Maven 3.1.1, but does occur with Maven 3.2.3.
> To recreate the problem place the attached pom.xml into a directory,
> navigate to the directory and run the command {{"mvn
> help:effective-settings"}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-176) Suppress warning output
[ https://jira.codehaus.org/browse/MSHADE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353016#comment-353016 ] Robert Scholte commented on MSHADE-176: --- What I don't understand is why it doesn't matter if there are 2 of the same classes on the classpath. Only one can be loaded, and that is the first one on the classpath. It would be very nice if you could add an integration-test exposing your issue. > Suppress warning output > --- > > Key: MSHADE-176 > URL: https://jira.codehaus.org/browse/MSHADE-176 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Taylor Jones > Fix For: 2.4 > > Attachments: suppressWarnings_option.patch > > > The warnings Shade outputs are useful, but there are some cases where nothing > can actually be done about them. Recently, I encountered this with the Neo4j > libraries; there is one overlapping class between two critical JARs (kernel > and rest), and no way to resolve this via exclusions. > In these cases, everything works just fine. At best, the warnings are just > noise, but we also have some build processes in place that will fail on Maven > warnings. I figured this would be a pretty simple thing to just suppress, but > Shade doesn't seem to have a way to do this. > I've included a simple patchset to address this which adds a new option to > the configuration called . There isn't a unit test > attached, unfortunately. I'm not quite sure how to unit test logging output > in this fashion without something akin to Mockito. I figured you guys > wouldn't appreciate me adding dependencies out of the blue but if a unit test > is required, I can give it a shot. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-250) NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
[
https://jira.codehaus.org/browse/MCHECKSTYLE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353019#comment-353019
]
Konstantin Pokrovsky commented on MCHECKSTYLE-250:
--
The initial idea was to install checkstyle config as an artifact. Declare it as
a plugin dependency and reuse it straight from repository that every module
could locate the config.
> NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
> --
>
> Key: MCHECKSTYLE-250
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-250
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Konstantin Pokrovsky
>
> *Steps to reproduce:*
> * Add non jar (XML for example) artifact dependency to plugin dependencies
> section:
> {code:xml}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.13
>
>
> anygroup
> anyfile
> xml
>
>
>
> {code}
> * Run _checkstyle:check_
> Result:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
> project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
> (default-cli) on project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check 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: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:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 common frames omitted
> Caused by: java.lang.NullPointerException: null
> at
> org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
> at
> org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:75)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor
[jira] (MCHECKSTYLE-250) NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
[
https://jira.codehaus.org/browse/MCHECKSTYLE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353019#comment-353019
]
Konstantin Pokrovsky edited comment on MCHECKSTYLE-250 at 9/22/14 1:17 PM:
---
The initial idea was to install checkstyle config as an artifact. Declare it as
a plugin dependency and reuse it straight from repository so that every module
could locate the config.
was (Author: kpokrovsky):
The initial idea was to install checkstyle config as an artifact. Declare it as
a plugin dependency and reuse it straight from repository that every module
could locate the config.
> NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
> --
>
> Key: MCHECKSTYLE-250
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-250
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Konstantin Pokrovsky
>
> *Steps to reproduce:*
> * Add non jar (XML for example) artifact dependency to plugin dependencies
> section:
> {code:xml}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.13
>
>
> anygroup
> anyfile
> xml
>
>
>
> {code}
> * Run _checkstyle:check_
> Result:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
> project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
> (default-cli) on project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check 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: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:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 common frames omitted
> Caused by: java.lang.NullPointerException: null
> at
> org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
> at
> org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceMan
[jira] (MCHECKSTYLE-250) NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
[
https://jira.codehaus.org/browse/MCHECKSTYLE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353017#comment-353017
]
Robert Scholte commented on MCHECKSTYLE-250:
I have to agree: it would be better to verify if the artifact is actually a
jar. But AFAIK just adding an xml as artifact won't work for this plugin, so
why would you do so?
> NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
> --
>
> Key: MCHECKSTYLE-250
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-250
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Konstantin Pokrovsky
>
> *Steps to reproduce:*
> * Add non jar (XML for example) artifact dependency to plugin dependencies
> section:
> {code:xml}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.13
>
>
> anygroup
> anyfile
> xml
>
>
>
> {code}
> * Run _checkstyle:check_
> Result:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
> project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
> (default-cli) on project rt: Execution default-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check 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: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:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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-cli of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 common frames omitted
> Caused by: java.lang.NullPointerException: null
> at
> org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
> at
> org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
> at
> org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:75)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:520)
>
[jira] (MDEP-454) copy-dependencies with does NOT copy transitive deps
[
https://jira.codehaus.org/browse/MDEP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEP-454:
Issue Type: Improvement (was: Bug)
> copy-dependencies with does NOT copy transitive deps
> -
>
> Key: MDEP-454
> URL: https://jira.codehaus.org/browse/MDEP-454
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: copy-dependencies
>Affects Versions: 2.8
> Environment: 1. RHEL 6.5,
> 2. mvn -version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T09:37:52-08:00)
> Maven home: /abc/apache-maven-3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /xyz/jdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-358.14.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Tejas Mulay
>Assignee: Karl-Heinz Marbaise
>Priority: Blocker
> Attachments: console.txt, consumerBanking.zip
>
>
> I would like to copy transitive deps of specific artifacts into a custom
> directory. For that I am using {{copy-dependencies}} goal of dep plugin.
> But the plugin copies only the artifacts which are mentioned in
> {{}} tag and not its transitive deps.
> POM section for reference->
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
> Copying dependencies into ${stage}/${pkg_name_ss}/jars
> package
>
> copy-dependencies
>
>
> false
>
> jbpm-executor,jbpm-runtime-manager
> ${stage}/${pkg_name_ss}/jars
> false
> false
> true
>
>
>
>
> {code}
> It is a blocker for me.
> -Tejas.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-454) copy-dependencies with does NOT copy transitive deps
[
https://jira.codehaus.org/browse/MDEP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353020#comment-353020
]
Robert Scholte commented on MDEP-454:
-
Ok, I see what you mean. [~khmarbaise] was right when he said that all
includes/excludes are _filters_ for the whole tree. Your {{includeArtifactId}}
matches exactly 1 artifact. So the plugin works as expected. However, you want
to copy 1 artifact and all its transitive dependencies, which is a fair
request, but I can't find a way to do that right now. Hence, I've changed the
type of this issue to {{improvement}}.
> copy-dependencies with does NOT copy transitive deps
> -
>
> Key: MDEP-454
> URL: https://jira.codehaus.org/browse/MDEP-454
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: copy-dependencies
>Affects Versions: 2.8
> Environment: 1. RHEL 6.5,
> 2. mvn -version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T09:37:52-08:00)
> Maven home: /abc/apache-maven-3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /xyz/jdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-358.14.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Tejas Mulay
>Assignee: Karl-Heinz Marbaise
>Priority: Blocker
> Attachments: console.txt, consumerBanking.zip
>
>
> I would like to copy transitive deps of specific artifacts into a custom
> directory. For that I am using {{copy-dependencies}} goal of dep plugin.
> But the plugin copies only the artifacts which are mentioned in
> {{}} tag and not its transitive deps.
> POM section for reference->
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
> Copying dependencies into ${stage}/${pkg_name_ss}/jars
> package
>
> copy-dependencies
>
>
> false
>
> jbpm-executor,jbpm-runtime-manager
> ${stage}/${pkg_name_ss}/jars
> false
> false
> true
>
>
>
>
> {code}
> It is a blocker for me.
> -Tejas.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353023#comment-353023
]
Meunier Frederic commented on MJAVADOC-408:
---
I encounter the same blocker issue. To fix it, I added the following property
in my POMs:
false
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Critical
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-341) Externalize JIRA server timeout values to the configuration section
[
https://jira.codehaus.org/browse/MCHANGES-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353024#comment-353024
]
Mirko Friedenhagen commented on MCHANGES-341:
-
[~rfscholte], while a general parameter might be feasible in the future, right
now neither Trac nor GitHub are an easy task to tackle as they hide their
clients very deeply. In the spirit of releasing more often, I would go for the
{{jira*}} solution and when we have a more general solution to take the
unprefixed parameters as defaults for the other ones.
> Externalize JIRA server timeout values to the configuration section
> ---
>
> Key: MCHANGES-341
> URL: https://jira.codehaus.org/browse/MCHANGES-341
> Project: Maven Changes Plugin
> Issue Type: Improvement
>Reporter: Boris Pavlovic
>Assignee: Mirko Friedenhagen
> Fix For: 2.11
>
>
> [Based on the StackOverflow
> Question|http://stackoverflow.com/questions/25626369/how-to-configure-timeout-for-maven-changes-plugin/25627583#25627583]
>
> QUESTION:
> I have a maven-changes-plugin configured for a build process. Sometimes, JIRA
> intranet server is down and the build takes ages waiting for a long timeout
> on JIRA.
> Is there a way to configure the timeout?
> ANSWER:
> It does not appear so. The source for the RestJiraDownloader, the class that
> queries JIRA for issues, has hard-coded timeout values. Lines 562-566
> indicate a connection timeout of 36 seconds and a receive timeout of 32
> seconds.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] [Resolved] (MPOM-58) Pom calls for yet another version of maven-release-plugin to deal with more git problems
[ https://issues.apache.org/jira/browse/MPOM-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved MPOM-58. -- Resolution: Fixed Done in r1626879. > Pom calls for yet another version of maven-release-plugin to deal with more > git problems > > > Key: MPOM-58 > URL: https://issues.apache.org/jira/browse/MPOM-58 > Project: Maven POMs > Issue Type: Bug >Affects Versions: ASF-14 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: ASF-15 > > > MRELEASE-875 is another problem with git that prevents work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MSHADE-176) Suppress warning output
[ https://jira.codehaus.org/browse/MSHADE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353025#comment-353025 ] Taylor Jones commented on MSHADE-176: - Well, in our particular case, it's an overlap of one class between two Neo4J libraries. The only difference in the class in this case was that one had a final declaration. Since we don't have control over the libraries, we can't remove it and we get a warning from Shade every time. That being said, the patch is simply to suppress the warning output. I'm not sure what an integration test would show here. > Suppress warning output > --- > > Key: MSHADE-176 > URL: https://jira.codehaus.org/browse/MSHADE-176 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Taylor Jones > Fix For: 2.4 > > Attachments: suppressWarnings_option.patch > > > The warnings Shade outputs are useful, but there are some cases where nothing > can actually be done about them. Recently, I encountered this with the Neo4j > libraries; there is one overlapping class between two critical JARs (kernel > and rest), and no way to resolve this via exclusions. > In these cases, everything works just fine. At best, the warnings are just > noise, but we also have some build processes in place that will fail on Maven > warnings. I figured this would be a pretty simple thing to just suppress, but > Shade doesn't seem to have a way to do this. > I've included a simple patchset to address this which adds a new option to > the configuration called . There isn't a unit test > attached, unfortunately. I'm not quite sure how to unit test logging output > in this fashion without something akin to Mockito. I figured you guys > wouldn't appreciate me adding dependencies out of the blue but if a unit test > is required, I can give it a shot. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] [Commented] (MPOM-58) Pom calls for yet another version of maven-release-plugin to deal with more git problems
[ https://issues.apache.org/jira/browse/MPOM-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143837#comment-14143837 ] Hudson commented on MPOM-58: FAILURE: Integrated in ASF Parent Pom #108 (See [https://builds.apache.org/job/ASF%20Parent%20Pom/108/]) MPOM-58: Pom calls for yet another version of maven-release-plugin to deal with more git problems (bimargulies: http://svn.apache.org/viewvc/?view=rev&rev=1626879) * /maven/pom/trunk/asf/pom.xml > Pom calls for yet another version of maven-release-plugin to deal with more > git problems > > > Key: MPOM-58 > URL: https://issues.apache.org/jira/browse/MPOM-58 > Project: Maven POMs > Issue Type: Bug >Affects Versions: ASF-14 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: ASF-15 > > > MRELEASE-875 is another problem with git that prevents work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353030#comment-353030
]
Darius Jazayeri commented on MJAVADOC-408:
--
This is breaking our builds for OpenMRS.
E.g. this revision of code failed today when I tried to release it (using maven
release):
https://github.com/openmrs/openmrs-module-appframework/tree/839a00603cefc7be4120cb2ff5de3e2fce00348d
For now we will manually specify the 2.9.1 version of the plugin in our
pluginManagement sections, like this:
https://github.com/openmrs/openmrs-module-appframework/commit/fd2db0822024b4292530fb5fa9c4fcd643b66d71
However this is going to be a huge pain to do to 50 maven projects.
Yes, I know we're supposed to already be specifying versions of every plugin,
but...the javadoc one? :-)
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Critical
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[
https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353033#comment-353033
]
David Liszewski commented on MJAVADOC-408:
--
FWIW, the issue is being reported on StackOverflow as well:
http://stackoverflow.com/questions/25983852/maven-javadoc-plugin-breaks-mvn-releaseperform/25986409#25986409
> changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
> -
>
> Key: MJAVADOC-408
> URL: https://jira.codehaus.org/browse/MJAVADOC-408
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5
>Reporter: Volker Seibt
>Priority: Critical
> Attachments: console.log, pom.xml, pom.xml
>
>
> build is startet with {{mvn -U clean deploy -DperformRelease=true}}
> and worked fine for several weeks without any changes.
> From today it produces the content of the attached console.log.
> We did not specify a version for maven-javadoc-plugin. After secifying
> maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again.
> (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the
> build
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-454) copy-dependencies with does NOT copy transitive deps
[
https://jira.codehaus.org/browse/MDEP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353034#comment-353034
]
Tejas Mulay commented on MDEP-454:
--
When false is mentioned in
configuration, it means plugin is supposed to copy transitive deps. No?
> copy-dependencies with does NOT copy transitive deps
> -
>
> Key: MDEP-454
> URL: https://jira.codehaus.org/browse/MDEP-454
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: copy-dependencies
>Affects Versions: 2.8
> Environment: 1. RHEL 6.5,
> 2. mvn -version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T09:37:52-08:00)
> Maven home: /abc/apache-maven-3.2.1
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /xyz/jdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-358.14.1.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Tejas Mulay
>Assignee: Karl-Heinz Marbaise
>Priority: Blocker
> Attachments: console.txt, consumerBanking.zip
>
>
> I would like to copy transitive deps of specific artifacts into a custom
> directory. For that I am using {{copy-dependencies}} goal of dep plugin.
> But the plugin copies only the artifacts which are mentioned in
> {{}} tag and not its transitive deps.
> POM section for reference->
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
> Copying dependencies into ${stage}/${pkg_name_ss}/jars
> package
>
> copy-dependencies
>
>
> false
>
> jbpm-executor,jbpm-runtime-manager
> ${stage}/${pkg_name_ss}/jars
> false
> false
> true
>
>
>
>
> {code}
> It is a blocker for me.
> -Tejas.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-61) Upgrade Locator URL logic to use maven-wagon.
[ https://jira.codehaus.org/browse/MCHECKSTYLE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353038#comment-353038 ] Arlo Louis O'Keeffe commented on MCHECKSTYLE-61: Is there any timeline for this and MCHECKSTYLE-42? It sucks to see new releases and bugs like these are hanging around since 2006. > Upgrade Locator URL logic to use maven-wagon. > - > > Key: MCHECKSTYLE-61 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-61 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Reporter: Joakim Erdfelt > Labels: plexus-resources > > Upgrade the URL location logic in the Locator to utilize the maven-wagon api. > Current logic utilizes the java URL object. > Using maven-wagon, will allow for many more potential sources, as well as > greater authorization and proxy abilities already built into maven. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-70) Support for multiple source folders
[
https://jira.codehaus.org/browse/MCHECKSTYLE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353039#comment-353039
]
Arlo Louis O'Keeffe commented on MCHECKSTYLE-70:
How does this deal with generated sources?
> Support for multiple source folders
> ---
>
> Key: MCHECKSTYLE-70
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-70
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Jan Palmquist
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.13
>
>
> It would be great if this plugin would support multiple source folders added
> by http://mojo.codehaus.org/build-helper-maven-plugin/ (or similar), and by
> default inspect sources from these folders instead of just
> ${project.build.sourceDirectory}. Correspondingly with respect to test
> sources if those are configured to be included.
> There are other plugins available solving this problem (somehow), eg:
> * http://mojo.codehaus.org/jdepend-maven-plugin/
> * http://mojo.codehaus.org/findbugs-maven-plugin/
> Maybe they can give some inspiration for how to make this possible?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
