Yes you can add the plugin to a parent pom but it means that all sub projects 
are 1) "bundle" projects and b) they all have this parent as their parent (not 
always the case).

I guess my point is that when I do a "mvn deploy" on a project of type "bundle" 
it would be packaged as an osgi bundle and have it's info added to the obr 
repository.

Pretty much what maven does to a normal jar project. 

Patrick                                                                         
                                                                                
                                                                                
                                                                                
         
 

-----Original Message-----
From: Stuart McCulloch <[EMAIL PROTECTED]>
Sent: Tuesday, January 29, 2008 6:51pm
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], users@felix.apache.org
Subject: Re: Bundle and OBR plugins

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.

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], users@felix.apache.org
> 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
>
>
>


-- 
Cheers, Stuart



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to