Solved it, works perfectly now. I was overriding the property in a pom higher up in the hirarchy. RTFM. :)
2012/12/31 Stephen Connolly <stephen.alan.conno...@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 <and...@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 <bimargul...@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 > > > <henrikeriksso...@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 <and...@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 < > > > bimargul...@gmail.com > > > >> >wrote: > > > >> > > > >> > On Sat, Dec 29, 2012 at 8:25 PM, Henrik Eriksson > > > >> > <henrikeriksso...@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-unsubscr...@maven.apache.org > > > >> > For additional commands, e-mail: users-h...@maven.apache.org > > > >> > > > > >> > > > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > >