Setting a plugins configruation parameter

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

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

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
> > >
> > >
> >
>

Re: Setting a plugins configruation parameter

[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
> >
> >
>

Re: Setting a plugins configruation parameter

[Anders Hammar <an...@hammar.net>]

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 <bi...@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
>
>

Re: Setting a plugins configruation parameter

[Benson Margulies <bi...@gmail.com>]

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

Re: Setting a plugins configruation parameter

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

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
> >
> >
>

Re: Setting a plugins configruation parameter

[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 <bi...@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
>
>

Re: Setting a plugins configruation parameter

[Benson Margulies <bi...@gmail.com>]

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