Re: suggestion regarding MJAVADOC-564 - javadoc:fix enforcing order of tags

o see the complete picture. > > The first thing I had in mind when reading this was the need for a comparator > to reorder the tags. > Not sure if that would replace the need for common-collections4 > > I would suggest to give it a try. > > thanks, > Robert > >

suggestion regarding MJAVADOC-564 - javadoc:fix enforcing order of tags

Hi all - I'd like to provide a fix for MJAVADOC-564, where the javadoc:fix goal will sometimes output the javadoc tags in incorrect order. The problem occurs because of the way the fix goal initially reads in the tags and then iterates over them to make the prescribed corrections. There is an

Re: [GitHub] maven issue #69: MNG-5899 Reactor should use reduced dependency pom

If the shaded artifact is built as a submodule with a different artifact ID, then the shade plugin can specify its DRP as its main POM. It lets other projects depend on the shaded artifact with only its remaining (unshaded) dependencies. I had tried to use the shade plugin along with the

Re: Building jar targeting multiple Java versions, including 9

user can live with the limitations of the IDE (e.g. not being multi-runtime aware) then I should be allowed to do so. Richard Sand | CEO IDF Connect, Inc. 2207 Concord Ave, #359 Wilmington | Delaware 19803 | USA Office: +1 888 765 1611 | Fax: +1 866 765 7284 Mobile: +1 267 984 3651

Re: Building jar targeting multiple Java versions, including 9

give the flexibility I need. But there have certainly been times that I've thought about just going multi-module. I guess my long rambling point is that I can see MRJar being done both ways, and wouldn't want to pigeon-hole anyone into doing it one way vs another. Richard Sand | CEO IDF Connect,

Re: Building jar targeting multiple Java versions, including 9

Understood. I guess it wouldn't be horrible if it required a multi-module maven project but I would still prefer to avoid introducing a requirement for multi-module projects anywhere. Richard Sand | CEO IDF Connect, Inc. 2207 Concord Ave, #359 Wilmington | Delaware 19803 | USA Office: +1 888

Re: Building jar targeting multiple Java versions, including 9

odule-info and having the addtional modules created by a separate plugin. Simplicity wherever possible. Best regards, Richard Sand | CEO IDF Connect, Inc. 2207 Concord Ave, #359 Wilmington | Delaware 19803 | USA Office: +1 888 765 1611 | Fax: +1 866 765 7284 Mobile: +1 267 984 3651 -- Origin

Re: opinions on MJAVADOC-451

Hi all - the request for the skip-parameter started as a requirement to break an infinite loop. When I discovered how the plugin was used and told that binding the plugin to a different phase, the loop was gone. Even though, the request for the skip parameter stayed. Untrue. I opened

Re: opinions on MJAVADOC-451

What about putting the skip option into an abstract base plugin class? Just thinking out loud Sent from my iPhone > On Aug 5, 2016, at 6:51 PM, Christopher wrote: > >> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory wrote: >> >>> On Aug 5, 2016 7:41

Re: opinions on MJAVADOC-451

Anyone want to give this a quick read/opinion? :-) -Richard -- Original Message -- From: "Richard Sand" <rs...@idfconnect.com> To: dev@maven.apache.org Sent: 8/1/2016 6:33:30 PM Subject: opinions on MJAVADOC-451 Hi all, I'd like to ask for opinions on https://issues

opinions on MJAVADOC-451

Hi all, I'd like to ask for opinions on https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and I have been discussing this off list and essentially disagree on it. The request is very simple - to add a "skip" parameter to the javadoc:fix goal. In my projects we are using the

Re[2]: [VOTE] Release Apache Maven Javadoc Plugin version 2.10.4

xt part. Robert On Wed, 29 Jun 2016 06:30:34 +0200, Richard Sand <rs...@idfconnect.com> wrote: Hi Maven Developers - now that Javadoc plugin 2.10.4 is released and work has commenced on the 3.0 version, can we revisit the patch I submitted for MJAVADOC-452? Its difficult to break the p

Re[2]: [VOTE] Release Apache Maven Javadoc Plugin version 2.10.4

duce a changed-flag. AFAIK all rewriting methods are now void-methods. Return true if changed; if changed then rewrite file. After that we can go for the next part. Robert On Wed, 29 Jun 2016 06:30:34 +0200, Richard Sand <rs...@idfconnect.com> wrote: Hi Maven Developers - now

Re: [VOTE] Release Apache Maven Javadoc Plugin version 2.10.4

