Unfortunately, I won't have time to do it today (at ApacheCon right now and flying back in a few hours), but I plan to do that on monday, unless someone else want to take a stab at it before that time.
On Fri, Nov 11, 2011 at 07:49, Timothy Ward <[email protected]> wrote: > > Thanks for taking that on Guillaume. > > I think once that change is done then we will have everything we need - > I'm assuming we'll need a respin of the blueprint itests as well as core, > bundle and cm to use the new released versions. Also Jeremy, will the new > blueprint core and CM pull in commit 1198699 (ARIES-773)? It might make the > next application release smoother if it did, and I have no idea how > intertwined that commit is with other fixes. > > Tim Ward > ------------------- > Apache Aries PMC member & Enterprise OSGi advocate > Enterprise OSGi in Action (http://www.manning.com/cummins) > ------------------- > > > > Date: Fri, 11 Nov 2011 05:00:49 -0800 > > Subject: Re: Problems deploying blueprint-cm ? > > From: [email protected] > > To: [email protected] > > > > I'll do the changes related to the ext package today. > > > > On Fri, Nov 11, 2011 at 04:38, Jeremy Hughes <[email protected]> wrote: > > > > > OK, there's been some talk of changes needed before I do a > > > blueprint-core and blueprint-bundle release. Dan's checked-in his > > > change, what's left to do? > > > > > > Thanks, > > > Jeremy > > > > > > On 11 November 2011 12:25, Alasdair Nottingham <[email protected]> wrote: > > > > +1 I'd like to get an agreed upon set of interfaces and utilities for > > > plugging into blueprint. One that we know to keep stable and doesn't > expose > > > the entire implementation. Something to consider as part of a 1.0 > release > > > perhaps? > > > > > > > > Alasdair > > > > > > > > Alasdair Nottingham > > > > > > > > On 11 Nov 2011, at 09:45, Timothy Ward <[email protected]> > wrote: > > > > > > > >> > > > >> Hi, > > > >> > > > >> Exporting the ext package is fine by me, as long as (as you > suggested) > > > we move the implementation classes out of it. While we're moving these > > > things, I'd like to ask whether PropertyPlaceholder is actually API or > not. > > > I know it's extended by CM, so I originally assumed it was, but is that > > > actually the right thing to do? Thoughts? > > > >> > > > >> Tim > > > >> > > > >>> Date: Thu, 10 Nov 2011 15:57:18 -0800 > > > >>> Subject: Re: Problems deploying blueprint-cm ? > > > >>> From: [email protected] > > > >>> To: [email protected] > > > >>> > > > >>> I haven't created the ComponentFactoryMetadata > > > >>> and DependentComponentFactoryMetadata interfaces but they sound to > me > > > like > > > >>> part of the api. > > > >>> Given that, I'm kinda enclined to move back the PropertyPlaceholder > > > >>> and PlaceholdersUtils classes where they were and instead of not > > > exporting > > > >>> the ext package, rather move the only class which is not part of a > > > public > > > >>> api (the ext namespace handler implementation) into a private > > > subpackage. > > > >>> > > > >>> On Thu, Nov 10, 2011 at 13:23, Jeremy Hughes <[email protected]> > > > wrote: > > > >>> > > > >>>> Please go ahead and open JIRAs / make the changes you need in > trunk > > > >>>> and I'll merge them into the branch and release. > > > >>>> > > > >>>> Thanks, > > > >>>> Jeremy > > > >>>> > > > >>>> On 10 November 2011 21:21, Guillaume Nodet <[email protected]> > wrote: > > > >>>>> I'd really like the AbstractPlaceholder to be moved in the utils > > > package > > > >>>> so > > > >>>>> that it can be extended (karaf needs it). > > > >>>>> > > > >>>>> On Thu, Nov 10, 2011 at 12:58, Jeremy Hughes <[email protected] > > > > > wrote: > > > >>>>> > > > >>>>>> On 10 November 2011 17:11, Timothy Ward < > [email protected]> > > > >>>> wrote: > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Can you remeber which artifacts will be affected? I think > > > >>>>>>> blueprint-core, blueprint-bundle and blueprint-itests. I can't > > > >>>> remember > > > >>>>>>> if one of the proxy bundles had a problem in 047 too. > > > >>>>>>> > > > >>>>>>> I suppose we can check the vote history to find out. > > > >>>>>> > > > >>>>>> Three bundles changed in attempt #3 they were from the > blueprint-cm > > > >>>>>> blueprint-core and blueprint-bundle modules. The blueprint-cm > and > > > >>>>>> blueprint-bundle modules are dated 28th Oct, just before I sent > the > > > >>>>>> attempt #3 vote email. The blueprint-core module artifacts are > dated > > > >>>>>> 25th Oct which corresponds to the attempt #1 vote. > > > >>>>>> > > > >>>>>> Are we good to release (0.4.1) what's in trunk for > blueprint-core > > > and > > > >>>>>> then of course release blueprint-bundle to make sure > > > blueprint-bundle > > > >>>>>> contains the correct blueprint-core ? Or are there some fixes > needed > > > >>>>>> before we do that? > > > >>>>>> > > > >>>>>>> > > > >>>>>>> Regards, > > > >>>>>>> > > > >>>>>>> Tim > > > >>>>>>> > > > >>>>>>>> From: [email protected] > > > >>>>>>>> Date: Thu, 10 Nov 2011 16:45:34 +0000 > > > >>>>>>>> Subject: Re: Problems deploying blueprint-cm ? > > > >>>>>>>> To: [email protected] > > > >>>>>>>> > > > >>>>>>>> On 10 November 2011 16:29, Jeremy Hughes <[email protected]> > > > wrote: > > > >>>>>>>>> On 10 November 2011 15:23, Timothy Ward < > [email protected] > > > > > > > >>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800 > > > >>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ? > > > >>>>>>>>>>> From: [email protected] > > > >>>>>>>>>>> To: [email protected] > > > >>>>>>>>>>> > > > >>>>>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward < > > > >>>>>> [email protected]> wrote: > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> That's odd, I don't have any uncommitted changes, but my > > > >>>>>> blueprint-core > > > >>>>>>>>>>>> bundle has the following export package list, which does > > > >>>> include > > > >>>>>> the > > > >>>>>>>>>>>> blueprint utils: > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> Export-Package: > > > >>>>>> org.apache.aries.blueprint;version="0.4";uses:="org.os > > > >>>>>>>>>>>> > > > >>>>>> > > > gi.service.blueprint.reflect,org.osgi.framework,org.w3c.dom",org.apac > > > >>>>>>>>>>>> > > > >>>>>> > > > he.aries.blueprint.mutable;version="0.3.2";uses:="org.osgi.service.bl > > > >>>>>>>>>>>> > > > >>>>>> > > > ueprint.reflect,org.apache.aries.blueprint,org.osgi.framework",org.ap > > > >>>>>>>>>>>> > > > >>>>>> > > > ache.aries.blueprint.ext.evaluator;version="0.3.2",org.apache.aries.b > > > >>>>>>>>>>>> > > > >>>>>> > > > lueprint.services;version="0.4";uses:="org.osgi.framework,org.apache. > > > >>>>>>>>>>>> > > > >>>>>> > > > aries.blueprint,org.osgi.service.blueprint.container",org.apache.arie > > > >>>>>>>>>>>> > > > >>>>>> > > > s.blueprint.utils;version="0.4.0";uses:="org.osgi.framework,org.apach > > > >>>>>>>>>>>> > > > >>>>>> > > > e.aries.blueprint,org.osgi.service.blueprint.reflect,org.apache.aries > > > >>>>>>>>>>>> > > > >>>>>> > > > .blueprint.mutable,org.osgi.service.blueprint.container,org.slf4j,org > > > >>>>>>>>>>>> > > > >>>>>> > > > .apache.aries.blueprint.ext.evaluator,org.apache.aries.blueprint.serv > > > >>>>>>>>>>>> ices",org.osgi.service.blueprint;version="1.0.0" > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> For some reason, that does not seem to be the case with the > > > >>>> released > > > >>>>>>>>>>> artifact.. Not sure what happened. > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> I see what you mean - the artifact in the maven repository > > > doesn't > > > >>>>>> match the source from the oct2011 branch, or the 0.4 tag for > that > > > >>>> bundle... > > > >>>>>>>>>> > > > >>>>>>>>>> We may need Jeremy's input here. It's possible that the > wrong > > > >>>> thing > > > >>>>>> got promoted, or maybe I don't fully understand the release > process! > > > >>>>>>>>> > > > >>>>>>>>> Oh dear. I released the two staging repo's voted on, so I > don't > > > >>>> know > > > >>>>>>>>> what's happened here. I'll look into what's in the Apache > > > releases > > > >>>>>>>>> repo. > > > >>>>>>>> > > > >>>>>>>> This is incredibly frustrating. I can only imagine the > > > blueprint-core > > > >>>>>>>> release that I deleted from the 047 staging repo was > published by > > > >>>>>>>> Nexus instead of the one in the 116 staging repo. I've > checked my > > > >>>>>>>> > > > >>>>>> > > > >>>> > > > > blueprint/blueprint-core/target/checkout/target/org.apache.aries.blueprint.core-0.4.jar > > > >>>>>>>> and it is dated 28th Oct as are the ones in my local .m2 > > > repository, > > > >>>>>>>> whereas the one in the releases repo is dated 25th Oct. So I > > > really > > > >>>>>>>> don't know what has happened here. Since the artifacts will > have > > > >>>>>>>> likely been mirrored the only sensible thing is for me to run > a > > > 0.4.1 > > > >>>>>>>> release of the affected artifacts. > > > >>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> I don't see the core bundle exporting either of the > blueprint > > > >>>> API > > > >>>>>> packages > > > >>>>>>>>>>>> (org.osgi.service.blueprint.container or > > > >>>>>>>>>>>> org.osgi.service.blueprint.reflect), but it does export > the > > > >>>> empty > > > >>>>>> package > > > >>>>>>>>>>>> org.osgi.service.blueprint, which I think is spec > mandated to > > > >>>>>> come from the > > > >>>>>>>>>>>> blueprint implementation. I'll check that one to be sure. > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> Yep, that's right. I was fooled by the fact that it used > > > another > > > >>>>>> api I > > > >>>>>>>>>>> deployed earlier. Sorry about that. > > > >>>>>>>>>>> Note that the spec also mandates that the blueprint > extender > > > >>>>>> provides > > > >>>>>>>>>>> (exporting and not importing) its own api so that multiple > > > >>>>>> extenders can't > > > >>>>>>>>>>> be wired to the same api, as that's what is used to make > sure > > > >>>>>> multiple > > > >>>>>>>>>>> extenders can coexists peacefully. Given the extender > checks > > > for > > > >>>>>>>>>>> compatibilty, if each extender has its own api, and > provided > > > that > > > >>>>>> blueprint > > > >>>>>>>>>>> bundles import the api as mandated by the spec, there's no > > > >>>>>> inconsistency, > > > >>>>>>>>>>> even if you can't easily choose which extender is used for > a > > > >>>> given > > > >>>>>> bundle. > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> As for property placeholder support, my understanding > (based > > > on > > > >>>>>> the cm > > > >>>>>>>>>>>> implementation) was that people who wanted property > > > >>>> placeholders > > > >>>>>> either > > > >>>>>>>>>>>> used or subclassed PropertyPlaceHolder (which is currently > > > >>>> still > > > >>>>>> possible), > > > >>>>>>>>>>>> and that the AbstractPropertyPlaceHolder was for internal > use > > > >>>> by > > > >>>>>> blueprint. > > > >>>>>>>>>>>> I could be wrong with my understanding of the API here, > and if > > > >>>> so > > > >>>>>> I have no > > > >>>>>>>>>>>> problem working to improve/correct it. > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> The PropertyPlaceHolder can be used in some cases, but I > have a > > > >>>>>> custom > > > >>>>>>>>>>> namespace which actually use the > AbstractPropertyPlaceHolder, > > > >>>> where > > > >>>>>> most of > > > >>>>>>>>>>> the processing is done. > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>>> My main aim with the packaging changes is to make sure > that > > > the > > > >>>>>> blueprint > > > >>>>>>>>>>>> bundles use good OSGi practice and therefore define a > proper > > > >>>> API. > > > >>>>>> Previous > > > >>>>>>>>>>>> versions of blueprint have exposed every package, > including > > > >>>>>> classes that I > > > >>>>>>>>>>>> definitely wouldn't expect to be API (for example the > recipes > > > >>>> or > > > >>>>>> the > > > >>>>>>>>>>>> internal parser implementation). I do want it to be > possible > > > to > > > >>>>>> write > > > >>>>>>>>>>>> functional namespace handlers, but I don't expect them to > be > > > >>>> able > > > >>>>>> to change > > > >>>>>>>>>>>> the internal behaviour of blueprint (for example how > beans are > > > >>>>>>>>>>>> instantiated, or injected with dependencies) unless they > are > > > >>>>>> either the ext > > > >>>>>>>>>>>> namespace (which is internal and a bit special) or built > as > > > >>>>>> fragments that > > > >>>>>>>>>>>> add to the core blueprint function. > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> When making this change I was careful to make sure that > any > > > >>>>>> existing > > > >>>>>>>>>>>> namespace handlers I knew of (JPA, TX, CM) were able to > keep > > > >>>>>> working. This > > > >>>>>>>>>>>> did require some changes to the CM bundle, which had > numerous > > > >>>>>> (and some > > > >>>>>>>>>>>> unnecessary) couplings to the blueprint internals, but > not to > > > >>>> the > > > >>>>>> others. > > > >>>>>>>>>>>> Is there something else from blueprint that we should make > > > part > > > >>>>>> of the API, > > > >>>>>>>>>>>> or perhaps expose as a service, to help other namespaces? > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> I'm not aware of anything else for now beyond > > > >>>>>>>>>>> the AbstractPropertyPlaceHolder. > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> Regards, > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> Tim > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>>> Date: Thu, 10 Nov 2011 03:26:39 -0800 > > > >>>>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ? > > > >>>>>>>>>>>>> From: [email protected] > > > >>>>>>>>>>>>> To: [email protected] > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> Actually, it's not exported by blueprint-core either > even if > > > >>>>>> the pom says > > > >>>>>>>>>>>>> so for some reason. Here's the list of exported packages > by > > > >>>>>>>>>>>> blueprint-core > > > >>>>>>>>>>>>> from its manifest: > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> Export-Package: > > > >>>>>> org.apache.aries.blueprint;version="0.4";uses:="org.os > > > >>>>>>>>>>>>> > > > >>>>>> > > > gi.service.blueprint.reflect,org.osgi.framework,org.w3c.dom",org.apac > > > >>>>>>>>>>>>> > > > >>>>>> > > > he.aries.blueprint.mutable;version="0.3.2";uses:="org.osgi.service.bl > > > >>>>>>>>>>>>> > > > >>>>>> > > > ueprint.reflect,org.apache.aries.blueprint,org.osgi.framework",org.ap > > > >>>>>>>>>>>>> > > > >>>>>> > > > ache.aries.blueprint.ext.evaluator;version="0.3.2",org.apache.aries.b > > > >>>>>>>>>>>>> > > > >>>>>> > > > lueprint.services;version="0.4";uses:="org.osgi.framework,org.apache. > > > >>>>>>>>>>>>> > > > >>>>>> > > > aries.blueprint,org.osgi.service.blueprint.container",org.osgi.servic > > > >>>>>>>>>>>>> e.blueprint;version="1.0.0" > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> Also blueprint-core seems to export blueprint-api (I > thought > > > >>>>>> only the > > > >>>>>>>>>>>> full > > > >>>>>>>>>>>>> blueprint bundle was supposed to aggregate those). > > > >>>>>>>>>>>>> So given the util package isn't exported at all, > > > >>>> blueprint-core > > > >>>>>> + > > > >>>>>>>>>>>>> blueprint-cm seems unusable to me. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> As for the util package itself, exporting it is actually > not > > > >>>>>> sufficient. > > > >>>>>>>>>>>>> The PlaceholderUtils is using the > > > >>>> AbstractPropertyPlaceholder > > > >>>>>> to check > > > >>>>>>>>>>>> the > > > >>>>>>>>>>>>> consistency of placeholders, but that class isn't > exported > > > >>>>>> anymore, so > > > >>>>>>>>>>>>> downstream namespace handlers can't use it. Even if we > fix > > > >>>>>>>>>>>> blueprint-core > > > >>>>>>>>>>>>> to export the utils package, that class need to be made > > > >>>>>> available somehow > > > >>>>>>>>>>>>> so that it can be extended, so I suppose it'd have to be > > > >>>> moved > > > >>>>>> to utils > > > >>>>>>>>>>>> too. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> On Thu, Nov 10, 2011 at 03:17, Timothy Ward < > > > >>>>>> [email protected]> > > > >>>>>>>>>>>> wrote: > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Hi Guillaume, > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> org.apache.aries.blueprint.utils is exported by the > > > >>>> blueprint > > > >>>>>> core > > > >>>>>>>>>>>> bundle > > > >>>>>>>>>>>>>> at version 0.4. As you identified in another thread it > > > >>>> should > > > >>>>>> also be > > > >>>>>>>>>>>> being > > > >>>>>>>>>>>>>> exported by the blueprint-bundle, but isn't. As for > > > >>>> deploying > > > >>>>>>>>>>>> blueprint-cm, > > > >>>>>>>>>>>>>> I believe it's possible if you install blueprint-api and > > > >>>>>>>>>>>> blueprint-core, > > > >>>>>>>>>>>>>> but as another approach, doesn't the blueprint-bundle > > > >>>> contain > > > >>>>>> the > > > >>>>>>>>>>>>>> blueprint-cm function by default? I think that should > > > >>>> deploy > > > >>>>>> fine as > > > >>>>>>>>>>>> it's > > > >>>>>>>>>>>>>> what's used in the CM itests. > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> I hope this is helpful. > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Tim > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> Date: Wed, 9 Nov 2011 15:10:44 -0800 > > > >>>>>>>>>>>>>>> Subject: Problems deploying blueprint-cm ? > > > >>>>>>>>>>>>>>> From: [email protected] > > > >>>>>>>>>>>>>>> To: [email protected] > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> Can someone point me to a process for deploying > > > >>>>>> blueprint-cm ? > > > >>>>>>>>>>>>>>> It seems that bundle requires > > > >>>>>> org.apache.aries.blueprint.utils > > > >>>>>>>>>>>> package > > > >>>>>>>>>>>>>>> which isn't exported by any bundle afaik. > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> It really looks like the most recent changes in > blueprint > > > >>>>>> completely > > > >>>>>>>>>>>>>> broke > > > >>>>>>>>>>>>>>> the bundles .... > > > >>>>>>>>>>>>>>> Thoughts welcome ( before I get really pissed ;-) ) > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> -- > > > >>>>>>>>>>>>>>> ------------------------ > > > >>>>>>>>>>>>>>> Guillaume Nodet > > > >>>>>>>>>>>>>>> ------------------------ > > > >>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ > > > >>>>>>>>>>>>>>> ------------------------ > > > >>>>>>>>>>>>>>> Open Source SOA > > > >>>>>>>>>>>>>>> http://fusesource.com > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> -- > > > >>>>>>>>>>>>> ------------------------ > > > >>>>>>>>>>>>> Guillaume Nodet > > > >>>>>>>>>>>>> ------------------------ > > > >>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ > > > >>>>>>>>>>>>> ------------------------ > > > >>>>>>>>>>>>> Open Source SOA > > > >>>>>>>>>>>>> http://fusesource.com > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> -- > > > >>>>>>>>>>> ------------------------ > > > >>>>>>>>>>> Guillaume Nodet > > > >>>>>>>>>>> ------------------------ > > > >>>>>>>>>>> Blog: http://gnodet.blogspot.com/ > > > >>>>>>>>>>> ------------------------ > > > >>>>>>>>>>> Open Source SOA > > > >>>>>>>>>>> http://fusesource.com > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> ------------------------ > > > >>>>> Guillaume Nodet > > > >>>>> ------------------------ > > > >>>>> Blog: http://gnodet.blogspot.com/ > > > >>>>> ------------------------ > > > >>>>> Open Source SOA > > > >>>>> http://fusesource.com > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> ------------------------ > > > >>> Guillaume Nodet > > > >>> ------------------------ > > > >>> Blog: http://gnodet.blogspot.com/ > > > >>> ------------------------ > > > >>> Open Source SOA > > > >>> http://fusesource.com > > > >> > > > > > > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
