So the pong is not as bad... Perhaps you are not at rotting shellfish
levels... Still a bad smell though

On Wednesday, December 24, 2014, David Hoffer <dhoff...@gmail.com> wrote:

> The 10 was just an example not something I have in my project.  Replace 10
> with 2 and the same issue applies.
>
> -Dave
>
> On Tue, Dec 23, 2014 at 5:35 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>
> > This is a smell that you are doing something wrong. You probably want to
> > compose everything with either a custom lifecycle or a better plugin or
> > perhaps both. Having to chain 10 things together like that smells of
> > abusing maven rather than playing to maven's strengths.
> >
> > Just an FYI though, if you have something that works for you and you know
> > why it's not recommended but want to fight against the recommendations,
> > that's your business ;-)
> >
> > On 23 December 2014 at 22:10, David Hoffer <dhoff...@gmail.com
> <javascript:;>> wrote:
> > >
> > > Right I understand that it's the plugin's goal that is being bound.
> > > However it's not the case that you can do what I want with just that
> > > approach (not w/o what feels like hacking).  I want to use the normal
> > maven
> > > feature where plugins are executed in order of pom declaration (per
> > phase)
> > > and the feature of specifying the phase per plugin goal.
> > >
> > > E.g. Lets take a simple case.  Plugin A has 10 executions where I need
> > > Plugin B to run between the first 5 and the later 5.
> > >
> > > That configuration is simple if I can have multiple plugin declarations
> > > because I can split plugin A into two declarations with a single
> > > declaration of plugin B in the middle.  They can all be bound to the
> same
> > > phase which is desired in this case.
> > >
> > > On the other hand if I can only have one declaration of A then I'm
> forced
> > > into gymnastics with phase binding.  First I have to have different
> > phases
> > > for the first 5 and the later 5 goals and then to get plugin B to run
> > > before the later half I have to carefully set this (pom location and
> > phase)
> > > so that it runs after the first set and before the later.  I'm not
> saying
> > > it can't be done...but it feels very unnatural and because it forces
> one
> > to
> > > pick extra normally-unneeded phases one might run into cases where its
> > not
> > > even possible.
> > >
> > > Am I missing something?
> > >
> > > -Dave
> > >
> > > On Tue, Dec 23, 2014 at 2:25 PM, Anders Hammar <and...@hammar.net
> <javascript:;>>
> > wrote:
> > >
> > > > You don't bind a plugin to a phase but rather a plugin's goal. So it
> is
> > > > possible to do what you want by having just one plugin declaration
> but
> > > two
> > > > executions specified (for plugin A); one execution for goal A1 bound
> to
> > > the
> > > > generate-resources phase and one execution for goal A2 bound to the
> > > > process-resources phase. There's an example in [1].
> > > >
> > > > The warning is a warning right now, it will still work. However, this
> > > > support can be removed in future versions of Maven.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_executions_Tag
> > > >
> > > > /Anders
> > > >
> > > > On Tue, Dec 23, 2014 at 10:11 PM, David Hoffer <dhoff...@gmail.com
> <javascript:;>>
> > > wrote:
> > > >
> > > > > I have some questions regarding the duplicate plugin declaration
> > > warning,
> > > > > e.g.
> > > > >
> > > > > [artifact:mvn] [WARNING]
> 'build.plugins.plugin.(groupId:artifactId)'
> > > must
> > > > > be unique but found duplicate declaration of plugin
> > > > > org.apache.maven.plugins:maven-xxx-plugin
> > > > >
> > > > > First is this a benign warning that can be ignored or is it really
> > > > > something that is not supported (multiple declarations of the same
> > > > plugin)
> > > > > and that I really need to remove?
> > > > >
> > > > > If it's the later case this really limits the flexibility of
> plugins,
> > > let
> > > > > me explain with an example.
> > > > >
> > > > > If my current build does the following in order:
> > > > >
> > > > > Plugin A - Phase: generate-resources
> > > > > Plugin B - Phase: process-resources
> > > > > Plugin A - Phase: process-resources
> > > > >
> > > > > By defining plugin A twice I'm able to use the most appropriate
> phase
> > > for
> > > > > each instance of the plugin (btw, each instance has several
> > > executions).
> > > > > The key to the above is that plugin B has be be done between each
> of
> > > the
> > > > > two instances of plugin A.
> > > > >
> > > > > If I had to only have one plugin A I'd have to set the phase in the
> > > later
> > > > > case to something later than process-resources (or I'd have to
> adjust
> > > the
> > > > > first one to something earlier).  Not only does it make it harder
> to
> > > > follow
> > > > > the flow (later in the pom is more clear) but it sometimes forces
> the
> > > use
> > > > > of poor phases as I have many other plugins in this pom
> after/before
> > > > these
> > > > > that are tied to phases as well so it limits what can be chosen
> here
> > to
> > > > > satisfy a no duplicate plugin rule.
> > > > >
> > > > > What's really the rule here regarding duplicate plugins?
> > > > >
> > > > > -Dave
> > > > >
> > > >
> > >
> >
>


-- 
Sent from my phone

Reply via email to