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
