You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Stuart McCulloch <st...@jayway.net> on 2008/01/30 04:46:31 UTC

[VOTE] Future of the maven-obr-plugin

Hi folks,

I'd like to get your feedback about the OBR plugin and its future.

Patrick has suggested merging the OBR plugin with the bundleplugin, because
they both
work with bundles. This is something that was considered in the past, but we
decided to
just add the OBR install goal to the 'bundle' lifecycle and keep the
codebases separate.
( mostly because we wanted to get 1.2.0 out of the door without too much
delay )

Now that we've released stable versions of both plugins, we can consider
this idea again.
In fact there actually two choices that can be implemented independently of
one another:

a)  Merge the OBR plugin and bundleplugin codebases - this means one less
plugin to
     maintain, but could lead to longer release times. It also avoids having
a dependency
     between two plugins (bundleplugin -> OBR plugin), which is a good
thing.

b)  Add the OBR deploy goal to the 'bundle' packaging lifecycle. This is
similar to what
     we already do for the install goal in 1.2.0. However, we should control
this with a flag
     (off by default) to avoid uploading OBR files to servers which aren't
expecting them.

Because there's no real point in doing a) without b) this leads us to 3
possibilities:

[ ] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
lifecycle (a+b)
[ ]  0  keep the plugins separate, but add the OBR deploy goal to the
'bundle' lifecycle (b only)
[ ] -1  keep the bundle and OBR plugins separate and don't change the
'bundle' lifecycle

Vote will run for *72hrs* - only PMC votes will be binding, but anyone can
vote

-- 
Cheers, Stuart

Re: [VOTE] Future of the maven-obr-plugin

Posted by Stuart McCulloch <st...@jayway.net>.
On 30/01/2008, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> On Wednesday 30 January 2008 11:46, Stuart McCulloch wrote:
>
> > b)  Add the OBR deploy goal
>
> Question; Will this integrate into the maven-release-plugin automatically
> as
> well, so that the release will both deploy to Maven repo as well as OBR?


yes it will, as long you enable the flag in the plugin configuration
(remember it would be off by default)
the release plugin will invoke the deploy phase for the project's lifecycle
- which would then include OBR

Cheers
> --
> Niclas Hedhman, Software Developer
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>

-- 
Cheers, Stuart

Re: [VOTE] Future of the maven-obr-plugin

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 30 January 2008 11:46, Stuart McCulloch wrote:

> b)  Add the OBR deploy goal 

Question; Will this integrate into the maven-release-plugin automatically as 
well, so that the release will both deploy to Maven repo as well as OBR?


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

Re: [VOTE] Future of the maven-obr-plugin

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

Am Mittwoch, den 30.01.2008, 11:46 +0800 schrieb Stuart McCulloch:
> [X] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
> lifecycle (a+b)


Regards
Felix


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: [VOTE] Future of the maven-obr-plugin

Posted by Anna Chen <ax...@bjc.org>.
Hi,
Even though my vote isn't binding, I would like to vote for the 4th option that Felix proposed (completely separating the 2 plugins). Otherwise
> [X] -1  keep the bundle and OBR plugins separate and don't change the
> 'bundle' lifecycle
My 2 cents. Thanks.
-Anna

>>> "Felix Meschberger" <fm...@gmail.com> 1/30/2008 9:11 AM >>>
Hi all,

Rereading this an other stuff, I see a fourth solution: Completely
separate the OBR plugin from the bundle plugin, that is to not include
any of the OBR plugin goals in the bundle plugin.

This would break the dependency of the bundle plugin on the OBR plugin
completely IIRC.

Regards
Felix

> 
> Vote will run for *72hrs* - only PMC votes will be binding, but anyone can
> vote



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: [VOTE] Future of the maven-obr-plugin

Posted by Stuart McCulloch <st...@jayway.net>.
On 30/01/2008, Patrick Forhan <fe...@muddyhorse.com> wrote:
>
> On Jan 30, 2008 9:41 AM, Stuart McCulloch <st...@jayway.net>
> wrote:
> > true, but we'd also lose automatic creation of OBR metadata for
> > the local maven repository, which is a big plus for many users...
>
> I'm a bit of a maven-obr-plugin newbie, but could you be more specific
> here?  What good does putting OBR metadata in the local maven
> repository do?


With the 1.2.0 bundleplugin, every time you install a bundle to your
local maven repository, it automatically updates the OBR metadata
associated with it using code shared with the maven-obr-plugin

(by default it updates "repository.xml" at the root of the repository)

This means you can pull bundles from your local maven repository
into your OSGi application using OBR, which can be useful during
development (as your local repository is like an OBR cache).

Completely separating the bundleplugin from the maven-obr-plugin
means that you wouldn't get this OBR metadata when installing your
bundles - so you'd then have to use bindex manually* if you wanted
to treat your local repository as an OBR.

(* or customize your pom.xml to add the maven-obr-plugin goals)

This leads me on to why we're having this vote...

The maven-obr-plugin also supports updating of remote OBR files
when you deploy bundles to remote servers - and we're thinking
about adding this to the deploy phase of the bundle lifecycle so
that an "mvn deploy" would also update the remote OBR file(s)

