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 Thu, 12 Feb 2015 20:55:06 GMT
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.


> 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