I can't build trunk/blueprint has all integration tests fail. Any idea? On Thu, Nov 10, 2011 at 15:57, Guillaume Nodet <[email protected]> wrote:
> 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
