The plugin will always be activated, but that's not an issue - it will only do something if the packaging is set, or there is an executions element given. So this is the correct approach.
There is not much details I can provide on components.xml other than the examples given. It is actually a very simple format. On 11/11/05, David Jackman <[EMAIL PROTECTED]> wrote: > Would it be possible to set up a parent pom to contain all of the plugin > information necessary so a subproject would only have to specify > <packaging>msm</packaging> (or whatever other type it creates) and > everything would work? Would that go in a pluginManagement section or > the plugins section? If the plugins section (which I would think would > be the case), how do you specify it such that the plugin won't get > activated unless the packaging is the right type? > > ..David.. > > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 10, 2005 12:46 AM > To: Maven Users List > Subject: Re: [m2] building non-jar projects > > The required parts of the documentation are: > - creating a lifecycle mapping for that packaging in components.xml of > your plugin > - specifying your plugin with <extensions>true</extensions> > > On 11/10/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote: > > Hi, > > > > ok, I found much info here: > > http://maven.apache.org/maven2/lifecycle.html > > > > but what I still miss, is how I define that when I run mvn install, it > > > should "see" that it is not a jar module, but for instance a msm > > (InstallShield Merge Module). I know in the pom I should specify: > > > > <packaging>msm</packaging> > > > > But how would I tell Maven to use my plugin for such modules. If you > > could add that information to the above documentation page, I would be > very happy. > > > > regards, > > > > Wim > > > > 2005/11/10, Brett Porter <[EMAIL PROTECTED]>: > > > > > > You would write a plugin that provides an alternative packaging > > > (this allows you to redefine all of the phases). See the guide to > > > the build lifecycle for details. > > > > > > Note that there is collaborative work under way to better support > > > native compilation from Maven - see the recent threads on this list. > > > > > > - Brett > > > > > > On 11/10/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > we are currently using Maven 1 to build c(++) projects and > > > > InstallShield projects. I have written custom goals in my > > > > maven.xml to accomplish > > > this. > > > > Nobody would ever call jar:deploy on such a project but the custom > > > defined > > > > goals. > > > > > > > > How would I do this in Maven 2. I want to avoid that the java > > > > compiler > > > runs > > > > and the jarring happens, but something of my own (a little piece > > > > of ant) runs. For instance, a bit of ant that calls the c compiler > > > > > or > > > InstallShield > > > > compiler and then a bit of ant that zips the result and puts it on > > > > > the > > > local > > > > or remote repository. > > > > > > > > How would I do this? > > > > > > > > regards, > > > > > > > > Wim > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - 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] > > > --------------------------------------------------------------------- > 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]
