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
