Stuart McCulloch wrote:
On 30/01/2008, Patrick Shea <[EMAIL PROTECTED]> wrote:
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.
No that's not quite right - you can add this execution to a single parent
pom that the other projects inherit from.
Composition of many small plugins is one of the key concepts behind maven,
as it gives you the most flexibility.
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.
Except the OBR plugin can also be used with non-bundle packaging artifacts
(ie. to deploy legacy artifacts)
so combining them would only mean we have a lager bundle with a potentially
longer release schedule, as
there's more to update and test per cycle.
+1
-> richard
In fact the bundle plugin already has it's own config by using
<instructions> so maybe add a <obr> section?
I'm not sure what this gains us - the bundleplugin already has OBR related
settings (see 'obrRepository')
The question is whether to add the OBR deploy goal to the bundle lifecycle,
like we already do for install
- and whether to use the same parameter names or make them more consistent
with the other ones
in the bundleplugin.
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]
