[jira] [Updated] (MJAVADOC-564) Generated javadoc tags in fix goal are not in proper order
[
https://issues.apache.org/jira/browse/MJAVADOC-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Sand updated MJAVADOC-564:
--
Description:
The javadoc:fix goal is placing/moving the @throws tags to the bottom of the
tags, which isn't the proper order if there is a since tag.
Example:
{{ /**}}
{{ * initialize.}}
{{ *}}
{{ * @param keyClass a \{@link java.lang.Class} object.}}
{{ * @param valueClass a \{@link java.lang.Class} object.}}
{{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
{{ * @since 3.1.4}}
{{ */}}
Get changed to:
{{ /**}}
{{ * initialize.}}
{{ *}}
{{ * @param keyClass a \{@link java.lang.Class} object.}}
{{ * @param valueClass a \{@link java.lang.Class} object.}}
{{ * @since 3.1.4}}
{{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
{{ */}}
The exact order of tags is documented here for reference:
[https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#orderoftags]
was:
The javadoc:fix goal is placing/moving the @throws tags to the bottom of the
tags, which isn't the proper order if there is a since tag.
Example: {{}}
{{ /**}}
{{ * initialize.}}
{{ *}}
{{ * @param keyClass a \{@link java.lang.Class} object.}}
{{ * @param valueClass a \{@link java.lang.Class} object.}}
{{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
{{ * @since 3.1.4}}
{{ */}}
Get changed to:
{{ /**}}
{{ * initialize.}}
{{ *}}
{{ * @param keyClass a \{@link java.lang.Class} object.}}
{{ * @param valueClass a \{@link java.lang.Class} object.}}
{{ * @since 3.1.4}}
{{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
{{*/}}
The exact order of tags is documented here for reference:
[https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#orderoftags]
> Generated javadoc tags in fix goal are not in proper order
> --
>
> Key: MJAVADOC-564
> URL: https://issues.apache.org/jira/browse/MJAVADOC-564
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: fix
>Affects Versions: 2.10.4, 3.0.1
>Reporter: Richard Sand
>Priority: Major
>
> The javadoc:fix goal is placing/moving the @throws tags to the bottom of the
> tags, which isn't the proper order if there is a since tag.
> Example:
> {{ /**}}
> {{ * initialize.}}
> {{ *}}
> {{ * @param keyClass a \{@link java.lang.Class} object.}}
> {{ * @param valueClass a \{@link java.lang.Class} object.}}
> {{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
> {{ * @since 3.1.4}}
> {{ */}}
> Get changed to:
> {{ /**}}
> {{ * initialize.}}
> {{ *}}
> {{ * @param keyClass a \{@link java.lang.Class} object.}}
> {{ * @param valueClass a \{@link java.lang.Class} object.}}
> {{ * @since 3.1.4}}
> {{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
> {{ */}}
> The exact order of tags is documented here for reference:
> [https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#orderoftags]
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-564) Generated javadoc tags in fix goal are not in proper order
Richard Sand created MJAVADOC-564:
-
Summary: Generated javadoc tags in fix goal are not in proper order
Key: MJAVADOC-564
URL: https://issues.apache.org/jira/browse/MJAVADOC-564
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: fix
Affects Versions: 3.0.1, 2.10.4
Reporter: Richard Sand
The javadoc:fix goal is placing/moving the @throws tags to the bottom of the
tags, which isn't the proper order if there is a since tag.
Example: {{}}
{{ /**}}
{{ * initialize.}}
{{ *}}
{{ * @param keyClass a \{@link java.lang.Class} object.}}
{{ * @param valueClass a \{@link java.lang.Class} object.}}
{{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
{{ * @since 3.1.4}}
{{ */}}
Get changed to:
{{ /**}}
{{ * initialize.}}
{{ *}}
{{ * @param keyClass a \{@link java.lang.Class} object.}}
{{ * @param valueClass a \{@link java.lang.Class} object.}}
{{ * @since 3.1.4}}
{{ * @throws com.idfconnect.ssorest.cache.CacheException if any.}}
{{*/}}
The exact order of tags is documented here for reference:
[https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#orderoftags]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-559) Extra duplicate "throws" tags added to methods with same names
[
https://issues.apache.org/jira/browse/MJAVADOC-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731029#comment-16731029
]
Richard Sand commented on MJAVADOC-559:
---
Sorry - something is different between the 452 branch and master - the problem
about having multiple methods with overlapping names causing an infinite loop -
e.g. “getValue” and “getValueAsInt”. I ran a test against the master and the
problem still existed, and then I ran it against the 452 branch and the problem
was fixed, so I thought that perhaps it hadn’t been merged. I’ll look further
tonight and at least provide a test case.
-Richard
> Extra duplicate "throws" tags added to methods with same names
> --
>
> Key: MJAVADOC-559
> URL: https://issues.apache.org/jira/browse/MJAVADOC-559
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: fix
>Affects Versions: 2.10.4, 3.0.1
>Reporter: Richard Sand
>Priority: Major
>
> This was one of the bugs I'd submitted a patch for in MJAVADOC-452. In that
> patch I had added a change buffer so that the javadoc output for each method
> would be queued up, stripped of duplicates, and sorted before writing. I
> think we still need that logic. Consider the class below, where i have a
> method getFirstValue and two methods getFirstValueAsInt. The latter both have
> a proper declaration of throws NFE, but then each gets an extra declaration
> at the end of the javadoc block. I ran this test using the MJAVADOC-452
> branch:
> {code}
> /**
> * Method getFirstValue.
> *
> * @param key
> * String
> * @param defaultValue
> * a {@link java.lang.String} object.
> * @return String
> * @since 2.7.3
> */
> public String getFirstValue(String key, String defaultValue) {
> ...
> }
> /**
> * Method getFirstValueAsInt.
> *
> * @param key
> * String
> * @return int
> * @throws java.lang.NumberFormatException
> * if the value is not an integer
> * @since 3.0
> * @throws java.lang.NumberFormatException if any.
> */
> public int getFirstValueAsInt(String key) throws NumberFormatException {
> ...
> }
> /**
> * NOTE: this method returns the defaultValue if the stored value is null
> OR an empty string
> *
> * @param key
> * String
> * @param defaultValue
> * a int.
> * @return int
> * @throws java.lang.NumberFormatException
> * if the value is not an integer
> * @since 3.0
> * @throws java.lang.NumberFormatException if any.
> */
> public int getFirstValueAsInt(String key, int defaultValue) throws
> NumberFormatException {
> ...
> }
> {code}
> Robert would you like me to create a patch for this or to do it yourself? If
> you could merge the 452 branch into master I can do a pull from master. Or I
> could pull from 452. Let me know if you'd like some help here. Thanks!
>
> Best regards,
> Richard
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-559) Extra duplicate "throws" tags added to methods with same names
[
https://issues.apache.org/jira/browse/MJAVADOC-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731006#comment-16731006
]
Richard Sand commented on MJAVADOC-559:
---
Makes sense. When will you merge the 452 branch into master? I can do a pull
from that.
I verified that the 452 branch fixed the problem of repeating elements, good
stuff!
-Richard
> Extra duplicate "throws" tags added to methods with same names
> --
>
> Key: MJAVADOC-559
> URL: https://issues.apache.org/jira/browse/MJAVADOC-559
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: fix
>Affects Versions: 2.10.4, 3.0.1
>Reporter: Richard Sand
>Priority: Major
>
> This was one of the bugs I'd submitted a patch for in MJAVADOC-452. In that
> patch I had added a change buffer so that the javadoc output for each method
> would be queued up, stripped of duplicates, and sorted before writing. I
> think we still need that logic. Consider the class below, where i have a
> method getFirstValue and two methods getFirstValueAsInt. The latter both have
> a proper declaration of throws NFE, but then each gets an extra declaration
> at the end of the javadoc block. I ran this test using the MJAVADOC-452
> branch:
> {code}
> /**
> * Method getFirstValue.
> *
> * @param key
> * String
> * @param defaultValue
> * a {@link java.lang.String} object.
> * @return String
> * @since 2.7.3
> */
> public String getFirstValue(String key, String defaultValue) {
> ...
> }
> /**
> * Method getFirstValueAsInt.
> *
> * @param key
> * String
> * @return int
> * @throws java.lang.NumberFormatException
> * if the value is not an integer
> * @since 3.0
> * @throws java.lang.NumberFormatException if any.
> */
> public int getFirstValueAsInt(String key) throws NumberFormatException {
> ...
> }
> /**
> * NOTE: this method returns the defaultValue if the stored value is null
> OR an empty string
> *
> * @param key
> * String
> * @param defaultValue
> * a int.
> * @return int
> * @throws java.lang.NumberFormatException
> * if the value is not an integer
> * @since 3.0
> * @throws java.lang.NumberFormatException if any.
> */
> public int getFirstValueAsInt(String key, int defaultValue) throws
> NumberFormatException {
> ...
> }
> {code}
> Robert would you like me to create a patch for this or to do it yourself? If
> you could merge the 452 branch into master I can do a pull from master. Or I
> could pull from 452. Let me know if you'd like some help here. Thanks!
>
> Best regards,
> Richard
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-559) Extra duplicate "throws" tags added to methods with same names
Richard Sand created MJAVADOC-559:
-
Summary: Extra duplicate "throws" tags added to methods with same
names
Key: MJAVADOC-559
URL: https://issues.apache.org/jira/browse/MJAVADOC-559
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: fix
Affects Versions: 3.0.1, 2.10.4
Reporter: Richard Sand
This was one of the bugs I'd submitted a patch for in MJAVADOC-452. In that
patch I had added a change buffer so that the javadoc output for each method
would be queued up, stripped of duplicates, and sorted before writing. I think
we still need that logic. Consider the class below, where i have a method
getFirstValue and two methods getFirstValueAsInt. The latter both have a proper
declaration of throws NFE, but then each gets an extra declaration at the end
of the javadoc block. I ran this test using the MJAVADOC-452 branch:
{{/**}}
{{ * Method getFirstValue.}}
{{ *}}
{{ * @param key}}
{{ * String}}
{{ * @param defaultValue}}
{{ * a \{@link java.lang.String} object.}}
{{ * @return String}}
{{ * @since 2.7.3}}
{{ */}}
{{ public String getFirstValue(String key, String defaultValue) {}}
{{...}}
{{}}}
{{/**}}
{{ * Method getFirstValueAsInt.}}
{{ *}}
{{ * @param key}}
{{ * String}}
{{ * @return int}}
{{ * @throws java.lang.NumberFormatException}}
{{ * if the value is not an integer}}
{{ * @since 3.0}}
{{ {color:#FF}* @throws java.lang.NumberFormatException if any.{color}}}
{{*/}}
{{ public int getFirstValueAsInt(String key) throws NumberFormatException {}}
{{...}}
{{}}}
{{/**}}
{{ * NOTE: this method returns the defaultValue if the stored value is null
OR an empty string}}
{{ *}}
{{ * @param key}}
{{ * String}}
{{ * @param defaultValue}}
{{ * a int.}}
{{ * @return int}}
{{ * @throws java.lang.NumberFormatException}}
{{ * if the value is not an integer}}
{{ * @since 3.0}}
{{ {color:#FF}* @throws java.lang.NumberFormatException if any.{color}}}
{{ */}}
{{ public int getFirstValueAsInt(String key, int defaultValue) throws
NumberFormatException {}}
{{...}}
{{}}}
Robert would you like me to create a patch for this or to do it yourself? If
you could merge the 452 branch into master I can do a pull from master. Or I
could pull from 452. Let me know if you'd like some help here. Thanks!
Best regards,
Richard
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15935655#comment-15935655 ] Richard Sand commented on MDEPLOY-131: -- By that logic Robert, you should remove the "pomFile" parameter from the deploy-file goal. It only leads to abuse. Just like you should remove the automatic update from the javadoc plugin, or require it to be explicitly invoked like deploy-file, because adding a skip smells so bad too. Maven *is* a complex tool. If you want to constrain how people use it and not only adopt your tool but adopt your philosophies, then dumb it down. But maven isn't that - its a powerful can-do-almost-anything tool. If I want simplicity and a single formulaic method, there are certainly simpler and more straightforward tools out there. But you seem to want to dictate process as well, and keep all of your users in line. I guess you know our businesses best? > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934013#comment-15934013 ] Richard Sand commented on MDEPLOY-131: -- Hi Robert - i admit my frustration is showing. But my question is still unanswered - forget my use case for a moment. Forget I mentioned anything about deploying multiple shaded artifacts. Just tell me your opinion on the following: 1) the deploy module does not have the ability to inherit the URL from the project - this is a useful feature to have and is doable with a dozen lines of code and an option to enable it 2) the patch is here already 3) including me, there are 5 people who have asked for this feature on this ticket Why would you *not* accept it? > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931934#comment-15931934 ] Richard Sand commented on MDEPLOY-131: -- Hi Karl - my customers are using COTS products and often don't even have in-house Java developers. They don't know or care what slf4j is. If you want to tell them to read the slf4j docs feel free to :-). But to answer your question, yes I am using 3 different executions of shade, install-file, and deploy-file in my POM to build the different variations of the main artifact. I am truly baffled by the maven project's philosophy that it is not acceptable for organizations to use maven tools as those orgs see fit. I've hit this barrier before in the maven community with something as trivial as adding a "skip" parameter to one of the few plugin goals that actually didn't have one. Instead of looking at the feature at face value and deciding if it is useful, instead the response is "well why do you need that? stop doing things the way you are and instead do them as we prescribe". I avoid multi-module projects whenever I can. My company has used maven exclusively for its projects since 2010. I invite you to take over writing and maintaining all of our POMs, documenting them, educating our developers, etc. Would you do that for me? :-) Otherwise, can you tell me why you would reject this patch on its face value, rather than making me justify why I'd dare ask about it and submit such a patch? I've never opened an issue on Jira simply asking for some feature - every ticket I've opened over the years has been accompanied by a patch. I don't expect others to just do work for me - I contribute where I can. I follow every e-mail on the maven-dev and users list. I know the hell that the project has gone through with 3.4/3.5 and some of the soul-searching that has gone on within the maven team. I love this tool, but I think the maven team killing itself by trying to dictate to users the one-and-only way it should be used, and rejecting updates by telling users they can re-tool how they do things rather than accept a 10-line patch. I've contributed to other open source projects in the past, including Apache projects, and never had such negativity towards submissions. I truly do not understand it. Maybe the "silence" on the Jira isn't a good thing? I now maintain 4 different plugins in my company's repo for trivial patches that make our company's maven implementation stronger, but I've given up getting dragged into philosophical arguments and having to justify how we've done things. Sorry for the rant. -Richard > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931911#comment-15931911 ] Richard Sand commented on MDEPLOY-131: -- Hi Karl - I could make a multi-module project, but why when there is a very simple capability that can let me avoid that and have 1 POM build everything I need? If you take a look at the patch its hardly anything at all and adds a capability that is useful and that others have requested. Regarding the slf4j - there are situations where my customers want a single jar that can be dropped into their application without a single other dependency, which is really the use case for shaded jars in the first place. And they are not familiar with slf4j, so I provide a shaded jar that has slf4j and for example slf4j-jcl or slf4j-jul, so that they can continue to run with whatever log framework they're already using without needing any other jar than the single that our product provides. > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931902#comment-15931902 ] Richard Sand commented on MDEPLOY-131: -- In other words, I'm not replacing the default artifact or default pom, but using shade to create alternative variants with different dependencies and using deploy-file to deploy them all > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931898#comment-15931898 ] Richard Sand commented on MDEPLOY-131: -- Hi Karl - thanks for the quick reply, but the example you posted doesn't address the use case I've described. I'm not building different dev-vs-prod artifacts. I need *all* of the artifacts to be in our repo, the original jar and the shaded uber-jars, and they cannot be under the same artifact ID otherwise they have the same POM and same dependencies. Each shaded artifact produced needs to be deployed along with it's unique dependency-reduced-pom. > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MDEPLOY-131: - Attachment: maven-deploy-useProjectRepo-20170319.patch Adds new optional (default false) parameter "useProjectRepository". Code is commented and passes junit tests, checkstyle etc. > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931887#comment-15931887 ] Richard Sand commented on MDEPLOY-131: -- This thread has been inactive for a couple of years, but I'm guessing that the need for deploy-file to be able to use the existing project's default repositories is still out there. I've attached a very simple patch to enable this without changing the existing behavior of any current deployments. See the attachment "maven-deploy-useProjectRepo-20170319.patch" The patch adds a new configuration parameter called "useProjectRepository" (default false of course). When set to true, it will use the project's default artifactresolver. It changes "url" from required to optional, but throws an error if "url" is missing and "useProjectRepository" isn't explicitly set to true, so it won't disrupt any current behavior. I've used this new parameter in two of my company's projects to good effect. I use it in combination with maven shade plugin, to create multiple permutations of a shaded jar that includes different log capabilities (e.g. one has slf4j and slf4j-jcl, another has slf4j and jcl-over-slf4j, one has only slf4j, etc). I allow the shade plugin to create the dependency reduced pom, then deploy-file to attach the alternate jar and pom to a different artifact ID. It works great! -Richard > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MSHADE-229) Add ability for ServicesResourceTransformer to rename files
[ https://issues.apache.org/jira/browse/MSHADE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414642#comment-15414642 ] Richard Sand commented on MSHADE-229: - Agreed, sorry it is a duplicate of 221. Hopefully the patch gets incorporated soon. > Add ability for ServicesResourceTransformer to rename files > --- > > Key: MSHADE-229 > URL: https://issues.apache.org/jira/browse/MSHADE-229 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.4.3 >Reporter: Richard Sand > Attachments: shade srt.patch > > > The ServicesResoureTransformer can transform the contents of files in > META-INF/services - however, often the names of these files also follow the > package hierarchy. Simple example is commons-logging, where it creates a > service META-INF/services/org.apache.commons.logging.LogFactory containing > the full name of the default LogFactory class. So in addition to transforming > the file contents, we want to transform the file names as well. > Sometimes this is a requirement to create a working shaded jar. For example, > if you are using Jersey JAX-RS, or any project using Glassfish HK2, you will > find that your shaded jar fails because these services files are now expected > to have been renamed along with the class relocation rules. > I've added a patch to this case that augments ServicesResourceTransformer to > add this capability. It adds a new Boolean "renamFiles" - which defaults to > "false" to preserve existing functionality. But when sent to true, it will > send each resource filename through the relocators, so that > "META-INF\services\org.glassfish.hk2.extension.ServiceLocatorGenerator" is > renamed to > "com.idfconnect.relocated.org.glassfish.hk2.extension.ServiceLocatorGenerator", > as well as having its contents updated as well. With this fix In place, I've > easily encapsulated Jersey and my logging framework into a shaded jar that > works just fine. > The fix is very easy and only a few lines of code and provides a useful new > feature. I hope the development community agrees and accepts this patch into > the next release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-470) fix goal corrupts file if no newline before end-comment tag
[ https://issues.apache.org/jira/browse/MJAVADOC-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-470: -- Description: If a method comment has the end-comment tag without a preceding newline, the next method processed will become corrupted. I've attached a simple java file to this case that demonstrates the problem. In short, if Method1 has a comment like: /** * This javadoc has no newline before the end-comment token * * @throws UnsupportedEncodingException * if UTF-8 is not supported */ then Method2's javadoc will be broken. The actual cause seems to be within the QDox library, where the library doesn't properly set the line number where the actual method begins. was: If a method comment has the end-comment tag without a preceding newline, the next method processed will become corrupted. I've attached a simple java file to this case that demonstrates the problem. In short, if Method1 has a comment like: /** * This javadoc has no newline before the end-comment token * * @throws UnsupportedEncodingException * if UTF-8 is not supported */ then Method2's javadoc will be broken. The actual cause seems to be within the QDox library > fix goal corrupts file if no newline before end-comment tag > --- > > Key: MJAVADOC-470 > URL: https://issues.apache.org/jira/browse/MJAVADOC-470 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Attachments: QDoxBug.java > > > If a method comment has the end-comment tag without a preceding newline, the > next method processed will become corrupted. I've attached a simple java file > to this case that demonstrates the problem. In short, if Method1 has a > comment like: > /** > * This javadoc has no newline before the end-comment token > * > * @throws UnsupportedEncodingException > * if UTF-8 is not supported */ > then Method2's javadoc will be broken. > The actual cause seems to be within the QDox library, where the library > doesn't properly set the line number where the actual method begins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-434) Running javadoc:fix corrupts files
[
https://issues.apache.org/jira/browse/MJAVADOC-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15402969#comment-15402969
]
Richard Sand commented on MJAVADOC-434:
---
There are two separate issues here - iterative duplication of comments (see
MJAVADOC-452) and corruption of code. The latter I've determined comes from a
specific odd condition that the QDox library misinterprets where QDox doesn't
properly set the line number where the method starts. See MJAVADOC-470.
> Running javadoc:fix corrupts files
> --
>
> Key: MJAVADOC-434
> URL: https://issues.apache.org/jira/browse/MJAVADOC-434
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1, 2.10.3
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
> Maven home: /Users/dwinsor/maven/3.0.3
> Java version: 1.6.0_65, vendor: Apple Inc.
> Java home: /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
> also
> ~/neo/neo-test$ mvn -v
> Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
> Maven home: /Users/dwinsor/maven/3.0.3
> Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
>Reporter: Daniel Winsor
> Attachments: test.gz
>
>
> {noformat}
> ~/neo/neo-test$ mvn clean javadoc:fix && mvn compile
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building test 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ neo-test ---
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.10.3:fix (default-cli) @ neo-test >>>
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
> neo-test ---
> [WARNING] Using platform encoding (MacRoman actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /Users/dwinsor/neo/neo-test/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ neo-test
> ---
> [WARNING] File encoding has not been set, using platform encoding MacRoman,
> i.e. build is platform dependent!
> [INFO] Compiling 4 source files to /Users/dwinsor/neo/neo-test/target/classes
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.10.3:fix (default-cli) @ neo-test <<<
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.10.3:fix (default-cli) @ neo-test ---
> [WARNING] File encoding has not been set, using platform encoding MacRoman,
> i.e. build is platform dependent!
> [WARNING]
> [WARNING] WARRANTY DISCLAIMER
> [WARNING]
> [WARNING] All warranties with regard to this Maven goal are disclaimed!
> [WARNING] The changes will be done directly in the source code.
> [WARNING] The Maven Team strongly recommends the use of a SCM software BEFORE
> executing this goal.
> [WARNING]
> [INFO] Are you sure to proceed? [Y]es [N]o
> y
> [INFO] OK, let's proceed...
> [WARNING] No previous artifact has been deployed, Clirr is ignored.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 6.041s
> [INFO] Finished at: Mon Aug 31 18:33:42 PDT 2015
> [INFO] Final Memory: 17M/245M
> [INFO]
>
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building test 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
> neo-test ---
> [WARNING] Using platform encoding (MacRoman actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /Users/dwinsor/neo/neo-test/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ neo-test
> ---
> [WARNING] File encoding has not been set, using platform encoding MacRoman,
> i.e. build is platform dependent!
> [INFO] Compiling 4 source files to /Users/dwinsor/neo/neo-test/target/classes
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO]
[jira] [Updated] (MJAVADOC-470) fix goal corrupts file if no newline before end-comment tag
[ https://issues.apache.org/jira/browse/MJAVADOC-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-470: -- Attachment: QDoxBug.java Run the javadoc:fix goal on the attached java file > fix goal corrupts file if no newline before end-comment tag > --- > > Key: MJAVADOC-470 > URL: https://issues.apache.org/jira/browse/MJAVADOC-470 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Attachments: QDoxBug.java > > > If a method comment has the end-comment tag without a preceding newline, the > next method processed will become corrupted. I've attached a simple java file > to this case that demonstrates the problem. In short, if Method1 has a > comment like: > /** > * This javadoc has no newline before the end-comment token > * > * @throws UnsupportedEncodingException > * if UTF-8 is not supported */ > then Method2's javadoc will be broken. > The actual cause seems to be within the QDox library -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MJAVADOC-470) fix goal corrupts file if no newline before end-comment tag
Richard Sand created MJAVADOC-470: - Summary: fix goal corrupts file if no newline before end-comment tag Key: MJAVADOC-470 URL: https://issues.apache.org/jira/browse/MJAVADOC-470 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 2.10.3 Reporter: Richard Sand If a method comment has the end-comment tag without a preceding newline, the next method processed will become corrupted. I've attached a simple java file to this case that demonstrates the problem. In short, if Method1 has a comment like: /** * This javadoc has no newline before the end-comment token * * @throws UnsupportedEncodingException * if UTF-8 is not supported */ then Method2's javadoc will be broken. The actual cause seems to be within the QDox library -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Attachment: javadocfix-loop.zip > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Attachments: javadocfix-loop.zip, > maven-javadoc-plugin-MJAVADOC451.patch, skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387139#comment-15387139 ] Richard Sand commented on MJAVADOC-451: --- Hi Robert - I've uploaded to the issue a zip file that contains a couple of simple POMs, a single class file for testing with, and the maven log and a snapshot of my file system showing what happens when the looping occurs. Basically to trip this condition, the pom executes javadoc:fix and specifies force=true and runs in the generate-sources phase. Its a bad combination obviously. But this particular circumstance is not the main reason to introduce a skip option. Most plugins that alter the project in some way have a skip flag - in fact most of the apache maven plugins have a skip option, and the Javadoc plugin itself has a skip - its just this specific goal that lacks the skip. In my projects, I use the goal with force=true but sometime it is useful to be able to simply turn it off. I truly can't think of any downside to providing this option. It is simple, it is useful, and it doesn't impact any other functionality or regression. > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Attachments: maven-javadoc-plugin-MJAVADOC451.patch, skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373729#comment-15373729 ] Richard Sand commented on MJAVADOC-452: --- Thanks Robert. I uploaded the patch to #6 to MJAVADOC-451 > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch, > maven-javadoc-plugin-OnlySaveIfChanged.patch, > maven-javadoc-plugin-RemoveUnknownThrowsOption.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Attachment: maven-javadoc-plugin-MJAVADOC451.patch Updated patch against trunk > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Attachments: maven-javadoc-plugin-MJAVADOC451.patch, skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: maven-javadoc-plugin-RemoveUnknownThrowsOption.patch This simple patch adds the option to remove unknown throws > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch, > maven-javadoc-plugin-OnlySaveIfChanged.patch, > maven-javadoc-plugin-RemoveUnknownThrowsOption.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369310#comment-15369310 ] Richard Sand commented on MJAVADOC-452: --- Thanks Robert. You saw what I was going for with passing the state into each method, just to save doing the string compares to detect changes if we know there are changes already. Not a big deal either way, code is cleaner and makes more sense the way you structured it. I'll work on the next patch now > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch, > maven-javadoc-plugin-OnlySaveIfChanged.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368922#comment-15368922 ] Richard Sand commented on MJAVADOC-452: --- I uploaded a fix for item #2 in my list above (only saving the file if its been changed). If you add this into the trunk, I'll check out the latest and create another patch for item #1 (new config option for removing unknown throws), which is also self-contained. After that, item #6 (skipJavaDoc) is also self-contained, although I know you don't like that fix. Then items 3-5 I hope we can tackle as one patch since they all involve updates to the same method Thanks! > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch, > maven-javadoc-plugin-OnlySaveIfChanged.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: maven-javadoc-plugin-OnlySaveIfChanged.patch this patch is for the improvement that a file is not saved if no changes are made > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch, > maven-javadoc-plugin-OnlySaveIfChanged.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHADE-229) Add ability for ServicesResourceTransformer to rename files
[ https://issues.apache.org/jira/browse/MSHADE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-229: Attachment: shade srt.patch > Add ability for ServicesResourceTransformer to rename files > --- > > Key: MSHADE-229 > URL: https://issues.apache.org/jira/browse/MSHADE-229 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.4.3 >Reporter: Richard Sand > Attachments: shade srt.patch > > > The ServicesResoureTransformer can transform the contents of files in > META-INF/services - however, often the names of these files also follow the > package hierarchy. Simple example is commons-logging, where it creates a > service META-INF/services/org.apache.commons.logging.LogFactory containing > the full name of the default LogFactory class. So in addition to transforming > the file contents, we want to transform the file names as well. > Sometimes this is a requirement to create a working shaded jar. For example, > if you are using Jersey JAX-RS, or any project using Glassfish HK2, you will > find that your shaded jar fails because these services files are now expected > to have been renamed along with the class relocation rules. > I've added a patch to this case that augments ServicesResourceTransformer to > add this capability. It adds a new Boolean "renamFiles" - which defaults to > "false" to preserve existing functionality. But when sent to true, it will > send each resource filename through the relocators, so that > "META-INF\services\org.glassfish.hk2.extension.ServiceLocatorGenerator" is > renamed to > "com.idfconnect.relocated.org.glassfish.hk2.extension.ServiceLocatorGenerator", > as well as having its contents updated as well. With this fix In place, I've > easily encapsulated Jersey and my logging framework into a shaded jar that > works just fine. > The fix is very easy and only a few lines of code and provides a useful new > feature. I hope the development community agrees and accepts this patch into > the next release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHADE-229) Add ability for ServicesResourceTransformer to rename files
[ https://issues.apache.org/jira/browse/MSHADE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-229: Description: The ServicesResoureTransformer can transform the contents of files in META-INF/services - however, often the names of these files also follow the package hierarchy. Simple example is commons-logging, where it creates a service META-INF/services/org.apache.commons.logging.LogFactory containing the full name of the default LogFactory class. So in addition to transforming the file contents, we want to transform the file names as well. Sometimes this is a requirement to create a working shaded jar. For example, if you are using Jersey JAX-RS, or any project using Glassfish HK2, you will find that your shaded jar fails because these services files are now expected to have been renamed along with the class relocation rules. I've added a patch to this case that augments ServicesResourceTransformer to add this capability. It adds a new Boolean "renamFiles" - which defaults to "false" to preserve existing functionality. But when sent to true, it will send each resource filename through the relocators, so that "META-INF\services\org.glassfish.hk2.extension.ServiceLocatorGenerator" is renamed to "com.idfconnect.relocated.org.glassfish.hk2.extension.ServiceLocatorGenerator", as well as having its contents updated as well. With this fix In place, I've easily encapsulated Jersey and my logging framework into a shaded jar that works just fine. The fix is very easy and only a few lines of code and provides a useful new feature. I hope the development community agrees and accepts this patch into the next release was: The ServicesResoureTransformer can transform the contents of files in META-INF/services - however, often the names of these files also follow the package hierarchy. Simple example is commons-logging, where it creates a service META-INF/services/org.apache.commons.logging.LogFactory containing the full name of the default LogFactory class. So in addition to transforming the file contents, we want to transform the file names as well. Sometimes this is a requirement to create a working shaded jar. For example, if you are using Jersey, or > Add ability for ServicesResourceTransformer to rename files > --- > > Key: MSHADE-229 > URL: https://issues.apache.org/jira/browse/MSHADE-229 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.4.3 >Reporter: Richard Sand > > The ServicesResoureTransformer can transform the contents of files in > META-INF/services - however, often the names of these files also follow the > package hierarchy. Simple example is commons-logging, where it creates a > service META-INF/services/org.apache.commons.logging.LogFactory containing > the full name of the default LogFactory class. So in addition to transforming > the file contents, we want to transform the file names as well. > Sometimes this is a requirement to create a working shaded jar. For example, > if you are using Jersey JAX-RS, or any project using Glassfish HK2, you will > find that your shaded jar fails because these services files are now expected > to have been renamed along with the class relocation rules. > I've added a patch to this case that augments ServicesResourceTransformer to > add this capability. It adds a new Boolean "renamFiles" - which defaults to > "false" to preserve existing functionality. But when sent to true, it will > send each resource filename through the relocators, so that > "META-INF\services\org.glassfish.hk2.extension.ServiceLocatorGenerator" is > renamed to > "com.idfconnect.relocated.org.glassfish.hk2.extension.ServiceLocatorGenerator", > as well as having its contents updated as well. With this fix In place, I've > easily encapsulated Jersey and my logging framework into a shaded jar that > works just fine. > The fix is very easy and only a few lines of code and provides a useful new > feature. I hope the development community agrees and accepts this patch into > the next release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHADE-229) Add ability for ServicesResourceTransformer to rename files
[ https://issues.apache.org/jira/browse/MSHADE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-229: Description: The ServicesResoureTransformer can transform the contents of files in META-INF/services - however, often the names of these files also follow the package hierarchy. Simple example is commons-logging, where it creates a service META-INF/services/org.apache.commons.logging.LogFactory containing the full name of the default LogFactory class. So in addition to transforming the file contents, we want to transform the file names as well. Sometimes this is a requirement to create a working shaded jar. For example, if you are using Jersey, or > Add ability for ServicesResourceTransformer to rename files > --- > > Key: MSHADE-229 > URL: https://issues.apache.org/jira/browse/MSHADE-229 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.4.3 >Reporter: Richard Sand > > The ServicesResoureTransformer can transform the contents of files in > META-INF/services - however, often the names of these files also follow the > package hierarchy. Simple example is commons-logging, where it creates a > service META-INF/services/org.apache.commons.logging.LogFactory containing > the full name of the default LogFactory class. So in addition to transforming > the file contents, we want to transform the file names as well. > Sometimes this is a requirement to create a working shaded jar. For example, > if you are using Jersey, or -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MSHADE-229) Add ability for ServicesResourceTransformer to rename files
Richard Sand created MSHADE-229: --- Summary: Add ability for ServicesResourceTransformer to rename files Key: MSHADE-229 URL: https://issues.apache.org/jira/browse/MSHADE-229 Project: Maven Shade Plugin Issue Type: Improvement Affects Versions: 2.4.3 Reporter: Richard Sand -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306998#comment-15306998 ] Richard Sand commented on MJAVADOC-452: --- Hi Robert, its a pain to split it up, is it ok if I walk through the changes in the patch file? Here is a description of every change by line # (the line # in the patch file that is): 17: added boolean config param "removeUnknownThrows" for removing unknown throws, default is false 30: added boolean config param "maven.javadoc.fix.skip" for skipping the fix goal, default is false 43: inside execute() method, added check for skip=true 57: in properties passed into CLIRR invocation, added "maven.javadoc.fix.skip=true" to prevent CLIRR from invoking fix and looping [I understand you don't like that, but it's simple and straightforward] 68: added capability to detect if any actual changes have been made to the contents of the file before saving - line 68 initializes a new BufferedReader for holding the contents for comparison 75: reads the output file into our BufferedReader 86: closes the new BufferedReader 101: changed the log message from "fixing" to "analyzing", since here we are only looking for fixes, later we will log if any fixes were performed 112: moved "String line" variable declaration into the loop itself 121: added a missing "close" 130: does a line-by-line comparison of the original content to the new content 136: added a log statement saying that we were saving changes to this file because changes were made 148: no code change here, just changed the formatting so each method was on its own line 169: moved "addMissingJavadocTags" above "updateJavadocTags" - this is because we added a new method "writeJavadocTags" which does the actual output, so addMissingJavadocTags doesn't actually output anything, it just adds the missing tags to the list 177: added writeJavadocTags 185: we are inside parseJavadocTags - we are now passing the javaEntityTags object into getJavadocComment 198: here instead of directly putting the throws tag into the javaEntityTags, we call fixThrowsTag 207-312: the method updateJavadocTags has been modified a fair amount. First, it has been renamed to writeJavadocTags - this method writes all of the tags provided, and uniformly ensures that every tag ends in an EOL with no extra whitespaces trailing. The main change is its handling specifically of methods comments. Here, it uses the javaEntityTags to find all of the tags it needs to write, since we have ensured that the javaEntityTags are populated with everything that the comment should have 314: the method writeParamTag is now passed in the 1 specific tag it is supposed to be writing, instead of the array of all parameters 318: removed call to fixQdox because that was called outside of writeParamTag 329: changed log message from "fixed unknown param" to "removed unknown param" to provide a clearer message 338: we renamed the method "writeThrowsTag" to "fixThrowsTag" because this method no longer writes any output, but just fixes the tag within the javaEntityTags. we added a new "writeThrowsTag" later to do the actual output writing 354: instead of writing the tag, put it into javaEntityTags 360-371: no code changes, just formatting 381-386: we don't output the tag, just update the String and put it back into the javaEntityTags 392: add check for "removeUnknownThrows" 394-396: updated log message to explicitly state that the throws is being ignored (removed) 399-405: updated log message to explicitly state that an unknown throws was found but is being included 409-441: new method "writeThrowsTag" which does the actual output 455-456: addMissingJavadocTags no longer needs a StringBuffer since it no longer does any output writing. Instead any changes it makes are added to the javaEntityTags 464-467: instead of writing to the output, we create a new javaEntityTags entry [java parameter] 475-478: instead of writing to the output, we create a new javaEntityTags entry [type parameter] 486-489: instead of writing to the output, we create a new javaEntityTags entry [return tag] 497-500: instead of writing to the output, we create a new javaEntityTags entry [throws tag] 508-511: instead of writing to the output, we create a new javaEntityTags entry [author tag] 515-518: instead of writing to the output, we create a new javaEntityTags entry [version tag] 526-529: instead of writing to the output, we create a new javaEntityTags entry [since tag, new class] 534-538: instead of writing to the output, we create a new javaEntityTags entry [since tag, existing class] 546-549: instead of writing to the output, we create a new javaEntityTags entry [since tag, new method] 557-560: instead of writing to the output, we create a new javaEntityTags entry [since tag, existing] 568: added missing close 578: added missing close 587-592: because
[jira] [Commented] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15305093#comment-15305093 ] Richard Sand commented on MJAVADOC-452: --- Yes take a look at the very bottom of the patch file, you'll see the fixes to the test output pages where I simply switched the location of two tags to be consistent with fix #3 > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15304852#comment-15304852 ] Richard Sand commented on MJAVADOC-451: --- As per our discussion in MJAVADOC-452 - how do you want to handle this? The skip option is really needed if the goal is to be used unattended, and many other plugins have a skip parameter. I think maybe you object to also using the parameter within the goal itself, to prevent CLIRR from re-executing the fix goal and causing a loop? If so, I'm not sure how else to avoid that problem. Unless we used a separate parameter e.g. "invokedFromClirr" that we'd use internally but separate from the skip parameter. Is that preferable? > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Attachments: skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15304830#comment-15304830 ] Richard Sand commented on MJAVADOC-452: --- Hi Robert - thanks for replying! The fixes for 3,4, and 5 all involve changes to the same method updateJavadocTags so its going to be difficult to create separate patches for them. The patch I uploaded to the case also included the patches for the 2 JUnit test sample pages. Understand that I did not change the actual tests, I only changed the sample pages it compares the output with, so that the sample page now has the tags in the proper order as created by the goal. The two failures were simply due to fix #3 - because the old behavior added missing tags at the bottom of the javadoc, instead of preserving order, so those two JUnit tests were comparing to an output file that had the tags in the wrong order. I will doublecheck the patch file to make sure the JUnit test pages are in there. Regarding #6, I'll reply in the MJAVADOC-451 thread. Thanks again! > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: (was: AbstractFixJavadocMojo.patch) > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: maven-javadoc-plugin-MJAVADOC452.patch > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: maven-javadoc-plugin-MJAVADOC452.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and > adds some improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force". Also this > parameter prevents "clirr" from causing javadoc:fix from being re-invoked > when clirr is kicked off, which would cause an infinite loop of > fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing > the "skip" parameter into the invocation of clirr > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing"). > Now that the tags are output in the prescribed order, two of the JUnit test > "expected" java output files needed to be updated to put the @return tag > below their @param tags > The attached patch file updates AbstractFixJavadocMojo.jar, and two test > resources. All JUnit tests pass successfully. The patch was generated against > the 2.10.3 tag in SVN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Description: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force". Also this parameter prevents "clirr" from causing javadoc:fix from being re-invoked when clirr is kicked off, which would cause an infinite loop of fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing the "skip" parameter into the invocation of clirr I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more descriptive and indicative of the actual activity (e.g. changed "fixing" to "analyzing"). Now that the tags are output in the prescribed order, two of the JUnit test "expected" java output files needed to be updated to put the @return tag below their @param tags The attached patch file updates AbstractFixJavadocMojo.jar, and two test resources. All JUnit tests pass successfully. The patch was generated against the 2.10.3 tag in SVN. was: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force". Also this parameter prevents "clirr" from causing javadoc:fix from being re-invoked when clirr is kicked off, which would cause an infinite loop of fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing the "skip" parameter into the invocation of clirr I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more
[jira] [Commented] (MJAVADOC-420) javadoc:fix duplicates lines
[
https://issues.apache.org/jira/browse/MJAVADOC-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15290436#comment-15290436
]
Richard Sand commented on MJAVADOC-420:
---
FYI I provided a patch for this issue attached to MJAVADOC-452
> javadoc:fix duplicates lines
>
>
> Key: MJAVADOC-420
> URL: https://issues.apache.org/jira/browse/MJAVADOC-420
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.1
> Environment: MacOS
>Reporter: Michenaud Laurent
> Attachments: fixjavadocbugs.zip
>
>
> On the following example, if you starts several times the javadoc:fix goal,
> the line "@param paramSecond" is duplicated several times.
> package com.example;
> /**
> * FirstBug class.
> */
> public class FirstBug {
> /**
>* mymethod.
>*
>* @param param a {@link java.lang.String} object.
>* @param paramSecond a {@link java.lang.String} object.
>*/
> public void mymethod( String param, String paramSecond ) {
>
> }
> }
> After investigation, i have found that when a parameter name is included in
> another parameter name, the bug occurs.
> Best regards
> Laurent
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Description: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,MJAVADOC-434, and MJAVADOC-451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force". Also this parameter prevents "clirr" from causing javadoc:fix from being re-invoked when clirr is kicked off, which would cause an infinite loop of fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing the "skip" parameter into the invocation of clirr I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more descriptive and indicative of the actual activity (e.g. changed "fixing" to "analyzing") and updated the hardcoded clirr version to 2.7. was: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force". Also this parameter prevents "clirr" from causing javadoc:fix from being re-invoked when clirr is kicked off, which would cause an infinite loop of fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing the "skip" parameter into the invocation of clirr I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more descriptive and indicative of the actual activity (e.g. changed "fixing" to "analyzing") and updated the hardcoded clirr version to 2.7. > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL:
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Description: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force". Also this parameter prevents "clirr" from causing javadoc:fix from being re-invoked when clirr is kicked off, which would cause an infinite loop of fix-->clirr-->fix-->clirr. This scenario is prevented by internally passing the "skip" parameter into the invocation of clirr I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more descriptive and indicative of the actual activity (e.g. changed "fixing" to "analyzing") and updated the hardcoded clirr version to 2.7. was: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force" I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more descriptive and indicative of the actual activity (e.g. changed "fixing" to "analyzing") and updated the hardcoded clirr version to 2.7. > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: AbstractFixJavadocMojo.patch > > > I've attached a
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: (was: AbstractFixJavadocMojo.patch) > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: AbstractFixJavadocMojo.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some > improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force" > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing") and > updated the hardcoded clirr version to 2.7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: AbstractFixJavadocMojo.patch > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: AbstractFixJavadocMojo.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some > improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force" > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing") and > updated the hardcoded clirr version to 2.7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Attachment: AbstractFixJavadocMojo.patch > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > Attachments: AbstractFixJavadocMojo.patch > > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some > improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed updateJavadocTags so that > method tags are always output in the prescribed order > 4) I fixed issue MJAVADOC-420, where if two method parameters existed with > overlapping names (e.g. @param thing @param thing2), then the second > parameter would be added twice > 5) there was an issue if a comment erroneously contained the same parameter > twice (.e.g @param thing, @param thing), where both tags would be duplicated, > and all instances would have the description of the first. this was fixed in > "updateJavadocTags" and "addMissingJavadocTags" > 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" > parameter, which is useful when used in conjunction with "force" > I believe the patch will also resolve MJAVADOC-434, corrupted files > (basically the end-comment tag was left in the middle of the comment block > causing syntax errors) because I also observed this behavior and I don't now > after the patch, but I didn't actually trace down the root cause of 434 to be > certain > Lastly I updated some of the log messages to be more descriptive and > indicative of the actual activity (e.g. changed "fixing" to "analyzing") and > updated the hardcoded clirr version to 2.7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-452) Several fixes for comment corruption in fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-452: -- Description: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force" I believe the patch will also resolve MJAVADOC-434, corrupted files (basically the end-comment tag was left in the middle of the comment block causing syntax errors) because I also observed this behavior and I don't now after the patch, but I didn't actually trace down the root cause of 434 to be certain Lastly I updated some of the log messages to be more descriptive and indicative of the actual activity (e.g. changed "fixing" to "analyzing") and updated the hardcoded clirr version to 2.7. was: I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force" > Several fixes for comment corruption in fix goal > > > Key: MJAVADOC-452 > URL: https://issues.apache.org/jira/browse/MJAVADOC-452 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.3 >Reporter: Richard Sand > Labels: patch > > I've attached a patch to this issue that fixes several problems in > javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some > improvements to the fix goal. > 1) added a new config parameter "removeUnknownThrows", to tell the plugin to > remove a @throws tag if the exception class is not actually thrown. > Previously it only warned. I set the default value to "false" to preserve > existing behavior > 2) in "processFix", I added a check to see if the content had actually been > changed before writing to disk. This preserves file timestamps and provides a > clear indication if any changes were actually made > 3) a problem in "updateJavadocTags" for method comments specifically, where, > if a throws tag was unknown, it would be written at the bottom of the > comments e.g. after @return, @since etc. I fixed
[jira] [Created] (MJAVADOC-452) Several fixes for comment corruption in fix goal
Richard Sand created MJAVADOC-452: - Summary: Several fixes for comment corruption in fix goal Key: MJAVADOC-452 URL: https://issues.apache.org/jira/browse/MJAVADOC-452 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 2.10.3 Reporter: Richard Sand I've attached a patch to this issue that fixes several problems in javadoc:fix, including issue MJAVADOC-420,434, and 451, and adds some improvements to the fix goal. 1) added a new config parameter "removeUnknownThrows", to tell the plugin to remove a @throws tag if the exception class is not actually thrown. Previously it only warned. I set the default value to "false" to preserve existing behavior 2) in "processFix", I added a check to see if the content had actually been changed before writing to disk. This preserves file timestamps and provides a clear indication if any changes were actually made 3) a problem in "updateJavadocTags" for method comments specifically, where, if a throws tag was unknown, it would be written at the bottom of the comments e.g. after @return, @since etc. I fixed updateJavadocTags so that method tags are always output in the prescribed order 4) I fixed issue MJAVADOC-420, where if two method parameters existed with overlapping names (e.g. @param thing @param thing2), then the second parameter would be added twice 5) there was an issue if a comment erroneously contained the same parameter twice (.e.g @param thing, @param thing), where both tags would be duplicated, and all instances would have the description of the first. this was fixed in "updateJavadocTags" and "addMissingJavadocTags" 6) Includes the same fix as attached to MJAVADOC-451, which adds a "skip" parameter, which is useful when used in conjunction with "force" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Attachment: skip.patch > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Fix For: 2.10.4 > > Attachments: skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Attachment: (was: skip.patch) > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Fix For: 2.10.4 > > Attachments: skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Priority: Minor (was: Trivial) > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Minor > Fix For: 2.10.4 > > Attachments: skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Attachment: (was: skip.patch) > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Trivial > Fix For: 2.10.4 > > Attachments: skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[ https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MJAVADOC-451: -- Attachment: skip.patch > Add "skip" option to javadoc:fix goal > - > > Key: MJAVADOC-451 > URL: https://issues.apache.org/jira/browse/MJAVADOC-451 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 2.10.3 > Environment: all >Reporter: Richard Sand >Priority: Trivial > Fix For: 2.10.4 > > Attachments: skip.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > I've a project where we want to use the javadoc:fix goal in a non-interactive > (forced) mode. I know this isn't recommended usage but we have specific > reasons for this particular project. It is useful to have a parameter to tell > maven to skip this goal if desired. > Also, since using the javadoc:fix with "force" as part of the build lifecycle > will cause an endless loop as maven executes the clirr:check goal, adding > this parameter allows javadoc:fix to invoke clirr:check without looping. > Many other goals/plugins have a skip parameter, so I added one called > "maven.javadoc.fix.skip". > I've provided a patch here to add this parameter. Its a trivial enough patch > that I hope you'll allow it for 2.10.4. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[
https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Sand updated MJAVADOC-451:
--
Description:
I've a project where we want to use the javadoc:fix goal in a non-interactive
(forced) mode. I know this isn't recommended usage but we have specific reasons
for this particular project. It is useful to have a parameter to tell maven to
skip this goal if desired.
Also, since using the javadoc:fix with "force" as part of the build lifecycle
will cause an endless loop as maven executes the clirr:check goal, adding this
parameter allows javadoc:fix to invoke clirr:check without looping.
Many other goals/plugins have a skip parameter, so I added one called
"maven.javadoc.fix.skip".
I've provided a patch here to add this parameter. Its a trivial enough patch
that I hope you'll allow it for 2.10.4. Thanks!
was:
I've a project where we want to use the javadoc:fix goal in a non-interactive
(forced) mode. I know this isn't recommended usage but we have specific reasons
for this particular project. It is useful to have a parameter to tell maven to
skip this goal if desired. Many other goals/plugins have a skip parameter, so I
added one called "maven.javadoc.fix.skip".
I've provided a patch here to add this parameter. Its a trivial enough patch
that I hope you'll allow it for 2.10.4. Thanks!
Index: src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
===
--- src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
(revision 1743597)
+++ src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
(working copy)
@@ -365,6 +365,14 @@
@Parameter( defaultValue = "${settings}", readonly = true, required = true
)
private Settings settings;
+/**
+ * Specifies whether the Javadoc fix should be skipped.
+ *
+ * @since 2.10.4
+ */
+@Parameter( property = "maven.javadoc.fix.skip", defaultValue = "false" )
+protected boolean skip;
+
// --
// Internal fields
// --
@@ -402,6 +410,12 @@
public void execute()
throws MojoExecutionException, MojoFailureException
{
+if ( skip )
+{
+getLog().info( "Skipping javadoc generation" );
+return;
+}
+
if ( !fixClassComment && !fixFieldComment && !fixMethodComment )
{
getLog().info( "Specified to NOT fix classes, fields and methods.
Nothing to do." );
> Add "skip" option to javadoc:fix goal
> -
>
> Key: MJAVADOC-451
> URL: https://issues.apache.org/jira/browse/MJAVADOC-451
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.3
> Environment: all
>Reporter: Richard Sand
>Priority: Trivial
> Fix For: 2.10.4
>
> Attachments: skip.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I've a project where we want to use the javadoc:fix goal in a non-interactive
> (forced) mode. I know this isn't recommended usage but we have specific
> reasons for this particular project. It is useful to have a parameter to tell
> maven to skip this goal if desired.
> Also, since using the javadoc:fix with "force" as part of the build lifecycle
> will cause an endless loop as maven executes the clirr:check goal, adding
> this parameter allows javadoc:fix to invoke clirr:check without looping.
> Many other goals/plugins have a skip parameter, so I added one called
> "maven.javadoc.fix.skip".
> I've provided a patch here to add this parameter. Its a trivial enough patch
> that I hope you'll allow it for 2.10.4. Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
[
https://issues.apache.org/jira/browse/MJAVADOC-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Sand updated MJAVADOC-451:
--
Attachment: skip.patch
> Add "skip" option to javadoc:fix goal
> -
>
> Key: MJAVADOC-451
> URL: https://issues.apache.org/jira/browse/MJAVADOC-451
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.3
> Environment: all
>Reporter: Richard Sand
>Priority: Trivial
> Fix For: 2.10.4
>
> Attachments: skip.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I've a project where we want to use the javadoc:fix goal in a non-interactive
> (forced) mode. I know this isn't recommended usage but we have specific
> reasons for this particular project. It is useful to have a parameter to tell
> maven to skip this goal if desired. Many other goals/plugins have a skip
> parameter, so I added one called "maven.javadoc.fix.skip".
> I've provided a patch here to add this parameter. Its a trivial enough patch
> that I hope you'll allow it for 2.10.4. Thanks!
> Index:
> src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
> ===
> --- src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
> (revision 1743597)
> +++ src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
> (working copy)
> @@ -365,6 +365,14 @@
> @Parameter( defaultValue = "${settings}", readonly = true, required =
> true )
> private Settings settings;
>
> +/**
> + * Specifies whether the Javadoc fix should be skipped.
> + *
> + * @since 2.10.4
> + */
> +@Parameter( property = "maven.javadoc.fix.skip", defaultValue = "false" )
> +protected boolean skip;
> +
> // --
> // Internal fields
> // --
> @@ -402,6 +410,12 @@
> public void execute()
> throws MojoExecutionException, MojoFailureException
> {
> +if ( skip )
> +{
> +getLog().info( "Skipping javadoc generation" );
> +return;
> +}
> +
> if ( !fixClassComment && !fixFieldComment && !fixMethodComment )
> {
> getLog().info( "Specified to NOT fix classes, fields and
> methods. Nothing to do." );
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MJAVADOC-451) Add "skip" option to javadoc:fix goal
Richard Sand created MJAVADOC-451:
-
Summary: Add "skip" option to javadoc:fix goal
Key: MJAVADOC-451
URL: https://issues.apache.org/jira/browse/MJAVADOC-451
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Affects Versions: 2.10.3
Environment: all
Reporter: Richard Sand
Priority: Trivial
Fix For: 2.10.4
I've a project where we want to use the javadoc:fix goal in a non-interactive
(forced) mode. I know this isn't recommended usage but we have specific reasons
for this particular project. It is useful to have a parameter to tell maven to
skip this goal if desired. Many other goals/plugins have a skip parameter, so I
added one called "maven.javadoc.fix.skip".
I've provided a patch here to add this parameter. Its a trivial enough patch
that I hope you'll allow it for 2.10.4. Thanks!
Index: src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
===
--- src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
(revision 1743597)
+++ src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
(working copy)
@@ -365,6 +365,14 @@
@Parameter( defaultValue = "${settings}", readonly = true, required = true
)
private Settings settings;
+/**
+ * Specifies whether the Javadoc fix should be skipped.
+ *
+ * @since 2.10.4
+ */
+@Parameter( property = "maven.javadoc.fix.skip", defaultValue = "false" )
+protected boolean skip;
+
// --
// Internal fields
// --
@@ -402,6 +410,12 @@
public void execute()
throws MojoExecutionException, MojoFailureException
{
+if ( skip )
+{
+getLog().info( "Skipping javadoc generation" );
+return;
+}
+
if ( !fixClassComment && !fixFieldComment && !fixMethodComment )
{
getLog().info( "Specified to NOT fix classes, fields and methods.
Nothing to do." );
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MSHADE-171) Access Denied on Windows because shade plugin seems to try to open a directory as Zip-File
[
https://jira.codehaus.org/browse/MSHADE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352629#comment-352629
]
Richard Sand commented on MSHADE-171:
-
I have the same error - it occurs for me when one of the dependencies is found
in the local file system as opposed to the local repository, for example in
Eclipse when checking the box resolve local workspace artifacts.
If the shade plugin did a simple isDirectory test before proceeding with
unzipping/unjarring it would probably work fine in all circumstances.
-Richard
Access Denied on Windows because shade plugin seems to try to open a
directory as Zip-File
Key: MSHADE-171
URL: https://jira.codehaus.org/browse/MSHADE-171
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Happens on both Windows and Linux
Reporter: Dominik Stadler
Config of plugin is fairly simple, but fails with the error below when I call
mvn package test, it works when I call only mvn package, it seems the
plugin tries to open a directory as zip-file.
It happens in a multi-module setup when building from the parent-directory.
It seems the dependency between the module where the shade plugin runs onto
another module causes the target/classes of that module to be added as
artifact-file, which causes the shade plugin to fail.
Let me know if you need a self-contained reproducer project, I can provide
one, but it will take some time to build it...
FYI, there was a similar problem in the war plugin at MWAR-192.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version2.3/version
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
/execution
/executions
/plugin
{code}
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on project
towerrunner-ui: Error creating shaded jar:
C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
(Access is denied) - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on
project towerrunner-ui: Error creating shaded jar:
C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
(Access is denied)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
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.MojoExecutionException: Error creating
shaded jar:
C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
(Access is denied)
at
[jira] (MSHADE-155) dependency-reduced-pom should use shadedArtifactId
Richard Sand created MSHADE-155: --- Summary: dependency-reduced-pom should use shadedArtifactId Key: MSHADE-155 URL: https://jira.codehaus.org/browse/MSHADE-155 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.0 Environment: version 2.1, maven 3.0.5 Reporter: Richard Sand When supplying the shadedArtifactId parameter and generate a dependency-reduced-pom, the reduced pom should use this artifactId. This is a 1-line fix in ShadeMojo.createDependencyReducedPom() - simply add: model.setArtifactId(shadedArtifactId); -- 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] (MSHADE-139) Change the default output file name so that it does not replace the ordinary jar
[ https://jira.codehaus.org/browse/MSHADE-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-139: Attachment: patch.txt This patch file on the 2.1 release adds a parameter called replaceOriginalArtifact, which defaults to true, but when false tells shade not to overwrite the original artifact. It also adds a check to see if the classifier parameter is set to blank when building the shaded artifact's id - the two features combined allow you to run shade with an output alternative artifact id (and no classifier) and the corresponding dependency-reduced-pom, which the installer plugin can then add to the repository with the specified alternative coordinates. Change the default output file name so that it does not replace the ordinary jar Key: MSHADE-139 URL: https://jira.codehaus.org/browse/MSHADE-139 Project: Maven Shade Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Benson Margulies Attachments: patch.txt See http://markmail.org/message/kqbvju36nusvydwt We could make incremental builds work righter by not overwriting the base jar by default. -- 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] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
[ https://jira.codehaus.org/browse/MSHADE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-154: Attachment: patch139and154.txt A patch file combining my submission for MSHADE-139 and this issue Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin) --- Key: MSHADE-154 URL: https://jira.codehaus.org/browse/MSHADE-154 Project: Maven Shade Plugin Issue Type: New Feature Affects Versions: 2.0 Environment: all Reporter: Richard Sand Attachments: patch139and154.txt, patch.txt When switching from assembly-plugin to shade-plugin for a given project, I discovered that the shade plugin did not have the capability of using an attached artifact as the primary artifact - only the project's main artifact was supported. I've attached changes to add a configuration parameter alternativeInputClassifier, which, when specified, tells the plugin to look for an artifact with the specified classifier in the project attachments, and to use that as the primary artifact. This makes shade behave similar to assembly-plugin, and allows shade to recognize attached artifacts generated by previous plugins in a maven execution. This was a trivial change, but required modifying several other classes and methods to accept the primary artifact as a parameter instead of a global variable. IMHO these changes are good for the plugin as a whole, as it will allow for future flexibility and logic for determining the entrypoint for the plugin (e.g. being able to run as a standalone goal with a specific artifact as input). -- 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] (MSHADE-134) Shade plugin does not seem to be aware of the classifier setting for the jar plugin
[ https://jira.codehaus.org/browse/MSHADE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332382#comment-332382 ] Richard Sand commented on MSHADE-134: - the patch I submitted in 154 solves this, sorry for the duplicate Shade plugin does not seem to be aware of the classifier setting for the jar plugin --- Key: MSHADE-134 URL: https://jira.codehaus.org/browse/MSHADE-134 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Thomas Dudziak When using the classifier configuration for the jar plugin, e.g. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.4/version configuration classifierfoo/classifier /configuration /plugin then the shade plugin (in both attach or replace modes) complains about a missing main artifact: [ERROR] The project main artifact does not exist. This could have the following [ERROR] reasons: [ERROR] - You have invoked the goal directly from the command line. This is not [ERROR] supported. Please add the goal to the default lifecycle via an [ERROR] execution element in your POM and use mvn package to have it run. [ERROR] - You have bound the goal to a lifecycle phase before package. Please [ERROR] remove this binding from your POM such that the goal will be run in [ERROR] the proper phase. [ERROR] - You removed the configuration of the maven-jar-plugin that produces the main artifact. -- 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] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
Richard Sand created MSHADE-154: --- Summary: Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin) Key: MSHADE-154 URL: https://jira.codehaus.org/browse/MSHADE-154 Project: Maven Shade Plugin Issue Type: New Feature Affects Versions: 2.0 Environment: all Reporter: Richard Sand Attachments: patch.txt When switching from assembly-plugin to shade-plugin for a given project, I discovered that the shade plugin did not have the capability of using an attached artifact as the primary artifact - only the project's main artifact was supported. I've attached changes to add a configuration parameter alternativeInputClassifier, which, when specified, tells the plugin to look for an artifact with the specified classifier in the project attachments, and to use that as the primary artifact. This makes shade behave similar to assembly-plugin, and allows shade to recognize attached artifacts generated by previous plugins in a maven execution. This was a trivial change, but required modifying several other classes and methods to accept the primary artifact as a parameter instead of a global variable. IMHO these changes are good for the plugin as a whole, as it will allow for future flexibility and logic for determining the entrypoint for the plugin (e.g. being able to run as a standalone goal with a specific artifact as input). -- 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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand closed MWAR-304. - Resolution: Not A Bug Ok I follow, thanks for explaining the architectural principle to it. WAR plugin ignores attached artifacts from previous plugins --- Key: MWAR-304 URL: https://jira.codehaus.org/browse/MWAR-304 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.4 Environment: any Reporter: Richard Sand If my maven project includes a plugin that attaches an artifact to the project, the war plugin will not process the artifact for inclusion in the results -- 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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=331185#comment-331185 ] Richard Sand commented on MWAR-304: --- OK understood, thanks for the explanation WAR plugin ignores attached artifacts from previous plugins --- Key: MWAR-304 URL: https://jira.codehaus.org/browse/MWAR-304 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.4 Environment: any Reporter: Richard Sand If my maven project includes a plugin that attaches an artifact to the project, the war plugin will not process the artifact for inclusion in the results -- 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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand closed MWAR-304. - Resolution: Not A Bug WAR plugin ignores attached artifacts from previous plugins --- Key: MWAR-304 URL: https://jira.codehaus.org/browse/MWAR-304 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.4 Environment: any Reporter: Richard Sand If my maven project includes a plugin that attaches an artifact to the project, the war plugin will not process the artifact for inclusion in the results -- 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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand reopened MWAR-304: --- Sorry just one question before closing - is there any merit to the idea of having a configuration option in maven-war-plugin to include attached artifacts in the webapp in the same way it includes dependent artifacts? If there is merit to the idea I'll be happy to submit a new update here WAR plugin ignores attached artifacts from previous plugins --- Key: MWAR-304 URL: https://jira.codehaus.org/browse/MWAR-304 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.4 Environment: any Reporter: Richard Sand If my maven project includes a plugin that attaches an artifact to the project, the war plugin will not process the artifact for inclusion in the results -- 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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
Richard Sand created MWAR-304: - Summary: WAR plugin ignores attached artifacts from previous plugins Key: MWAR-304 URL: https://jira.codehaus.org/browse/MWAR-304 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.4 Environment: any Reporter: Richard Sand If my maven project includes a plugin that attaches an artifact to the project, the war plugin will not process the artifact for inclusion in the results -- 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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[
https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=331127#comment-331127
]
Richard Sand commented on MWAR-304:
---
### Eclipse Workspace Patch 1.0
#P maven-war-plugin
Index:
src/main/java/org/apache/maven/plugin/war/packaging/WarProjectPackagingTask.java
===
---
src/main/java/org/apache/maven/plugin/war/packaging/WarProjectPackagingTask.java
(revision 1515694)
+++
src/main/java/org/apache/maven/plugin/war/packaging/WarProjectPackagingTask.java
(working copy)
@@ -21,6 +21,7 @@
import java.io.File;
import java.io.IOException;
+import java.util.HashSet;
import org.apache.maven.model.Resource;
import org.apache.maven.plugin.MojoExecutionException;
@@ -192,6 +193,11 @@
ArtifactsPackagingTask task = new ArtifactsPackagingTask(
context.getProject().getArtifacts(),
currentProjectOverlay );
task.performPackaging( context );
+
+@SuppressWarnings( { unchecked, rawtypes } )
+ArtifactsPackagingTask task2 = new ArtifactsPackagingTask(new
HashSet(context.getProject().getAttachedArtifacts() ),
+currentProjectOverlay );
+task2.performPackaging( context );
}
/**
WAR plugin ignores attached artifacts from previous plugins
---
Key: MWAR-304
URL: https://jira.codehaus.org/browse/MWAR-304
Project: Maven WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.4
Environment: any
Reporter: Richard Sand
If my maven project includes a plugin that attaches an artifact to the
project, the war plugin will not process the artifact for inclusion in the
results
--
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] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=331128#comment-331128 ] Richard Sand commented on MWAR-304: --- The patch above will properly process attached artifacts WAR plugin ignores attached artifacts from previous plugins --- Key: MWAR-304 URL: https://jira.codehaus.org/browse/MWAR-304 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.4 Environment: any Reporter: Richard Sand If my maven project includes a plugin that attaches an artifact to the project, the war plugin will not process the artifact for inclusion in the results -- 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] (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ https://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=324415#comment-324415 ] Richard Sand commented on MWAR-192: --- Is this issue going to be addressed? Does the patch attached to the case work? Conflict with workspace resoutlion in m2eclipse --- Key: MWAR-192 URL: https://jira.codehaus.org/browse/MWAR-192 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Environment: windows vista Reporter: Max Powers Attachments: maven-war-plugin-2.1.1-patch.jar, maven-war-plugin.patch While building my webapp in eclipse using a launch configuration (goals clean install) and having 'Resolve Workspace Artifacts' checked, the war plugin cant assemble the war file properly. Note that disabled 'Resolve Workspace Artifacts' and the war is assembled fine [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] Embedded error: C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes (Access is denied) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] at org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) ... 16 more Caused by: java.io.FileNotFoundException: C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes (Access is denied) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) at org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057) at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:965) at
[jira] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[ https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=324416#comment-324416 ] Richard Sand commented on MWAR-269: --- Is this issue a duplicate of MWAR-192? There's a patch thats been contributed to that issue war fails to build while using m2e in workspace resolution mode --- Key: MWAR-269 URL: https://jira.codehaus.org/browse/MWAR-269 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Chris Gamache Attachments: maven-war-plugin.patch, screenshot-1.png This is my first time for an issue/patch submission. Apologies if I'm doing it wrong When building in Eclipse using m2e in workspace resolution mode, the maven-war-plugin is not prepared for a dependency which isn't an assembly but is instead a folder containing the compiled classes from within the local workspace. I propose that if the incoming dependency happens to be a directory that it get packaged up and copied to the destination instead of blowing up with an exception. See attached patch for your review... -- 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
