You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/11/10 00:10:44 UTC
Problems deploying blueprint-cm ?
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
Re: Problems deploying blueprint-cm ?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, November 10, 2011 10:00:54 PM Jean-Baptiste Onofré wrote:
> Hi,
>
> it could be helpful for the Karaf update.
>
> AFAIK, Dan would like to include some fixes. It could be a good opportunity.
I just put a 1 line change to fix PART of ARIES-626. I need to start a
discuss about the rest of it and likely won't get to fix it for 0.4.1.
There is always 0.4.2. :-)
Dan
>
> Regards
> JB
>
> On 11/10/2011 09:58 PM, Jeremy Hughes wrote:
> > On 10 November 2011 17:11, Timothy Ward<ti...@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: hughesj@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<hu...@apache.org> wrote:
> >>>> On 10 November 2011 15:23, Timothy Ward<ti...@apache.org>
wrote:
> >>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> >>>>>> Subject: Re: Problems deploying blueprint-cm ?
> >>>>>> From: gnodet@gmail.com
> >>>>>> To: dev@aries.apache.org
> >>>>>>
> >>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward<ti...@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.o
> >>>>>>> sgi.service.bl
> >>>>>>> ueprint.reflect,org.apache.aries.blueprint,org.osgi.fra
> >>>>>>> mework",org.ap
> >>>>>>> ache.aries.blueprint.ext.evaluator;version="0.3.2",org.
> >>>>>>> apache.aries.b
> >>>>>>> lueprint.services;version="0.4";uses:="org.osgi.framewo
> >>>>>>> rk,org.apache.
> >>>>>>> aries.blueprint,org.osgi.service.blueprint.container",o
> >>>>>>> rg.apache.arie
> >>>>>>> s.blueprint.utils;version="0.4.0";uses:="org.osgi.frame
> >>>>>>> work,org.apach
> >>>>>>> e.aries.blueprint,org.osgi.service.blueprint.reflect,or
> >>>>>>> g.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.blu
> >>> eprint.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: gnodet@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.w3
> >>>>>>>> c.dom",org.apac
> >>>>>>>> he.aries.blueprint.mutable;version="0.3.2";uses:="org
> >>>>>>>> .osgi.service.bl
> >>>>>>>> ueprint.reflect,org.apache.aries.blueprint,org.osgi.f
> >>>>>>>> ramework",org.ap
> >>>>>>>> ache.aries.blueprint.ext.evaluator;version="0.3.2",or
> >>>>>>>> g.apache.aries.b
> >>>>>>>> lueprint.services;version="0.4";uses:="org.osgi.frame
> >>>>>>>> work,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<ti...@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: gnodet@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Problems deploying blueprint-cm ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
it could be helpful for the Karaf update.
AFAIK, Dan would like to include some fixes. It could be a good opportunity.
Regards
JB
On 11/10/2011 09:58 PM, Jeremy Hughes wrote:
> On 10 November 2011 17:11, Timothy Ward<ti...@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: hughesj@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<hu...@apache.org> wrote:
>>>> On 10 November 2011 15:23, Timothy Ward<ti...@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>>>>>> Subject: Re: Problems deploying blueprint-cm ?
>>>>>> From: gnodet@gmail.com
>>>>>> To: dev@aries.apache.org
>>>>>>
>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward<ti...@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: gnodet@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<ti...@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: gnodet@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
>>>>>
>>>>
>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems deploying blueprint-cm ?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, November 10, 2011 4:39:55 PM Guillaume Nodet wrote:
> I can't build trunk/blueprint has all integration tests fail. Any idea?
I just did a mvn clean install in blueprint and everything is passing. Not
sure what to suggest.
Dan
> On Thu, Nov 10, 2011 at 15:57, Guillaume Nodet <gn...@gmail.com> 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 <hu...@apache.org> 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 <gn...@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 <hu...@apache.org>
> >>
> >> wrote:
> >> >> On 10 November 2011 17:11, Timothy Ward
> >> >> <ti...@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: hughesj@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
> >> >> >> <hu...@apache.org>
> >>
> >> wrote:
> >> >> >> > On 10 November 2011 15:23, Timothy Ward
> >> >> >> > <ti...@apache.org>>> >>
> >> >> wrote:
> >> >> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> >> >> >> >>> Subject: Re: Problems deploying blueprint-cm ?
> >> >> >> >>> From: gnodet@gmail.com
> >> >> >> >>> To: dev@aries.apache.org
> >> >> >> >>>
> >> >> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> >> >>
> >> >> timothyjward@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",o
> >> >> rg.apac
> >> >>
> >> >> he.aries.blueprint.mutable;version="0.3.2";uses:="org.osgi.ser
> >> >> vice.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.apac
> >> >> he.arie
> >> >>
> >> >> s.blueprint.utils;version="0.4.0";uses:="org.osgi.framework,or
> >> >> g.apach
> >> >>
> >> >> e.aries.blueprint,org.osgi.service.blueprint.reflect,org.apach
> >> >> e.aries
> >> >>
> >> >> .blueprint.mutable,org.osgi.service.blueprint.container,org.sl
> >> >> f4j,org
> >> >>
> >> >> .apache.aries.blueprint.ext.evaluator,org.apache.aries.bluepri
> >> >> nt.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.bluep
> >> rint.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: gnodet@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",o
> >> >> rg.apac
> >> >>
> >> >> he.aries.blueprint.mutable;version="0.3.2";uses:="org.osgi.ser
> >> >> vice.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 <
> >> >>
> >> >> timothyjward@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: gnodet@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
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
I can't build trunk/blueprint has all integration tests fail. Any idea?
On Thu, Nov 10, 2011 at 15:57, Guillaume Nodet <gn...@gmail.com> 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 <hu...@apache.org> 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 <gn...@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 <hu...@apache.org>
>> wrote:
>> >
>> >> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org>
>> wrote:
>> >> >> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
>> >> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>> >> >> >>> Subject: Re: Problems deploying blueprint-cm ?
>> >> >> >>> From: gnodet@gmail.com
>> >> >> >>> To: dev@aries.apache.org
>> >> >> >>>
>> >> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
>> >> timothyjward@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: gnodet@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 <
>> >> timothyjward@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: gnodet@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
>> >
>>
>
>
>
> --
> ------------------------
> 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
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
Unfortunately, I won't have time to do it today (at ApacheCon right now and
flying back in a few hours), but I plan to do that on monday, unless
someone else want to take a stab at it before that time.
On Fri, Nov 11, 2011 at 07:49, Timothy Ward <ti...@apache.org> wrote:
>
> Thanks for taking that on Guillaume.
>
> I think once that change is done then we will have everything we need -
> I'm assuming we'll need a respin of the blueprint itests as well as core,
> bundle and cm to use the new released versions. Also Jeremy, will the new
> blueprint core and CM pull in commit 1198699 (ARIES-773)? It might make the
> next application release smoother if it did, and I have no idea how
> intertwined that commit is with other fixes.
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
> > Date: Fri, 11 Nov 2011 05:00:49 -0800
> > Subject: Re: Problems deploying blueprint-cm ?
> > From: gnodet@gmail.com
> > To: dev@aries.apache.org
> >
> > I'll do the changes related to the ext package today.
> >
> > On Fri, Nov 11, 2011 at 04:38, Jeremy Hughes <hu...@apache.org> wrote:
> >
> > > OK, there's been some talk of changes needed before I do a
> > > blueprint-core and blueprint-bundle release. Dan's checked-in his
> > > change, what's left to do?
> > >
> > > Thanks,
> > > Jeremy
> > >
> > > On 11 November 2011 12:25, Alasdair Nottingham <no...@apache.org> wrote:
> > > > +1 I'd like to get an agreed upon set of interfaces and utilities for
> > > plugging into blueprint. One that we know to keep stable and doesn't
> expose
> > > the entire implementation. Something to consider as part of a 1.0
> release
> > > perhaps?
> > > >
> > > > Alasdair
> > > >
> > > > Alasdair Nottingham
> > > >
> > > > On 11 Nov 2011, at 09:45, Timothy Ward <ti...@apache.org>
> wrote:
> > > >
> > > >>
> > > >> 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: gnodet@gmail.com
> > > >>> To: dev@aries.apache.org
> > > >>>
> > > >>> 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 <hu...@apache.org>
> > > 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 <gn...@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 <hughesj@apache.org
> >
> > > wrote:
> > > >>>>>
> > > >>>>>> On 10 November 2011 17:11, Timothy Ward <
> timothyjward@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: hughesj@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 <hu...@apache.org>
> > > wrote:
> > > >>>>>>>>> On 10 November 2011 15:23, Timothy Ward <
> timothyjward@apache.org
> > > >
> > > >>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> > > >>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ?
> > > >>>>>>>>>>> From: gnodet@gmail.com
> > > >>>>>>>>>>> To: dev@aries.apache.org
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> > > >>>>>> timothyjward@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: gnodet@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 <
> > > >>>>>> timothyjward@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: gnodet@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
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> ------------------------
> > > >>> 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
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
I'll do the changes related to the ext package today.
On Fri, Nov 11, 2011 at 04:38, Jeremy Hughes <hu...@apache.org> wrote:
> OK, there's been some talk of changes needed before I do a
> blueprint-core and blueprint-bundle release. Dan's checked-in his
> change, what's left to do?
>
> Thanks,
> Jeremy
>
> On 11 November 2011 12:25, Alasdair Nottingham <no...@apache.org> wrote:
> > +1 I'd like to get an agreed upon set of interfaces and utilities for
> plugging into blueprint. One that we know to keep stable and doesn't expose
> the entire implementation. Something to consider as part of a 1.0 release
> perhaps?
> >
> > Alasdair
> >
> > Alasdair Nottingham
> >
> > On 11 Nov 2011, at 09:45, Timothy Ward <ti...@apache.org> wrote:
> >
> >>
> >> 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: gnodet@gmail.com
> >>> To: dev@aries.apache.org
> >>>
> >>> 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 <hu...@apache.org>
> 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 <gn...@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 <hu...@apache.org>
> wrote:
> >>>>>
> >>>>>> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org>
> wrote:
> >>>>>>>>> On 10 November 2011 15:23, Timothy Ward <timothyjward@apache.org
> >
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> >>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ?
> >>>>>>>>>>> From: gnodet@gmail.com
> >>>>>>>>>>> To: dev@aries.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> >>>>>> timothyjward@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: gnodet@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 <
> >>>>>> timothyjward@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: gnodet@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
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> ------------------------
> >>> 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
RE: Problems deploying blueprint-cm ?
Posted by Timothy Ward <ti...@apache.org>.
Thanks for taking that on Guillaume.
I think once that change is done then we will have everything we need - I'm assuming we'll need a respin of the blueprint itests as well as core, bundle and cm to use the new released versions. Also Jeremy, will the new blueprint core and CM pull in commit 1198699 (ARIES-773)? It might make the next application release smoother if it did, and I have no idea how intertwined that commit is with other fixes.
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> Date: Fri, 11 Nov 2011 05:00:49 -0800
> Subject: Re: Problems deploying blueprint-cm ?
> From: gnodet@gmail.com
> To: dev@aries.apache.org
>
> I'll do the changes related to the ext package today.
>
> On Fri, Nov 11, 2011 at 04:38, Jeremy Hughes <hu...@apache.org> wrote:
>
> > OK, there's been some talk of changes needed before I do a
> > blueprint-core and blueprint-bundle release. Dan's checked-in his
> > change, what's left to do?
> >
> > Thanks,
> > Jeremy
> >
> > On 11 November 2011 12:25, Alasdair Nottingham <no...@apache.org> wrote:
> > > +1 I'd like to get an agreed upon set of interfaces and utilities for
> > plugging into blueprint. One that we know to keep stable and doesn't expose
> > the entire implementation. Something to consider as part of a 1.0 release
> > perhaps?
> > >
> > > Alasdair
> > >
> > > Alasdair Nottingham
> > >
> > > On 11 Nov 2011, at 09:45, Timothy Ward <ti...@apache.org> wrote:
> > >
> > >>
> > >> 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: gnodet@gmail.com
> > >>> To: dev@aries.apache.org
> > >>>
> > >>> 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 <hu...@apache.org>
> > 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 <gn...@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 <hu...@apache.org>
> > wrote:
> > >>>>>
> > >>>>>> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org>
> > wrote:
> > >>>>>>>>> On 10 November 2011 15:23, Timothy Ward <timothyjward@apache.org
> > >
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> > >>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ?
> > >>>>>>>>>>> From: gnodet@gmail.com
> > >>>>>>>>>>> To: dev@aries.apache.org
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> > >>>>>> timothyjward@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: gnodet@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 <
> > >>>>>> timothyjward@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: gnodet@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
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> ------------------------
> > >>> 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
Re: Problems deploying blueprint-cm ?
Posted by Jeremy Hughes <hu...@apache.org>.
OK, there's been some talk of changes needed before I do a
blueprint-core and blueprint-bundle release. Dan's checked-in his
change, what's left to do?
Thanks,
Jeremy
On 11 November 2011 12:25, Alasdair Nottingham <no...@apache.org> wrote:
> +1 I'd like to get an agreed upon set of interfaces and utilities for plugging into blueprint. One that we know to keep stable and doesn't expose the entire implementation. Something to consider as part of a 1.0 release perhaps?
>
> Alasdair
>
> Alasdair Nottingham
>
> On 11 Nov 2011, at 09:45, Timothy Ward <ti...@apache.org> wrote:
>
>>
>> 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: gnodet@gmail.com
>>> To: dev@aries.apache.org
>>>
>>> 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 <hu...@apache.org> 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 <gn...@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 <hu...@apache.org> wrote:
>>>>>
>>>>>> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
>>>>>>>>> On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ?
>>>>>>>>>>> From: gnodet@gmail.com
>>>>>>>>>>> To: dev@aries.apache.org
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
>>>>>> timothyjward@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: gnodet@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 <
>>>>>> timothyjward@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: gnodet@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
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>
Re: Problems deploying blueprint-cm ?
Posted by Alasdair Nottingham <no...@apache.org>.
+1 I'd like to get an agreed upon set of interfaces and utilities for plugging into blueprint. One that we know to keep stable and doesn't expose the entire implementation. Something to consider as part of a 1.0 release perhaps?
Alasdair
Alasdair Nottingham
On 11 Nov 2011, at 09:45, Timothy Ward <ti...@apache.org> wrote:
>
> 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: gnodet@gmail.com
>> To: dev@aries.apache.org
>>
>> 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 <hu...@apache.org> 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 <gn...@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 <hu...@apache.org> wrote:
>>>>
>>>>> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
>>>>>>>> On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>>>>>>>>>> Subject: Re: Problems deploying blueprint-cm ?
>>>>>>>>>> From: gnodet@gmail.com
>>>>>>>>>> To: dev@aries.apache.org
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
>>>>> timothyjward@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: gnodet@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 <
>>>>> timothyjward@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: gnodet@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
>>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
RE: Problems deploying blueprint-cm ?
Posted by Timothy Ward <ti...@apache.org>.
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: gnodet@gmail.com
> To: dev@aries.apache.org
>
> 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 <hu...@apache.org> 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 <gn...@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 <hu...@apache.org> wrote:
> > >
> > >> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
> > >> >> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
> > >> wrote:
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> > >> >> >>> Subject: Re: Problems deploying blueprint-cm ?
> > >> >> >>> From: gnodet@gmail.com
> > >> >> >>> To: dev@aries.apache.org
> > >> >> >>>
> > >> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> > >> timothyjward@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: gnodet@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 <
> > >> timothyjward@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: gnodet@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
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <hu...@apache.org> 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 <gn...@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 <hu...@apache.org> wrote:
> >
> >> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
> >> >> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
> >> wrote:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> >> >> >>> Subject: Re: Problems deploying blueprint-cm ?
> >> >> >>> From: gnodet@gmail.com
> >> >> >>> To: dev@aries.apache.org
> >> >> >>>
> >> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> >> timothyjward@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: gnodet@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 <
> >> timothyjward@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: gnodet@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
> >
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Problems deploying blueprint-cm ?
Posted by Jeremy Hughes <hu...@apache.org>.
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 <gn...@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 <hu...@apache.org> wrote:
>
>> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
>> >> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>> >> >>> Subject: Re: Problems deploying blueprint-cm ?
>> >> >>> From: gnodet@gmail.com
>> >> >>> To: dev@aries.apache.org
>> >> >>>
>> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
>> timothyjward@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: gnodet@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 <
>> timothyjward@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: gnodet@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
>
Re: Problems deploying blueprint-cm ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Definitely +1
Currently, we copy/paste the code from Aries in Karaf :/
If we can avoid it, it's much better.
Regards
JB
On 11/10/2011 10:21 PM, Guillaume Nodet 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<hu...@apache.org> wrote:
>
>> On 10 November 2011 17:11, Timothy Ward<ti...@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: hughesj@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<hu...@apache.org> wrote:
>>>>> On 10 November 2011 15:23, Timothy Ward<ti...@apache.org>
>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>>>>>>> Subject: Re: Problems deploying blueprint-cm ?
>>>>>>> From: gnodet@gmail.com
>>>>>>> To: dev@aries.apache.org
>>>>>>>
>>>>>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward<
>> timothyjward@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: gnodet@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<
>> timothyjward@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: gnodet@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
>>>>>>
>>>>>
>>>
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <hu...@apache.org> wrote:
> On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
> >> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org>
> wrote:
> >> >>
> >> >>
> >> >>
> >> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> >> >>> Subject: Re: Problems deploying blueprint-cm ?
> >> >>> From: gnodet@gmail.com
> >> >>> To: dev@aries.apache.org
> >> >>>
> >> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <
> timothyjward@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: gnodet@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 <
> timothyjward@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: gnodet@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
Re: Problems deploying blueprint-cm ?
Posted by Jeremy Hughes <hu...@apache.org>.
On 10 November 2011 17:11, Timothy Ward <ti...@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: hughesj@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 <hu...@apache.org> wrote:
>> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org> wrote:
>> >>
>> >>
>> >>
>> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>> >>> Subject: Re: Problems deploying blueprint-cm ?
>> >>> From: gnodet@gmail.com
>> >>> To: dev@aries.apache.org
>> >>>
>> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <ti...@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: gnodet@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 <ti...@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: gnodet@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
>> >>
>> >
>
RE: Problems deploying blueprint-cm ?
Posted by Timothy Ward <ti...@apache.org>.
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.
Regards,
Tim
> From: hughesj@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 <hu...@apache.org> wrote:
> > On 10 November 2011 15:23, Timothy Ward <ti...@apache.org> wrote:
> >>
> >>
> >>
> >>> Date: Thu, 10 Nov 2011 05:40:58 -0800
> >>> Subject: Re: Problems deploying blueprint-cm ?
> >>> From: gnodet@gmail.com
> >>> To: dev@aries.apache.org
> >>>
> >>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <ti...@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: gnodet@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 <ti...@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: gnodet@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
> >>
> >
Re: Problems deploying blueprint-cm ?
Posted by Jeremy Hughes <hu...@apache.org>.
On 10 November 2011 16:29, Jeremy Hughes <hu...@apache.org> wrote:
> On 10 November 2011 15:23, Timothy Ward <ti...@apache.org> wrote:
>>
>>
>>
>>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>>> Subject: Re: Problems deploying blueprint-cm ?
>>> From: gnodet@gmail.com
>>> To: dev@aries.apache.org
>>>
>>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <ti...@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: gnodet@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 <ti...@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: gnodet@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
>>
>
Re: Problems deploying blueprint-cm ?
Posted by Jeremy Hughes <hu...@apache.org>.
On 10 November 2011 15:23, Timothy Ward <ti...@apache.org> wrote:
>
>
>
>> Date: Thu, 10 Nov 2011 05:40:58 -0800
>> Subject: Re: Problems deploying blueprint-cm ?
>> From: gnodet@gmail.com
>> To: dev@aries.apache.org
>>
>> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <ti...@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.
>
>> >
>> > 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: gnodet@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 <ti...@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: gnodet@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
>
RE: Problems deploying blueprint-cm ?
Posted by Timothy Ward <ti...@apache.org>.
> Date: Thu, 10 Nov 2011 05:40:58 -0800
> Subject: Re: Problems deploying blueprint-cm ?
> From: gnodet@gmail.com
> To: dev@aries.apache.org
>
> On Thu, Nov 10, 2011 at 05:32, Timothy Ward <ti...@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!
> >
> > 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: gnodet@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 <ti...@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: gnodet@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
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Nov 10, 2011 at 05:32, Timothy Ward <ti...@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 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: gnodet@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 <ti...@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: gnodet@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
RE: Problems deploying blueprint-cm ?
Posted by Timothy Ward <ti...@apache.org>.
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"
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.
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.
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?
Regards,
Tim
> Date: Thu, 10 Nov 2011 03:26:39 -0800
> Subject: Re: Problems deploying blueprint-cm ?
> From: gnodet@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 <ti...@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: gnodet@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
Re: Problems deploying blueprint-cm ?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ti...@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: gnodet@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
RE: Problems deploying blueprint-cm ?
Posted by Timothy Ward <ti...@apache.org>.
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: gnodet@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