Hmhmh. Strange deduction that you make. From my of view, if the resolver is equal to obr for the feature description then it should be used.
On Tue, Oct 1, 2013 at 11:49 AM, Jean-Baptiste Onofré <[email protected]>wrote: > Why do you want to change this ? > > If resolver="(obr)" is set, but not the OBR feature, it won't be used. And > with resolver="(obr)" and OBR feature, it will use it. > > I don't see any issue with this behaviour. > > Regards > JB > > > On 10/01/2013 11:06 AM, Charles Moulliard wrote: > >> Maybe, we could use 2 values for resolver attribute of <feature/> to >> clarify the situation as OBR is not installed / used by default (values >> --> karaf (default), obr) ? >> >> >> On Tue, Oct 1, 2013 at 10:57 AM, Jean-Baptiste Onofré <[email protected] >> <mailto:[email protected]>> wrote: >> >> If you want to use dependency flag, you have to install the OBR >> feature (which provide Felix OBR), you are right. >> However, most of the users don't care about the OBR resolver, and >> the dependency flag is not used: it's the default behavior. >> >> Regards >> JB >> >> >> On 10/01/2013 10:54 AM, Charles Moulliard wrote: >> >> They don't use it now but to use dependency = true we need felix >> obr >> bundle to calculate 'capabilities' and 'requirements'. So this >> bundle >> must be deployed or do I miss something ? >> >> >> On Tue, Oct 1, 2013 at 10:47 AM, Jean-Baptiste Onofré >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> No, I don't think it's a good idea: 90% of the users don't >> use OBR >> right now. >> >> Regards >> JB >> >> >> On 10/01/2013 09:43 AM, Charles Moulliard wrote: >> >> We should perhaps add by default 'obr' feature on Karaf >> and also >> package >> the bundles required to setup OBR in the distro of >> Karaf. If the >> idea is >> to promote/delegate 'dependency resolution' to OBR for >> bundle >> deployment, that should be there out of the box ? >> >> >> On Tue, Oct 1, 2013 at 9:15 AM, 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 Charles, >> >> you are right, I'm gonna add some description in the >> documentation. >> >> Regards >> JB >> >> >> On 10/01/2013 09:09 AM, Charles Moulliard wrote: >> >> Agree with you but as this feature is not >> documented, >> it is not >> obvious >> for our users that bundle dependency=true >> means that >> obr feature >> must be >> deployed previously on Karaf (which is not the >> case). >> >> >> On Sun, Sep 29, 2013 at 7:55 AM, 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]>>> >> <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>> wrote: >> >> The purpose is dependency is to be used >> by OBR >> resolver >> (else it >> doesn't make sense). >> >> Regards >> JB >> >> >> On 09/28/2013 10:23 AM, Charles Moulliard >> wrote: >> >> I will debug with an example but >> until now the >> <bundle >> dependency="true"> option of feature >> is only >> use when >> OBR is >> installed >> on Karaf. As obr is not deployed by >> default, >> this option is >> never used >> >> See ObrResolver Class line 105-110 >> >> for (Resource res : ress) { >> if >> (!infos.get(res).isDependency(**________)) { >> >> >> >> >> resolver.add(res); >> } >> } >> >> of method (line 76) >> >> public List<BundleInfo> >> resolve(Feature >> feature) >> throws >> Exception { >> >> Regards, >> >> Charles >> >> >> >> >> On Fri, Sep 27, 2013 at 5:23 PM, >> Charles Moulliard >> <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> >> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>>> wrote: >> >> When we install a feature (method >> installFeatures of >> FeaturesServiceImpl, we collect >> BundleInfo and >> check the >> state of >> the bundle but the code does not >> check >> isDependency ....) ? >> >> >> On Fri, Sep 27, 2013 at 5:18 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]>>> >> <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> >> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>>> wrote: >> >> It's in the feature core >> during >> resolution. >> >> Regards >> JB >> >> >> On 09/27/2013 05:15 PM, >> Charles >> Moulliard wrote: >> >> Hi, >> >> When I read the code of >> karaf >> feature, I >> see that >> the field >> isDependency >> of BundleInfoImpl is >> only use by >> class >> CreateKarMojo >> >> /** >> * Read and load the >> bundles and >> configuration files >> contained in >> the features file. >> >> private >> List<Artifact> >> readResources() throws >> MojoExecutionException { >> List<Artifact> >> resources = new >> ArrayList<Artifact>(); >> try { >> >> RepositoryImpl >> featuresRepo >> = new >> >> RepositoryImpl(featuresFile.__**________toURI()); >> >> >> >> >> >> Feature[] >> features = >> featuresRepo.getFeatures(); >> for >> (Feature feature : >> features) { >> for >> (BundleInfo >> bundle : >> feature.getBundles()) { >> if >> (ignoreDependencyFlag || >> (!ignoreDependencyFlag >> && >> !bundle.isDependency())) { >> >> Question: Do we use this >> attribute/field for >> something else >> ? If yes, >> which class/method ? >> >> Regards >> >> -- >> Charles Moulliard >> Apache Committer / >> Architect @RedHat >> Twitter : @cmoulliard | >> Blog : >> http://cmoulliard.blogspot.com >> >> >> -- >> 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]>>> >> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected] >> >>>**> >> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected] >> >> >> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> <mailto:[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 >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Architect >> @RedHat >> Twitter : @cmoulliard | Blog : >> http://cmoulliard.blogspot.com >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Architect @RedHat >> Twitter : @cmoulliard | Blog : >> http://cmoulliard.blogspot.com >> >> >> -- >> 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]>>> >> <mailto:[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 >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Architect @RedHat >> Twitter : @cmoulliard | Blog : >> http://cmoulliard.blogspot.com >> >> >> -- >> 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 >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Architect @RedHat >> Twitter : @cmoulliard | Blog : >> http://cmoulliard.blogspot.com >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Architect @RedHat >> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Architect @RedHat >> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
