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 Fri, 13 Feb 2015 12:17:28 GMT
Could you raise a JIRA issue and attach the files needed to reproduce the
issue ?
I can have a quick look at it.

2015-02-13 12:48 GMT+01:00 Fabian Lange <fabian.lange@codecentric.de>:

> 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