Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@aries.apache.org
Cc: Guillaume Nodet <gnodet@gmail.com>
Subject: Re: Problems deploying blueprint-cm ?
Date: Thu, 10 Nov 2011 19:45:22 -0500
Message-ID: <2239157.7ZuFCVKPK3@dilbert.dankulp.com>
User-Agent: KMail/4.7.3 (Linux/3.0.1; KDE/4.7.3; x86_64; ; )
In-Reply-To: 
 <CAEQV+EEoGCjh0s77d3yPoi-dFc3t2TV173nwsHuGamdS9QkMnw@mail.gmail.com>
References: 
 <CAEQV+EEz1cAsNZ8j8gmiOjdHkV3WyM+sQ5m1s2jHrj43ZY7gSA@mail.gmail.com>
 <CAEQV+EHcsLTpcTeZ3ASwn1SAMSxUTBN7XiET50=XvvjbKJLDEg@mail.gmail.com>
 <CAEQV+EEoGCjh0s77d3yPoi-dFc3t2TV173nwsHuGamdS9QkMnw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

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 <gnodet@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 <hughesj@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 <gnodet@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
> >> >> >> <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",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