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