The problem with using executions is that it forces you to add the obr plugin to all bundle projects and that could be a lot.
For me it's all the same, build bundle, deploy bundle and since there's no point of deploying a bundle to an OBR without being a bundle to start with I think these two plugins would benefit greatly if they were combined. In fact the bundle plugin already has it's own config by using <instructions> so maybe add a <obr> section? Patrick -----Original Message----- From: Stuart McCulloch <[EMAIL PROTECTED]> Sent: Tuesday, January 29, 2008 4:42pm To: [EMAIL PROTECTED], [EMAIL PROTECTED], [email protected] Subject: Re: Bundle and OBR plugins On 30/01/2008, Patrick Shea <[EMAIL PROTECTED]> wrote: > > I've been trying to use these two plugins together but I got the > impression that maven would not let two plugins take over the lifecycle > during the same build. the maven OBR plugin does not specify a lifecycle - you should use executions: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Plugins Since these two are really close maybe it would be a good idea to merge > them. they are already partially merged - the "bundle" packaging lifecycle will invoke code from the OBR plugin to update the local OBR repository.xml file on install the reason they're not fully merged is because the OBR plugin also provides additional goals that are outside of the scope of the bundleplugin - if you want to use these goals from your pom.xml then you only need to add an execution section, as shown later on... (this is how maven works - otherwise you'd end up merging all sorts of plugins into one uber-plugin that would then be much harder to maintain and debug) So the goals would be to > > 1. Add osgi info to manifest (bundle plugin) > 2. Update local obr repository (obr plugin) > 3. Update remote obr repository (obr plugin) 1 + 2 are already there: if you use the 1.2.0 bundleplugin or later you will see it update the local repository.xml file on the install phase. However, 3 is not done because the remote deploy goal from the OBR plugin is not used as much and it can always be enabled on a per-project basis using the following fragment: <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-obr-plugin</artifactId> <version>1.0.0</version> <executions> <execution> <id>obr:deploy</id> <goals> <goal>deployment</goal> </goals> </execution> </executions> </plugin> you then have to enable this goal with an extra flag: mvn deploy -Dmaven.obr.installToRemoteOBR in the next release, I'm updating the OBR plugin to use standard goal names and removing the installToRemoteOBR flag as it's not really needed now (you can achieve the same with profiles in the pom) which means you only need to use the following to enable remote OBR deployment: <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-obr-plugin</artifactId> <version>1.2.0-SNAPSHOT</version> <executions> <execution> <id>obr:deploy</id> <goals> <goal>deploy</goal> </goals> </execution> </executions> </plugin> and it will update the remote OBR on every "mvn deploy" We could add a switch (obr local/remote/off) to turn on/off obr processing. > > This plugin would be tied to the "bundle" project type like the current > bundle plugin. -- Cheers, Stuart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
