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 07:49:43 GMT
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