On 10 November 2011 17:11, Timothy Ward<[email protected]> wrote:
Can you remeber which artifacts will be affected? I think
blueprint-core, blueprint-bundle and blueprint-itests. I can't remember
if one of the proxy bundles had a problem in 047 too.
I suppose we can check the vote history to find out.
Three bundles changed in attempt #3 they were from the blueprint-cm
blueprint-core and blueprint-bundle modules. The blueprint-cm and
blueprint-bundle modules are dated 28th Oct, just before I sent the
attempt #3 vote email. The blueprint-core module artifacts are dated
25th Oct which corresponds to the attempt #1 vote.
Are we good to release (0.4.1) what's in trunk for blueprint-core and
then of course release blueprint-bundle to make sure blueprint-bundle
contains the correct blueprint-core ? Or are there some fixes needed
before we do that?
Regards,
Tim
From: [email protected]
Date: Thu, 10 Nov 2011 16:45:34 +0000
Subject: Re: Problems deploying blueprint-cm ?
To: [email protected]
On 10 November 2011 16:29, Jeremy Hughes<[email protected]> wrote:
On 10 November 2011 15:23, Timothy Ward<[email protected]>
wrote:
Date: Thu, 10 Nov 2011 05:40:58 -0800
Subject: Re: Problems deploying blueprint-cm ?
From: [email protected]
To: [email protected]
On Thu, Nov 10, 2011 at 05:32, Timothy Ward<
[email protected]> wrote:
That's odd, I don't have any uncommitted changes, but my
blueprint-core
bundle has the following export package list, which does include
the
blueprint utils:
Export-Package:
org.apache.aries.blueprint;version="0.4";uses:="org.os
gi.service.blueprint.reflect,org.osgi.framework,org.w3c.dom",org.apac
he.aries.blueprint.mutable;version="0.3.2";uses:="org.osgi.service.bl
ueprint.reflect,org.apache.aries.blueprint,org.osgi.framework",org.ap
ache.aries.blueprint.ext.evaluator;version="0.3.2",org.apache.aries.b
lueprint.services;version="0.4";uses:="org.osgi.framework,org.apache.
aries.blueprint,org.osgi.service.blueprint.container",org.apache.arie
s.blueprint.utils;version="0.4.0";uses:="org.osgi.framework,org.apach
e.aries.blueprint,org.osgi.service.blueprint.reflect,org.apache.aries
.blueprint.mutable,org.osgi.service.blueprint.container,org.slf4j,org
.apache.aries.blueprint.ext.evaluator,org.apache.aries.blueprint.serv
ices",org.osgi.service.blueprint;version="1.0.0"
For some reason, that does not seem to be the case with the released
artifact.. Not sure what happened.
I see what you mean - the artifact in the maven repository doesn't
match the source from the oct2011 branch, or the 0.4 tag for that bundle...
We may need Jeremy's input here. It's possible that the wrong thing
got promoted, or maybe I don't fully understand the release process!
Oh dear. I released the two staging repo's voted on, so I don't know
what's happened here. I'll look into what's in the Apache releases
repo.
This is incredibly frustrating. I can only imagine the blueprint-core
release that I deleted from the 047 staging repo was published by
Nexus instead of the one in the 116 staging repo. I've checked my
blueprint/blueprint-core/target/checkout/target/org.apache.aries.blueprint.core-0.4.jar
and it is dated 28th Oct as are the ones in my local .m2 repository,
whereas the one in the releases repo is dated 25th Oct. So I really
don't know what has happened here. Since the artifacts will have
likely been mirrored the only sensible thing is for me to run a 0.4.1
release of the affected artifacts.
I don't see the core bundle exporting either of the blueprint API
packages
(org.osgi.service.blueprint.container or
org.osgi.service.blueprint.reflect), but it does export the empty
package
org.osgi.service.blueprint, which I think is spec mandated to
come from the
blueprint implementation. I'll check that one to be sure.
Yep, that's right. I was fooled by the fact that it used another
api I
deployed earlier. Sorry about that.
Note that the spec also mandates that the blueprint extender
provides
(exporting and not importing) its own api so that multiple
extenders can't
be wired to the same api, as that's what is used to make sure
multiple
extenders can coexists peacefully. Given the extender checks for
compatibilty, if each extender has its own api, and provided that
blueprint
bundles import the api as mandated by the spec, there's no
inconsistency,
even if you can't easily choose which extender is used for a given
bundle.
As for property placeholder support, my understanding (based on
the cm
implementation) was that people who wanted property placeholders
either
used or subclassed PropertyPlaceHolder (which is currently still
possible),
and that the AbstractPropertyPlaceHolder was for internal use by
blueprint.
I could be wrong with my understanding of the API here, and if so
I have no
problem working to improve/correct it.
The PropertyPlaceHolder can be used in some cases, but I have a
custom
namespace which actually use the AbstractPropertyPlaceHolder, where
most of
the processing is done.
My main aim with the packaging changes is to make sure that the
blueprint
bundles use good OSGi practice and therefore define a proper API.
Previous
versions of blueprint have exposed every package, including
classes that I
definitely wouldn't expect to be API (for example the recipes or
the
internal parser implementation). I do want it to be possible to
write
functional namespace handlers, but I don't expect them to be able
to change
the internal behaviour of blueprint (for example how beans are
instantiated, or injected with dependencies) unless they are
either the ext
namespace (which is internal and a bit special) or built as
fragments that
add to the core blueprint function.
When making this change I was careful to make sure that any
existing
namespace handlers I knew of (JPA, TX, CM) were able to keep
working. This
did require some changes to the CM bundle, which had numerous
(and some
unnecessary) couplings to the blueprint internals, but not to the
others.
Is there something else from blueprint that we should make part
of the API,
or perhaps expose as a service, to help other namespaces?
I'm not aware of anything else for now beyond
the AbstractPropertyPlaceHolder.
Regards,
Tim
Date: Thu, 10 Nov 2011 03:26:39 -0800
Subject: Re: Problems deploying blueprint-cm ?
From: [email protected]
To: [email protected]
Actually, it's not exported by blueprint-core either even if
the pom says
so for some reason. Here's the list of exported packages by
blueprint-core
from its manifest:
Export-Package:
org.apache.aries.blueprint;version="0.4";uses:="org.os
gi.service.blueprint.reflect,org.osgi.framework,org.w3c.dom",org.apac
he.aries.blueprint.mutable;version="0.3.2";uses:="org.osgi.service.bl
ueprint.reflect,org.apache.aries.blueprint,org.osgi.framework",org.ap
ache.aries.blueprint.ext.evaluator;version="0.3.2",org.apache.aries.b
lueprint.services;version="0.4";uses:="org.osgi.framework,org.apache.
aries.blueprint,org.osgi.service.blueprint.container",org.osgi.servic
e.blueprint;version="1.0.0"
Also blueprint-core seems to export blueprint-api (I thought
only the
full
blueprint bundle was supposed to aggregate those).
So given the util package isn't exported at all, blueprint-core
+
blueprint-cm seems unusable to me.
As for the util package itself, exporting it is actually not
sufficient.
The PlaceholderUtils is using the AbstractPropertyPlaceholder
to check
the
consistency of placeholders, but that class isn't exported
anymore, so
downstream namespace handlers can't use it. Even if we fix
blueprint-core
to export the utils package, that class need to be made
available somehow
so that it can be extended, so I suppose it'd have to be moved
to utils
too.
On Thu, Nov 10, 2011 at 03:17, Timothy Ward<
[email protected]>
wrote:
Hi Guillaume,
org.apache.aries.blueprint.utils is exported by the blueprint
core
bundle
at version 0.4. As you identified in another thread it should
also be
being
exported by the blueprint-bundle, but isn't. As for deploying
blueprint-cm,
I believe it's possible if you install blueprint-api and
blueprint-core,
but as another approach, doesn't the blueprint-bundle contain
the
blueprint-cm function by default? I think that should deploy
fine as
it's
what's used in the CM itests.
I hope this is helpful.
Tim
Date: Wed, 9 Nov 2011 15:10:44 -0800
Subject: Problems deploying blueprint-cm ?
From: [email protected]
To: [email protected]
Can someone point me to a process for deploying
blueprint-cm ?
It seems that bundle requires
org.apache.aries.blueprint.utils
package
which isn't exported by any bundle afaik.
It really looks like the most recent changes in blueprint
completely
broke
the bundles ....
Thoughts welcome ( before I get really pissed ;-) )
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