(there'd be a flag to turn this feature on/off + additional options)

  Currently, we push our bundles out to several remote
> servers and run bindex on each.
>
> If there's a big win that maven-obr-plugin could do for us, I'd love to
> know.


The maven-obr-plugin uses bindex under the covers and was
designed to help manage local and remote OBRs - I'd suggest
you try the current 1.2.0-SNAPSHOT maven-obr-plugin as this
contains several fixes reported wrt. remote updating of OBR.

Documentation for the maven-obr-plugin can be found here:

   http://felix.apache.org/site/maven-obr-plugin.html

and new features can be requested (or bugs reported) on JIRA
so if there's anything missing - or something that would make
your life easier, feel free to suggest it :)

Pat.
> --
> Defy mediocrity.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Cheers, Stuart

Re: [VOTE] Future of the maven-obr-plugin

Posted by Patrick Forhan <fe...@muddyhorse.com>.
On Jan 30, 2008 9:41 AM, Stuart McCulloch <st...@jayway.net> wrote:
> true, but we'd also lose automatic creation of OBR metadata for
> the local maven repository, which is a big plus for many users...

I'm a bit of a maven-obr-plugin newbie, but could you be more specific
here?  What good does putting OBR metadata in the local maven
repository do?  Currently, we push our bundles out to several remote
servers and run bindex on each.

If there's a big win that maven-obr-plugin could do for us, I'd love to know.

Pat.
-- 
Defy mediocrity.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: [VOTE] Future of the maven-obr-plugin

Posted by Stuart McCulloch <st...@jayway.net>.
On 30/01/2008, Felix Meschberger <fm...@gmail.com> wrote:
>
> Hi all,
>
> Rereading this an other stuff, I see a fourth solution: Completely
> separate the OBR plugin from the bundle plugin, that is to not include
> any of the OBR plugin goals in the bundle plugin.
>
> This would break the dependency of the bundle plugin on the OBR plugin
> completely IIRC.


true, but we'd also lose automatic creation of OBR metadata for
the local maven repository, which is a big plus for many users...

Regards
> Felix
>
> Am Mittwoch, den 30.01.2008, 11:46 +0800 schrieb Stuart McCulloch:
> > Hi folks,
> >
> > I'd like to get your feedback about the OBR plugin and its future.
> >
> > Patrick has suggested merging the OBR plugin with the bundleplugin,
> because
> > they both
> > work with bundles. This is something that was considered in the past,
> but we
> > decided to
> > just add the OBR install goal to the 'bundle' lifecycle and keep the
> > codebases separate.
> > ( mostly because we wanted to get 1.2.0 out of the door without too much
> > delay )
> >
> > Now that we've released stable versions of both plugins, we can consider
> > this idea again.
> > In fact there actually two choices that can be implemented independently
> of
> > one another:
> >
> > a)  Merge the OBR plugin and bundleplugin codebases - this means one
> less
> > plugin to
> >      maintain, but could lead to longer release times. It also avoids
> having
> > a dependency
> >      between two plugins (bundleplugin -> OBR plugin), which is a good
> > thing.
> >
> > b)  Add the OBR deploy goal to the 'bundle' packaging lifecycle. This is
> > similar to what
> >      we already do for the install goal in 1.2.0. However, we should
> control
> > this with a flag
> >      (off by default) to avoid uploading OBR files to servers which
> aren't
> > expecting them.
> >
> > Because there's no real point in doing a) without b) this leads us to 3
> > possibilities:
> >
> > [ ] +1  merge the bundle and OBR plugins and add OBR deploy to the
> 'bundle'
> > lifecycle (a+b)
> > [ ]  0  keep the plugins separate, but add the OBR deploy goal to the
> > 'bundle' lifecycle (b only)
> > [ ] -1  keep the bundle and OBR plugins separate and don't change the
> > 'bundle' lifecycle
> >
> > Vote will run for *72hrs* - only PMC votes will be binding, but anyone
> can
> > vote
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Cheers, Stuart

Re: [VOTE] Future of the maven-obr-plugin

Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,

Rereading this an other stuff, I see a fourth solution: Completely
separate the OBR plugin from the bundle plugin, that is to not include
any of the OBR plugin goals in the bundle plugin.

This would break the dependency of the bundle plugin on the OBR plugin
completely IIRC.

Regards
Felix

