If you do feature:repo-add first with all repositories, sure it works. The resolver doesn't install automatically required feature based on req/cap: it validates the requirement is matched, so you have to install the feature provided the cap. It allows you to "decoupled" the features (without req/cap, you would need to define inner features) and it also works at bundle/feature level.
In the verify goal, it's what you do: you define all features repositories, and then, you add features with <features/> so the cap/req will match. What do you try to achieve ? Install a feature with req and then automatically install features provided the cap ? Regards JB On 20/06/2019 18:41, Ryan Moquin wrote: > In the second example, I'm referring to the repository with the feature > that has the capability though. I'm also referencing it from the test1 > feature with a dependency=true attribute. If I verify the features with > the karaf-maven-plugin, I don't get any validation errors. I only do > when I install from inside Karaf. > > If I use the separate feature repository like above, test1 will fail to > install even with the reference to feature test2, unless I install > feature test2 first, "feature:install test2". I guess that's a little > why I am confused. I'm also confused why the verify doesn't fail. It's > almost like the verify is able to resolve the requirement and > capability, but it can't at runtime. > > Ryan > > > On Thu, Jun 20, 2019 at 10:50 AM Jean-Baptiste Onofré <[email protected] > <mailto:[email protected]>> wrote: > > Hi Ryan, > > it's what I thought: the cap/req are splitted in two repositories, where > each one doesn't know each other ;) > > Here you have different options: > > 1. You can load all features repository in your Karaf distribution (in > etc/org.apache.karaf.features.cfg) > 2. You can refer one repository in another one using <repository/> tag > 3. You can use Cave feature gateway to gather all features in one. > > Regards > JB > > On 20/06/2019 14:57, Ryan Moquin wrote: > > Sure, I figured I would test with a simple example so I can make sure > > I'm not doing anything stupid (I NEEEEEVER do anything stupid). If I > > created a features xml like this: > > > > ---------------------------------------------------------- > > <?xml version="1.0" encoding="UTF-8"?> > > <features name="${project.artifactId}-${project.version}" > > xmlns="http://karaf.apache.org/xmlns/features/v1.5.0"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > > xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.5.0 > > http://karaf.apache.org/xmlns/features/v1.5.0";> > > > > <feature name="test1" version="${project.version}"> > > <requirement>test.env;filter:="(env=np)"</requirement> > > </feature> > > > > <feature name="test2" version="${project.version}"> > > <feature dependency="true">test3</feature> > > </feature> > > > > <feature name="test3" version="${project.version}"> > > <capability>test.env;env=np</capability> > > </feature> > > </features> > > --------------------------------------------- > > > > It works as expected. If I do this: > > > > > -------------------------------------------------------------------------- > > <?xml version="1.0" encoding="UTF-8"?> > > <features name="${project.artifactId}-${project.version}" > > xmlns="http://karaf.apache.org/xmlns/features/v1.5.0"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > > xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.5.0 > > http://karaf.apache.org/xmlns/features/v1.5.0";> > > > > > > > > <repository>mvn:${project.groupId}/test23/${project.version}/xml/features</repository> > > > > <feature name="test1" version="${project.version}"> > > <requirement>test.env;filter:="(env=np)"</requirement> > > </feature> > > </features> > > > -------------------------------------------------------------------------- > > and > > > -------------------------------------------------------------------------- > > <?xml version="1.0" encoding="UTF-8"?> > > <features name="${project.artifactId}-${project.version}" > > xmlns="http://karaf.apache.org/xmlns/features/v1.5.0"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > > xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.5.0 > > http://karaf.apache.org/xmlns/features/v1.5.0";> > > > > <feature name="test2" version="${project.version}"> > > <feature dependency="true">test3</feature> > > </feature> > > > > <feature name="test3" version="${project.version}"> > > <capability>test.env;env=np</capability> > > </feature> > > </features> > > > -------------------------------------------------------------------------- > > > > Then the requirement can't be resolved. I can however install the > test2 > > feature so I know the test23 repo was added. What is curious to me > > though, is why if the above doesn't work, why I don't get a > failure when > > I verify the features for the above. I figured by referencing test2 > > (which lives in the other features.xml in the second case), it was > > discover that it provides the required capability. > > > > In reading the Karaf docs again (which I appreciate because they are > > quite good and I know docs are time consuming and a pain to write :)) > > I'm wondering if I have to install all the features and bundles in the > > other features xml but not auto-start them (I think I saw an > option for > > that)? > > > > Thanks! > > Ryan > > > > On Thu, Jun 20, 2019 at 1:17 AM Jean-Baptiste Onofré > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > Hi Ryan, > > > > Do you mean you are using resources repository (define in > > etc/org.apache.karaf.features.cfg) ? > > > > A features repository can also contains capability and > requirements. > > > > To be able to find the req/cap, the resolver needs to know the > cap/req. > > If they are splitted in different repositories, then you have > first to > > "load" the repositories to be visible by the resolver. Else > the resolver > > won't know "where" the cap is provided. > > > > Cave can help in two ways: > > 1. the features gateway is able to gather several features > repositories > > in a meta-global-one. > > 2. Cave can serve as resources repositories backend > > > > Can you share your test case in order for me to take a look ? > > > > Regards > > JB > > > > On 19/06/2019 23:18, Ryan Moquin wrote: > > > Hi JB, > > > > > > I decided to try the req/cap again. The reason it didn't > work for me > > > before apparently is because a capability satisfying a > requirement > > isn't > > > detected by the resolver if they are in different feature > repositories > > > (which is the same as a feature XML I believe). I tried to > > reference a > > > feature as a dependency in a different repository but it > wouldn't work > > > unless I had it in the same repository. > > > > > > I'm not sure if that's by design or if something like Cave > would be > > > needed for that scenario. Otherwise I need to rethink how I > > handle the > > > requirement and capabilities. I am trying to keep separate > feature > > > repositories because if I aggregate, then it takes longer to > > create the > > > updated aggregate feature xml. > > > > > > Ryan > > > > > > On Sat, Jun 15, 2019, 12:01 PM Jean-Baptiste Onofré > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > Hi Ryan, > > > > > > I will provide a more complete answer (I don't have time > right > > now), but > > > you can take a look on the way we use cap/req in Pax Web > (for > > the HTTP > > > provider capability). > > > > > > Basically, the cap/req are global in the feature resolver, > > considering > > > the req/cap at feature level, but also at bundle level. > > > > > > Regards > > > JB > > > > > > On 15/06/2019 16:28, Ryan Moquin wrote: > > > > I apologize if this is a stupid question. I've been > trying to > > > understand > > > > how to leverage capabilities and requirements in a way > to allow > > > defining > > > > the provisioning of a system by specifying > requirements in a > > feature. > > > > > > > > I've read through the posts on the mailing list about it, > > the docs and > > > > the karaf features.xml but haven't found the information I > > am looking > > > > for. I also tried some experiments with a bundle > providing a > > > capability > > > > and a feature requiring it but it didn't seem to > work. I am > > wondering > > > > if I am just over thinking or over complicating it in > my head. > > > Here are > > > > the questions: > > > > > > > > 1. When a feature specifies a requirement, what is the > > "scope" of > > > > resolution used by the feature resolver? Meaning, does it > > only pick > > > > from features specified within that feature with > dependency=true > > > > specified? Or from any feature defined in the > features.xml > > and any > > > > feature repository defined that provides a satisfying > > capability? > > > > > > > > 2. Can you specify a requirement in a feature for a > requirement > > > > provided by a bundle? > > > > > > > > 3. If a bundle or feature provides a capability, but > you don't > > > specify > > > > you require it. Does it always get considered for > > installation if > > > it's > > > > in a feature that doesn't have dependency=true? > > > > > > > > Part of this is because I still can't understand when > to use > > > > dependency=true for a feature. I am primarily talking > about > > custom > > > > capabilities and requirements I make up myself for a > system > > to pull > > > > things in. > > > > > > > > Not sure if the above questions fully make sense, having a > > hard time > > > > articulating exactly what I am trying to figure out. > > > > > > > > Thanks for any help! > > > > > > > > Ryan > > > > > > -- > > > Jean-Baptiste Onofré > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > > > > -- > > Jean-Baptiste Onofré > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > -- > Jean-Baptiste Onofré > [email protected] <mailto:[email protected]> > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
