I've looked it up in the docs: http://maven.apache.org/pom.html#Properties
It might actually be "project.packaging". Jeroen On 19/04/07, Jeroen Leenarts <[EMAIL PROTECTED]> wrote:
You might be on to something there.... The page: http://maven.apache.org/guides/introduction/introduction-to-profiles.html mentiones this piece of code. Activiation based on a property. This will activate the profile when the system property "debug" is specified with any value: <profiles> <profile> <activation> <property> <name>debug</name> </property> </activation> ... </profile> </profiles> Wouldn't a property named "packaging" with the relevant value work? Packaging is the tag defining a projects, ehr, packaging. Which is exactly the granularity you want to configure at. Well worth to try. Jeroen On 19/04/07, Peter Nilsson <[EMAIL PROTECTED]> wrote: > > Yes, for the plugins we have developed in house it is no problem but > that is > not what I am struggling with right now (as you noticed). > > Reorganizing the tree is an option and is exactly what I am considering > right now. However, I would rather keep a functional organization of my > build tree and use features of the build system for controlling the > build of > different type of artifacts. A functional organization makes it easier > for > developers to check out and build only the part of the tree they are > working > on. A build tree organized after artifact type does not map to > responsible > developer/team very well. > > Perhaps it would be possible to use profiles for controlling the use of > plugins and let the packaging activate the profile? > > Thanks. > > Peter > > -----Original Message----- > From: Jeroen Leenarts [mailto:[EMAIL PROTECTED] > Sent: den 19 april 2007 10:44 > To: Maven Users List > Subject: Re: Plugin execution for a specific packaging > > So yes it is possible, but not declarativly.. > > (I just read your post again, and see that you are using standard Maven > mojo's and are not developing your own.) > > You probably noticed that running a mojo for all projects is easy. But > that > running for a subtype is more work. > > You could consider using an inheritance tree for your poms. > > + toplevel pom > --jar pom > ----FooBar pom > --ejb pom > ----FooBarEjb pom > > You would then define the checkstyle stuff in the jar of ejb poms. > > But it will probably not fit somewhere. > > jeroen > > > On 19/04/07, Jeroen Leenarts < [EMAIL PROTECTED]> wrote: > > > > This will wett your appetite: > > > > /** > > * @parameter expression="${project.packaging}" > > * @readonly > > */ > > private String packaging; > > > > /** > > * @see org.apache.maven.plugin.Mojo#execute () > > */ > > public void execute() throws MojoExecutionException, > > MojoFailureException { > > getLog().info(packaging); > > if (packaging == null || !packaging.equals("ejb")) { > > > > Regards, > > > > Jeroen > > > > On 19/04/07, Peter Nilsson < [EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > I have a build tree with 30+ projects of different packaging (jar, > pom, > > > dll, > > > so, plugin, etc) built with Maven and I would like to specify in the > top > > > pom.xml that certain plugins are used for all projects of a given > > > packaging. > > > For example, I would like to have the CheckStyle plugin run on all > > > projects > > > with packaging "jar". > > > > > > Of course I can set the configuration of the plugins in the top pom > > > (with a > > > pluginmanagement tag) and then just invoke the plugin explicitly in > the > > > projects but I would like to enforce that the plugin is used for all > > > projects of the given packaging. It is very easy for example to > forget > > > to > > > add CheckStyle to a new jar project. > > > > > > Adding the possibility of using a packaging filter to an execution > > > element > > > would solve it, but there are perhaps other ways? Any ideas? > > > > > > Peter > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
