karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Karaf 4.0 : new behaviour of the feature resolver
Date Wed, 11 Feb 2015 22:33:24 GMT
2015-02-11 22:06 GMT+01:00 Fabian Lange <fabian.lange@codecentric.de>:

> Hi Guillaume,
> your proposal is interesting but in the current case it would be
> confusing, because you would render it as a tree, right?

Well, not really a tree, more a list.

> the first two nodes of the tree say:
> the service is not there, and your bundle needs it.

The runtime state is only taken into account for bundles that are not part
of the resolution, i.e. the system bundle and any bundle that was not
installed using the feature service.
That's how you can verify at build time that your feature is valid.  In
this case, the feature is not valid.

> Well yes, but I can install the bundle and the service is there and it
> works :-)

But if you would have used the feature verification goal in your build, it
would have failed before you could even try to install the feature ;-)

> So maybe the bundle install also needs stronger validation?

That's out of control of Karaf really.

The metadata is key to make sure an application can work correctly.  The
resolution step ensures that everything will be available for the
Having bad metadata for services is no different than not using versions on
packages and then crying because the resolver did install your bundles, but
at some point, you installed a conflicting bundle and it stopped working.

I think the correct way is to fix the metadata when it's wrong.
I can work on the fix I proposed earlier to ignore effective:="active"
requirements, but I'm not convinced it's a really good idea to lead users
into this way.

> Fabian
> On Wed, Feb 11, 2015 at 10:02 PM, Guillaume Nodet <gnodet@apache.org>
> wrote:
> > On the diagnosis of the error, I'm now quite used to decrypt
> capabilities /
> > requirements. I suppose the ResolutionException message could be
> displayed
> > in a better way.  It currently indicates the path down to the
> requirement,
> > it may be easier to understand it the other way around:
> > - a service of class org.ops4j.pax.url.mvn.MavenResolver can not be found
> >   - which is required by bundle mybundle/1.0.0.SNAPSHOT
> >   - which is required by feature mybundle/1.0.0.SNAPSHOT
> > I suppose the error display could be improved ...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message