[jira] (MJAVADOC-365) [Patch] sourceFileExcludes does not work due to inclusion of packages
[ https://jira.codehaus.org/browse/MJAVADOC-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354140#comment-354140 ] Savas Ali Tokmen commented on MJAVADOC-365: --- Thanks, everyone :) Is there a target date for the Javadoc plugin's 2.11 release? > [Patch] sourceFileExcludes does not work due to inclusion of packages > - > > Key: MJAVADOC-365 > URL: https://jira.codehaus.org/browse/MJAVADOC-365 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Michael Bayne >Assignee: Robert Scholte > Fix For: 2.11 > > Attachments: MJAVADOC-365-REC-2014-10-09-a.patch, > MJAVADOC-365-REC-2014-10-09.patch, patch > > > If you specify sourceFileExcludes for Javadoc generation, they are ignored, > because the plugin always supplies a list of packages to Javadoc instead of a > list of source files. > This is easily remedied with the attached patch. It causes the plugin to > switch to "pass a list of source files to Javadoc" mode if any > sourceFileExcludes are supplied. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-365) [Patch] sourceFileExcludes does not work due to inclusion of packages
[ https://jira.codehaus.org/browse/MJAVADOC-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350544#comment-350544 ] Savas Ali Tokmen commented on MJAVADOC-365: --- It would be good if this could be integrated into the Javadoc plugin - else, the generated Maven2/Maven3 artifacts cannot be released with a JDK 8 > [Patch] sourceFileExcludes does not work due to inclusion of packages > - > > Key: MJAVADOC-365 > URL: https://jira.codehaus.org/browse/MJAVADOC-365 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Michael Bayne > Attachments: patch > > > If you specify sourceFileExcludes for Javadoc generation, they are ignored, > because the plugin always supplies a list of packages to Javadoc instead of a > list of source files. > This is easily remedied with the attached patch. It causes the plugin to > switch to "pass a list of source files to Javadoc" mode if any > sourceFileExcludes are supplied. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5563) Ensuring only the available parameters are allowed
[
https://jira.codehaus.org/browse/MNG-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338767#comment-338767
]
Savas Ali Tokmen commented on MNG-5563:
---
Sometimes it is not just even misspelling - it can also be a parameter which
has been renamed, or even removed, which won't trigger any warning nor error in
the current situation; which might also become a "trap".
> Ensuring only the available parameters are allowed
> --
>
> Key: MNG-5563
> URL: https://jira.codehaus.org/browse/MNG-5563
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Reporter: Savas Ali Tokmen
>
> I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin;
> and would have an improvement request with regards to how parameters are
> managed.
> Currently, what happens is that if a user unwillingly puts a parameter in the
> wrong place then the plugin execution continues as is. One of the latest such
> issues one of the users has had can be found on
> http://cargo.996258.n3.nabble.com/Maven-plugin-and-javaagent-tp18075.html
> As an example, I can write the below POM and build still works (even thought
> the MOJO has no parameter called "foo"):
> {noformat}
>
> org.codehaus.cargo
> cargo-maven2-plugin
> 1.4.6
>
>
> bar
>
>
>
> {noformat}
> It would be good for the MOJO developer to be ablo instruct by MOJO to fail
> if there is an unknown parameter in the configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5563) Ensuring only the available parameters are allowed
Savas Ali Tokmen created MNG-5563:
-
Summary: Ensuring only the available parameters are allowed
Key: MNG-5563
URL: https://jira.codehaus.org/browse/MNG-5563
Project: Maven 2 & 3
Issue Type: Improvement
Components: POM
Reporter: Savas Ali Tokmen
I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin; and
would have an improvement request with regards to how parameters are managed.
Currently, what happens is that if a user unwillingly puts a parameter in the
wrong place then the plugin execution continues as is. One of the latest such
issues one of the users has had can be found on
http://cargo.996258.n3.nabble.com/Maven-plugin-and-javaagent-tp18075.html
As an example, I can write the below POM and build still works (even thought
the MOJO has no parameter called "foo"):
{noformat}
org.codehaus.cargo
cargo-maven2-plugin
1.4.6
bar
{noformat}
It would be good for the MOJO developer to be ablo instruct by MOJO to fail if
there is an unknown parameter in the configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-156) Plugin fails to build on Mac OS
[
http://jira.codehaus.org/browse/MCHECKSTYLE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260475#action_260475
]
Savas Ali Tokmen commented on MCHECKSTYLE-156:
--
Fixing this is as easy as:
{noformat}
com.puppycrawl.tools
checkstyle
5.3
com.sun
tools
{noformat}
> Plugin fails to build on Mac OS
> ---
>
> Key: MCHECKSTYLE-156
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-156
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: Mac OS X 10.6.6, java version "1.6.0_22"
>Reporter: Lukas Theussl
>
> Trying to build the plugin on Mac fails:
> {noformat}
> [ERROR] Failed to execute goal on project maven-checkstyle-plugin: Could not
> resolve dependencies for project
> org.apache.maven.plugins:maven-checkstyle-plugin:maven-plugin:2.7-SNAPSHOT:
> Could not find artifact com.sun:tools:jar:1.5.0 at specified path
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar
> -> [Help 1]
> {noformat}
> The reason is apparently that the [checkstyle
> pom|http://repo1.maven.org/maven2/com/puppycrawl/tools/checkstyle/5.3/checkstyle-5.3.pom]
> declares a system dependency
> {code:xml}
>
> com.sun
> tools
> 1.5.0
> system
> ${java.home}/../lib/tools.jar
>
> {code}
> which does not exist on Mac. On Mac OS, the tools.jar classes are included in
> classes.jar. There's no need for a systemPath dependency on Mac OS, all
> required classes are already in the runtime classes.jar.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCHECKSTYLE-134) suppressionsFileExpression does not work - cannot initialize module SuppressionFilter
[
http://jira.codehaus.org/browse/MCHECKSTYLE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250875#action_250875
]
Savas Ali Tokmen edited comment on MCHECKSTYLE-134 at 1/8/11 9:56 AM:
--
Thank you for the workaround.
BTW, why isn't the patch applied yet?
was (Author: alitokmen):
Thank you for the workaround
> suppressionsFileExpression does not work - cannot initialize module
> SuppressionFilter
> -
>
> Key: MCHECKSTYLE-134
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-134
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Felix Röthenbacher
> Attachments: MCHECKSTYLE-134.diff.txt
>
>
> Setting the checkstyle.suppressions.file property through
> suppressionsFileExpression doesn't work:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file
>
> Output:
> [INFO] Failed during checkstyle configuration
>
>
> Embedded error: cannot initialize module SuppressionFilter - Cannot set
> property 'file' in module SuppressionFilter to
> 'checkstyle.suppressions.file': unable to find checkstyle.suppressions.file
> checkstyle.suppressions.file (No such file or directory)
> -
> Workaround:
> Using a different property name for suppressionsFileExpression and setting
> property manually works though:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file.donothing
>
> checkstyle.suppressions.file=${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-134) suppressionsFileExpression does not work - cannot initialize module SuppressionFilter
[
http://jira.codehaus.org/browse/MCHECKSTYLE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250875#action_250875
]
Savas Ali Tokmen commented on MCHECKSTYLE-134:
--
Thank you for the workaround
> suppressionsFileExpression does not work - cannot initialize module
> SuppressionFilter
> -
>
> Key: MCHECKSTYLE-134
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-134
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Felix Röthenbacher
> Attachments: MCHECKSTYLE-134.diff.txt
>
>
> Setting the checkstyle.suppressions.file property through
> suppressionsFileExpression doesn't work:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file
>
> Output:
> [INFO] Failed during checkstyle configuration
>
>
> Embedded error: cannot initialize module SuppressionFilter - Cannot set
> property 'file' in module SuppressionFilter to
> 'checkstyle.suppressions.file': unable to find checkstyle.suppressions.file
> checkstyle.suppressions.file (No such file or directory)
> -
> Workaround:
> Using a different property name for suppressionsFileExpression and setting
> property manually works though:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file.donothing
>
> checkstyle.suppressions.file=${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
