me to 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
>
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 i
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 insta
suffice. If I as the end 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 728
abilities with profiles, executions, etc. to
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 doi
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: +
ing
module-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
---
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 MJAV
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 AM, "Benson Margulies" wrote:
>>>
>>> On Fr
Anyone want to give this a quick read/opinion? :-)
-Richard
-- Original Message --
From: "Richard Sand"
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.apache.org/jira/brow
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
to do a String compare, which seems to me quite
expensive with large files. Instead I would introduce 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
riting 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
wrote:
Hi Maven Developers - now that Javadoc plugin 2.10.4 is released and
work has commenced on the 3.0
reate 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 in
need
more 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
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 solved 12 issues:
> htt
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 it
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
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 f
en-shade-plugin and maven-war-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
e dark side. Embrace the many modules on the light
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 en
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 exampl
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
sday, August 27, 2013 3:32 AM
To: Maven Users List
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 >
> wrote:
> > Is there any merit to the idea of having a configu
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 f
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'
S
n Maven modules of their own.
Regards Mirko
--
Sent from my mobile
On Aug 20, 2013 5:13 PM, "Richard Sand" 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
27 matches
Mail list logo
