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 > > >> > > > > > > > > >
