karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabian Lange <fabian.la...@codecentric.de>
Subject Re: Karaf 4.0 : new behaviour of the feature resolver
Date Fri, 13 Feb 2015 11:48:28 GMT
Hi all,

i just stumbled on a most likely related issue.

I have a my-feature which depends on
mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT

when I do feature:install my-feature
it fails:
[caused by: Unable to resolve io.netty.common/4.1.0.Beta4-SNAPSHOT: missing
requirement [io.netty.common/4.1.0.Beta4-SNAPSHOT] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.0.0)(!(version>=2.0.0))(resolution=optional))"]]]]

when I do bundle:install mvn:io.netty/netty-common/4.1.0.Beta4-SNAPSHOT
it works just fine

Note that the jetty.alpn is declared optional in the netty-common bundle.

Fabian



On Fri, Feb 13, 2015 at 8:49 AM, Guillaume Nodet <gnodet@apache.org> wrote:

> 2015-02-12 21:55 GMT+01:00 Guillaume Nodet <gnodet@apache.org>:
>
> >
> >
> > 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com>:
> >
> >> Hi,
> >>
> >> if it could be possible to add this feature back again, this clearly
> would
> >> help. (the -c option)
> >>
> >
> > Well, it it's just about trying to install the bundles listed in a
> feature
> > and its dependencies, that could be done, but then you'll expect
> everything
> > to work, such as conditionals, configurations, etc...  Now, features can
> > also define capabilities and requirements, so while this is doable, we
> need
> > to clearly define which subset of things we would support in such a mode.
> >
> > Another better way would be to do it in a very different way.  It may be
> > possible to have a mode where the resolution would be done in a loop
> while
> > it succeeds.  If it fails, we collect the missing requirement, add a
> dummy
> > capability to solve it, and run again, or something similar.  We could
> then
> > print the missing requirements and install the bundles.
> > There's already a simulatation mode which runs the resolution and prints
> > the action that needs to be performed without actually modifying the
> > framework, so that could be another mode.  I don't foresee any technical
> > impossibility here, so it may be worth a try if there's a consensus.
> >
>
> Well, there's one problem though, and it's similar to adding a flag to not
> take effective:="active" metadata into account.  The next resolution will
> fail the same way.  One possibility could be to install the bundles into
> "non managed" bundles, i.e. to not persist the fact that the feature was
> required, so that the feature won't cause any problem during the next
> resolution.
>
>
> >
> >
> >> Another interesting fact here, the Require-Capability is only added for
> >> bundles using DS by the maven-bundle-plugin.
> >> Blueprint Bundles don't have it even though that could be generated
> easily
> >> from the reference-tag.
> >>
> >
> > They are.  You're either using an old maven plugin, or you have disabled
> > the generation of the metadata.
> >
> >
> >>
> >> Regarding the feature validation goal, I doubt it would have shown that
> >> the
> >> pax-url-aether bundle was neglecting the providing capabilities manifest
> >> entries. Though I need to verify that with a test-case.
> >>
> >
> > No, you're right, it could not have figured the pax-url-aether bundle was
> > wrong, because there's no way to know that a capability should have been
> > provided.  It's like if you forgot to export a package, no one could tell
> > you.
> > But it would have failed to validate the feature that was using it, i.e.
> > the one you want to install and which currently fail.
> >
> >
> >>
> >> regards, Achim
> >>
> >>
> >> 2015-02-12 0:39 GMT+01:00 Christian Schneider <chris@die-schneider.net
> >:
> >>
> >> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
> >> >
> >> >> The breaking change is that features are now verified before being
> >> >> installed.
> >> >> In karaf < 4, there was no verification step, and the installation
of
> >> the
> >> >> feature was simply trying to install the bundles and start those.
> >> >>
> >> >
> >> > In most cases I like the verification. In some cases though especially
> >> > when I build the deployment I sometimes want the bundles to be
> installed
> >> > even if they do not even resolve.
> >> > The reason is that it is easier to debug what is wrong when the
> bundles
> >> > are in the system. So I would like to have an option to install even
> if
> >> the
> >> > verification fails. Kind of like the option in karaf
> >> > 2 and 3 where you leave the bundles installed in case of a failure.
> >> >
> >> > Doe that make sense?
> >> >
> >> > Christian
> >> >
> >> > --
> >> >  Christian Schneider
> >> > http://www.liquid-reality.de
> >> >
> >> > Open Source Architect
> >> > Talend Application Integration Division http://www.talend.com
> >> >
> >> >
> >>
> >>
> >> --
> >>
> >> Apache Member
> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer &
> >> Project Lead
> >> blog <http://notizblog.nierbeck.de/>
> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >>
> >> Software Architect / Project Manager / Scrum Master
> >>
> >
> >
>

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