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

Reply via email to