> 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!
> >
> > 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
