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 16:21:18 GMT
Hi,
sorry yeah, it was again a broken bundle.
I did not expect to find jetty and netty bundles to be broken ...

Have a nice weekend!
Fabian

On Fri, Feb 13, 2015 at 1:28 PM, Guillaume Nodet <gnodet@apache.org> wrote:
> Well, no need to, I found the problem.
> Installing the bundle obviously works, but it does not start.
> The reason is that the error message is correct:
> [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))"]]]]
>
> The resolution flag is a directive, not an attribute, so the bundle should
> have
>   resolution:=optional
> instead of
>   resolution=optional
>
> So everything's ok, it's just the bundle which is bad.
>
>
> 2015-02-13 13:17 GMT+01:00 Guillaume Nodet <gnodet@apache.org>:
>
>> 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
View raw message