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 <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]>: >> >>> 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 <[email protected]> >>> wrote: >>> >>> > 2015-02-12 21:55 GMT+01:00 Guillaume Nodet <[email protected]>: >>> > >>> > > >>> > > >>> > > 2015-02-12 19:56 GMT+01:00 Achim Nierbeck <[email protected]>: >>> > > >>> > >> 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 < >>> [email protected] >>> > >: >>> > >> >>> > >> > 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 >>> > >> >>> > > >>> > > >>> > >>> >> >>
