Re: Setting a plugins configruation parameter

[Henrik Eriksson <he...@gmail.com>]

Solved it, works perfectly now. I was overriding the property in a pom
higher up in the hirarchy. RTFM. :)


2012/12/31 Stephen Connolly <st...@gmail.com>

> Not just you. And the worst part is that Maven gets the blame for these
> shitty plugins.
>
> It's not Maven it's you (the shitty plugin authors).
>
>
> On 31 December 2012 15:00, Anders Hammar <an...@hammar.net> wrote:
>
> > It might just be me, but I get tired of these crappy Maven plugins not
> > doing things the Maven way and forcing the users to create even worse
> > patchy solution to use them. Sticking with Ant or some other tool might
> be
> > a better solution than twisting Maven's arm.
> >
> > /Anders
> >
> >
> > On Mon, Dec 31, 2012 at 1:41 PM, Benson Margulies <bimargulies@gmail.com
> > >wrote:
> >
> > > I think you need the invoker plugin so that you can set up and run the
> > > annoying one as configured by your other stuff.
> > >
> > > On Mon, Dec 31, 2012 at 1:00 AM, Henrik Eriksson
> > > <he...@gmail.com> wrote:
> > > > The somcomp-maven-plugin isn't mine plugin, I've not written it and
> the
> > > > code isn't public, ie I can't modify it without breaking licences and
> > > > patches. A solution would be to wrap it but I don't want to do that
> > > either.
> > > > This plugin requries that you setup a path with jars which the plugin
> > > uses
> > > > then it executes instead of using  the maven way ie declaring it in
> the
> > > > pom. Also some processing needs to be done to those jars since the
> > plugin
> > > > doesn't agree with some of those jars because they doesn't follow
> > specs.
> > > My
> > > > plugin preprocesses these jars, to keep the project in a "maven"
> style.
> > > So
> > > > I need to set that plugin parameter somehow.
> > > >
> > > > Not sure how attaching the information would solve this propblem.
> > > >
> > > > //Henrik
> > > >
> > > >
> > > > 2012/12/30 Anders Hammar <an...@hammar.net>
> > > >
> > > >> One other aspect, why two separate plugins? As they seem to be
> tightly
> > > >> coupled I would argue for one plugin with two goals. It makes more
> > sense
> > > >> having this tight coupling between two goals than between two
> plugins.
> > > >> You should then have a look at some plugins that does similar things
> > > (one
> > > >> goal preparing something for another goal). I *think* it is often
> > > solved by
> > > >> storing it in a file as Benson points out, but I also *think* I've
> > seen
> > > >> plugins putting info in system properties for the next goal to
> > consume.
> > > One
> > > >> plugin doing the latter is Mojo's RPM plugin. One plugin doing the
> > > former
> > > >> is the Maven Release plugin (prepare and perform goals).
> > > >>
> > > >> /Anders
> > > >>
> > > >>
> > > >> On Sun, Dec 30, 2012 at 3:33 AM, Benson Margulies <
> > > bimargulies@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > On Sat, Dec 29, 2012 at 8:25 PM, Henrik Eriksson
> > > >> > <he...@gmail.com> wrote:
> > > >> > > I'm writing a plugin for bridging propertiary software with
> maven.
> > > So
> > > >> > > making a portable project is not an option here. The project
> will
> > > only
> > > >> be
> > > >> > > used in our own development. So the problem I have. I have one
> > > plugin
> > > >> > > setting up a property for the other plugin. They are in the same
> > > pom.
> > > >> And
> > > >> > > looks something like this.
> > > >> > >
> > > >> > > <build>
> > > >> > > ...
> > > >> > > <plugin>
> > > >> > > <groupId>com.acme</groupId>
> > > >> > > <artifactId>myplugin-maven-plugin<artifactId>
> > > >> > > <version>1.0</version>
> > > >> > > ...
> > > >> > > <phase>package</phase>
> > > >> > > <plugin>
> > > >> > > <plugin>
> > > >> > > <groupId>com.somecomp</groupId>
> > > >> > > <artifactId>somcomp-maven-plugin<artifactId>
> > > >> > > <version>1.1</version>
> > > >> > > <executions>
> > > >> > > <execution>
> > > >> > > <phase>package</phase>
> > > >> > > <configuration>
> > > >> > > <importantConfiguration>this is the one I want to set with
> > > >> > > myplugin-maven-plugin</importantConfiguration>
> > > >> > > ...
> > > >> > > </configration>
> > > >> > > ...
> > > >> > > </execution>
> > > >> > > </executions>
> > > >> > > </plugin>
> > > >> > > ...
> > > >> > > </build>
> > > >> > >
> > > >> > > I've tried with setting
> > > >> > > <importantConfiguration>${someproperty}</importantConfiguration>
> > > >> > > I've tried various things but no success. Perhaps setting it
> > before
> > > the
> > > >> > > project is being built may solve setting it but makes the
> project
> > > alot
> > > >> > more
> > > >> > > complex. The thing is that somcomp-maven-plugin does a lot of
> > wierd
> > > >> > stuff,
> > > >> > > ie not mavenish but I believe its trying to isolate things from
> > the
> > > >> > > "normal" maven flow. Though our deployment/development
> environment
> > > has
> > > >> a
> > > >> > > lot of legacy and presents various issues by not doing this.
> > > >> > >
> > > >> > > TIA
> > > >> >
> > > >> > I can't make sense of this. What is happening? What don't you like
> > > >> > about what's happening? What do you want to have happen instead?
> Is
> > > >> > the bottom line that you want some information to flow from plugin
> > (1)
> > > >> > to plugin (2)? In that case, you might have to write out a file in
> > > >> > (1), attach it to the build, and consume it in (2).
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > >> > For additional commands, e-mail: users-help@maven.apache.org
> > > >> >
> > > >> >
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>