Am Mittwoch, den 30.01.2008, 11:46 +0800 schrieb Stuart McCulloch:
> Hi folks,
> 
> I'd like to get your feedback about the OBR plugin and its future.
> 
> Patrick has suggested merging the OBR plugin with the bundleplugin, because
> they both
> work with bundles. This is something that was considered in the past, but we
> decided to
> just add the OBR install goal to the 'bundle' lifecycle and keep the
> codebases separate.
> ( mostly because we wanted to get 1.2.0 out of the door without too much
> delay )
> 
> Now that we've released stable versions of both plugins, we can consider
> this idea again.
> In fact there actually two choices that can be implemented independently of
> one another:
> 
> a)  Merge the OBR plugin and bundleplugin codebases - this means one less
> plugin to
>      maintain, but could lead to longer release times. It also avoids having
> a dependency
>      between two plugins (bundleplugin -> OBR plugin), which is a good
> thing.
> 
> b)  Add the OBR deploy goal to the 'bundle' packaging lifecycle. This is
> similar to what
>      we already do for the install goal in 1.2.0. However, we should control
> this with a flag
>      (off by default) to avoid uploading OBR files to servers which aren't
> expecting them.
> 
> Because there's no real point in doing a) without b) this leads us to 3
> possibilities:
> 
> [ ] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
> lifecycle (a+b)
> [ ]  0  keep the plugins separate, but add the OBR deploy goal to the
> 'bundle' lifecycle (b only)
> [ ] -1  keep the bundle and OBR plugins separate and don't change the
> 'bundle' lifecycle
> 
> Vote will run for *72hrs* - only PMC votes will be binding, but anyone can
> vote
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


RE: [VOTE] Future of the maven-obr-plugin

Posted by Clement Escoffier <cl...@gmail.com>.
+1

Maxime did it at the beginning of the maven-obr-plugin development and undid
it after :-). We should allow to specify a different url for the deployment
than the maven distribution repository too.

Clement

> -----Message d'origine-----
> De : Richard S. Hall [mailto:heavy@ungoverned.org]
> Envoyé : mercredi 30 janvier 2008 09:53
> À : dev@felix.apache.org
> Objet : Re: [VOTE] Future of the maven-obr-plugin
> 
> Stuart McCulloch wrote:
> > [ ] +1  merge the bundle and OBR plugins and add OBR deploy to the
> 'bundle'
> > lifecycle (a+b)
> > [ ]  0  keep the plugins separate, but add the OBR deploy goal to the
> > 'bundle' lifecycle (b only)
> > [ ] -1  keep the bundle and OBR plugins separate and don't change the
> > 'bundle' lifecycle
> 
> Gut feeling, I am more in the 0 or -1 camp, but I won't vote since I
> don't really create too many bundles, so I don't really know which is
> the best approach.
> 
> -> richard


Re: [VOTE] Future of the maven-obr-plugin

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> On 30/01/2008, Richard S. Hall <he...@ungoverned.org> wrote:
>   
>> Stuart McCulloch wrote:
>>     
>>> [ ] +1  merge the bundle and OBR plugins and add OBR deploy to the
>>>       
>> 'bundle'
>>     
>>> lifecycle (a+b)
>>> [ ]  0  keep the plugins separate, but add the OBR deploy goal to the
>>> 'bundle' lifecycle (b only)
>>> [ ] -1  keep the bundle and OBR plugins separate and don't change the
>>> 'bundle' lifecycle
>>>       
>> Gut feeling, I am more in the 0 or -1 camp, but I won't vote since I
>> don't really create too many bundles, so I don't really know which is
>> the best approach.
>>
>> -> richard
>>
>>     
>
> yes, originally I was more in the 0 camp too - but after thinking long
> and hard about the possible benefits I'm going to vote +1 (merge)

I will have to trust your judgment. :-)

-> richard

Re: [VOTE] Future of the maven-obr-plugin

Posted by Stuart McCulloch <st...@jayway.net>.
On 30/01/2008, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Stuart McCulloch wrote:
> > [ ] +1  merge the bundle and OBR plugins and add OBR deploy to the
> 'bundle'
> > lifecycle (a+b)
> > [ ]  0  keep the plugins separate, but add the OBR deploy goal to the
> > 'bundle' lifecycle (b only)
> > [ ] -1  keep the bundle and OBR plugins separate and don't change the
> > 'bundle' lifecycle
>
> Gut feeling, I am more in the 0 or -1 camp, but I won't vote since I
> don't really create too many bundles, so I don't really know which is
> the best approach.
>
> -> richard
>

yes, originally I was more in the 0 camp too - but after thinking long
and hard about the possible benefits I'm going to vote +1 (merge)

-- 
Cheers, Stuart

Re: [VOTE] Future of the maven-obr-plugin

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> [ ] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
> lifecycle (a+b)
> [ ]  0  keep the plugins separate, but add the OBR deploy goal to the
> 'bundle' lifecycle (b only)
> [ ] -1  keep the bundle and OBR plugins separate and don't change the
> 'bundle' lifecycle

Gut feeling, I am more in the 0 or -1 camp, but I won't vote since I 
don't really create too many bundles, so I don't really know which is 
the best approach.

-> richard

Re: [VOTE] Future of the maven-obr-plugin

Posted by Carsten Ziegeler <cz...@apache.org>.
[x] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
lifecycle (a+b)

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: [VOTE] Future of the maven-obr-plugin

Posted by Carsten Ziegeler <cz...@apache.org>.
[x] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
lifecycle (a+b)

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org


Re: [VOTE] Future of the maven-obr-plugin

Posted by Niclas Hedhman <ni...@hedhman.org>.
[x] +1  merge the bundle and OBR plugins and add OBR deploy to the 'bundle'
        lifecycle (a+b)


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug