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 <gno...@gmail.com> 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 <hugh...@apache.org> wrote: > >> On 10 November 2011 17:11, Timothy Ward <timothyjw...@apache.org> 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: hugh...@apache.org >> >> Date: Thu, 10 Nov 2011 16:45:34 +0000 >> >> Subject: Re: Problems deploying blueprint-cm ? >> >> To: dev@aries.apache.org >> >> >> >> On 10 November 2011 16:29, Jeremy Hughes <hugh...@apache.org> wrote: >> >> > On 10 November 2011 15:23, Timothy Ward <timothyjw...@apache.org> >> wrote: >> >> >> >> >> >> >> >> >> >> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800 >> >> >>> Subject: Re: Problems deploying blueprint-cm ? >> >> >>> From: gno...@gmail.com >> >> >>> To: dev@aries.apache.org >> >> >>> >> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward < >> timothyjw...@apache.org> 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: gno...@gmail.com >> >> >>> > > To: dev@aries.apache.org >> >> >>> > > >> >> >>> > > 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 < >> timothyjw...@apache.org> >> >> >>> > 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: gno...@gmail.com >> >> >>> > > > > To: dev@aries.apache.org >> >> >>> > > > > >> >> >>> > > > > 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 >