the fixes on the 2.10.4 tag or the latest trunk. How can I help? -Richard Richard Sand <mailto:rs...@idfconnect.com> June 8, 2016 at 2:11 PM Hi Robert, For the skip parameter, the test is very simple. Usage of the fix goal without disabling CLIRR will result in a loop where fix invokes

Re: [VOTE] Release Apache Maven Javadoc Plugin version 2.10.4

e time to verify and apply it. thanks, Robert ps. In case you are still convinced the skip parameter is required, you need a complete testcase to show it to me. In general *I* won't apply any requests to add a skip parameter, there are often better solutions. On Wed, 08 Jun 2016 00:53:3

Re: [VOTE] Release Apache Maven Javadoc Plugin version 2.10.4

The patch I supplied for MJAVADOC-452, 451, 434 and 420 won't be considered for inclusion? I can recreate the patch off of the latest trunk if it would help Best regards, Richard Sent from my iPhone > On Jun 7, 2016, at 2:39 PM, Robert Scholte wrote: > > Hi, > > We

patch for MJAVADOC-452

Hi Dev community – I recently opened MJAVADOC-452 and uploaded a patch to it that fixes several problems with the Javadoc plugin’s “fix” goal, making it much more reliable to use the goal in an automated fashion. Is anyone from that plugin team interested in taking a look at it and evaluating

need filesystem-level operations in assembly plugin

Hi all - I'm using maven-assembly-plugin to create zip distributions of our web application. It takes in the Apache Tomcat zip artifact, and the war artifact for the app, and creates an assembly. There are a couple of file operations I haven't figured out how to do yet. For example, Tomcat unzips

maven shade patch

Hi all - if anyone is interested, I opened a jira ticket MSHADE-154 to submit a patch to the shade plugin to be able to use an attached artifact as input, similar to that of the assembly plugin. The patch adds a configuration parameter alternativeInputClassifier, which tells the plugin to look

RE: artifact attached by plugin not appearing in subsequent plugins

-plugin. -Original Message- From: Richard Sand [mailto:rs...@idfconnect.com] Sent: Wednesday, August 28, 2013 5:05 PM To: 'Maven Developers List' Subject: RE: artifact attached by plugin not appearing in subsequent plugins I always appreciate a good starwars reference. Actually

RE: artifact attached by plugin not appearing in subsequent plugins

Hi all, Wayne, thanks for the feedback. I understand where you're coming from. I've written out here a concrete example of what I want to do with these plugins, and with maven in general wrt passing generated artifacts between plugins. Hopefully others will weigh in on whether this approach is

RE: artifact attached by plugin not appearing in subsequent plugins

with classifier to module 3 and 4 (or do two obfuscations in module 2 if you need different flavours) On Wednesday, 28 August 2013, Richard Sand wrote: Hi all, Wayne, thanks for the feedback. I understand where you're coming from. I've written out here a concrete example of what I want to do

RE: artifact attached by plugin not appearing in subsequent plugins

side of the maven-force On Wednesday, 28 August 2013, Richard Sand wrote: I thought about it, but its very complicated to obfuscate in stages because some of the classes to be obfuscated in projects 3 and 4 rely on the obfuscated entrypoints in project 2. Basically obfuscation has

RE: artifact attached by plugin not appearing in subsequent plugins

Subject: Re: artifact attached by plugin not appearing in subsequent plugins On Tuesday, 27 August 2013, Barrie Treloar wrote: On 21 August 2013 00:42, Richard Sand rs...@idfconnect.com javascript:; wrote: Is there any merit to the idea of having a configuration option in maven-war-plugin

RE: artifact attached by plugin not appearing in subsequent plugins

Sorry just correcting myself, I was referring to the maven shade plugin not mojo shade plugin. -Richard -Original Message- From: Richard Sand [mailto:rs...@idfconnect.com] Sent: Monday, August 26, 2013 4:54 PM To: 'Maven Users List'; 'Maven Developers List' Subject: RE: artifact

RE: artifact attached by plugin not appearing in subsequent plugins

On Aug 20, 2013 5:13 PM, Richard Sand rs...@idfconnect.com wrote: 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? -Richard -Original Message- From: Mirko

RE: artifact attached by plugin not appearing in subsequent plugins

Hi Wayne - that seems a very inefficient approach, having 5 or 6 separate modules to manage to achieve a single assembly. The point is that maven does have phases, goals, lifecycles - why not use them? The MavenProject object already provides the mechanism for one plugin to see the attachments