felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: Bundle and OBR plugins
Date Wed, 30 Jan 2008 04:31:28 GMT
On 30/01/2008, Patrick Shea <patrick@ps1.net> wrote:
>
> 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).


Exactly - a project's parent does not have to be the same as the pom
in the directory above it (ie. the pom which lists the various modules)
so you can control plugin inheritance if you use the right structure.

For example, this is a common layout:

   pom.xml                (no parent, modules = poms, A, B, C)

   poms/pom.xml      (parent = root, modules = X, Y)

   poms/X/pom.xml   (parent = poms)
   poms/Y/pom.xml   (parent = poms)

   A/pom.xml             (parent = X)
   B/pom.xml             (parent = Y)
   C/pom.xml             (parent = X)

where X could be a pom that adds the bundleplugin and OBR plugin to
the build, while Y is a pom that provides plugins for normal jar projects.

I've used this layout in several projects, including ones that add the OBR
plugin to provide deployment of OBR metadata so it's definitely workable.

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.


Yes, and this is possible right now (several people are already doing this)
it's just not configured out of the box because requirements vary so much

For example, some people don't want to upload a remote OBR file when
they deploy (for example, the central repo has no OBR file) - other people
would like to separate OBR deployment from bundle deployment so they
have control over what gets pushed to the remote OBR (or push to many
OBRs at a time)

Pretty much what maven does to a normal jar project.


There's nothing like the OBR metadata file in normal Maven jar projects
(ie. there's no global 'artifacts.xml' file that lists the repository
content)

Anyway, I've started a vote on this subject because this will affect many
people who use both or either of the plugins, and we need to make sure
everyone's voice is heard before deciding one way or another.

Patrick
>
>
> -----Original Message-----
> From: Stuart McCulloch <stuart.mcculloch@jayway.net>
> Sent: Tuesday, January 29, 2008 6:51pm
> To: dev@felix.apache.org
> Cc: patrick@ps1.net, users@felix.apache.org
> Subject: Re: Bundle and OBR plugins
>
> On 30/01/2008, Patrick Shea <patrick@ps1.net> 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 <stuart.mcculloch@jayway.net>
> > Sent: Tuesday, January 29, 2008 4:42pm
> > To: dev@felix.apache.org, patrick@ps1.net, users@felix.apache.org
> > Subject: Re: Bundle and OBR plugins
> >
> > On 30/01/2008, Patrick Shea <patrick@ps1.net> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Cheers, Stuart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message