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
