Blueprint release

[David Jencks <da...@yahoo.com>]

IIUC one of the bad things that happened with the recent blueprint release was that some of the artifacts that actually got released were not the ones voted on.  While there is no way AFAIK to replace or un-release stuff from maven, we should at least release something that we do vote on really soon.  We might be able to make it harder to find the mistaken artifacts on the apache mirror system or at least add a note explaining what happened.

There have also been some compatibility fixes and general testing.  I'd like to encourage everyone to do some more testing and work towards a release of the necessary bundles next week sometime.

I guess the first step will be to figure out which artifacts are the wrong ones.  Does anyone already know?

I think this release will be simple enough that I might be able to successfully be the release manager :-)

Other issues:

- Question about which dependencies to build against--- released/stable or snapshot/dev.  I guess I should try out my profile idea?

- Guillaume changed the proxy code to generally avoid weaving.  IIUC this is not controlled through config admin, but I don't know why not.

- I'd like to get the util changes I made released.

- I think the blueprint api bundle should not be exporting org.osgi.service.blueprint bundle and the core bundle should have a uses clause for its export.  I'll write another note about this.

thanks
david jencks

RE: Blueprint release

[Timothy Ward <ti...@apache.org>]

Comments inline:

Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------


> From: david_jencks@yahoo.com
> Subject: Blueprint release
> Date: Sun, 4 Dec 2011 00:22:37 -0800
> To: dev@aries.apache.org
> 
> IIUC one of the bad things that happened with the recent blueprint release was that some of the artifacts that actually got released were not the ones voted on.  While there is no way AFAIK to replace or un-release stuff from maven, we should at least release something that we do vote on really soon.  We might be able to make it harder to find the mistaken artifacts on the apache mirror system or at least add a note explaining what happened.
> 
> There have also been some compatibility fixes and general testing.  I'd like to encourage everyone to do some more testing and work towards a release of the necessary bundles next week sometime.
> 
> I guess the first step will be to figure out which artifacts are the wrong ones.  Does anyone already know?
> 
> I think this release will be simple enough that I might be able to successfully be the release manager :-)
> 
> Other issues:
> 
> - Question about which dependencies to build against--- released/stable or snapshot/dev.  I guess I should try out my profile idea?

I would expect this release to be built against the latest release versions (mostly 0.4 I think) of everything.

> 
> - Guillaume changed the proxy code to generally avoid weaving.  IIUC this is not controlled through config admin, but I don't know why not.

I think Guillaume has answered this in another thread - In my view adding a CM dependency to proxy forces you to have a lot more installed to control weaving, this isn't ideal as proxy is a pretty low-level bundle in the dependency tree. Also there are timing issues if the config admin service arrives after weaving has started. Using Framework properties is a little less configurable, but much more reliable. It's certainly the approach I had thought about implementing.

> 
> - I'd like to get the util changes I made released.

That's fine with me - I think they can be done as a 0.4.1 release, is this right? If so then it means that the new blueprint release can build against 0.4 but be used with either.

> 
> - I think the blueprint api bundle should not be exporting org.osgi.service.blueprint bundle and the core bundle should have a uses clause for its export.  I'll write another note about this.
> 
> thanks
> david jencks
> 
>