aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <hugh...@apache.org>
Subject Re: Problems deploying blueprint-cm ?
Date Thu, 10 Nov 2011 16:45:34 GMT
On 10 November 2011 16:29, Jeremy Hughes <hughesj@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
>>
>

Mime
View raw message