Without mvn urls you can either use file urls or http urls. Both suck in some important regards:
A file url requires that the refered jar resides near the OBR. Today most people work with maven repos. So a natural place for an artifact is the local maven repository. It is difficult to point a file url to it as it will always be depending on the user setup. As a workaround file urls worked well for me in bndtools. What I did was to always generrate my OBR content during the build so it was no problem that the urls depend on my setup. This means though that you can never publish the contents of the OBR. The good thing is that you can work with maven SNAPSHOTs this way. For http urls you can point to the http url of a jar in a maven repo like maven central .. there are many downsides though. 1. The url is absolute. So you always point to a certain external resource. So you need additional measures if you want to cache the artifact locally. 2. For maven snapshots the urls in a remote maven repo always change. So you can not point to the newest snapshot which you want to do during active development 3. These absolute urls make you dependent on the external repo availability and you need to open your firewall to access it. mvn urls on the other hand work extremly well in enterprise environments as you can leverage local mvn proxies. You can also access secured reporitories that require authentication. So if you really try to use plain OBR without mvn urls in a maven build it sucks a lot. This is why Peter did the mvn based repos in bndtools 3.3.0. I discussed a lot with him about these. The current state works quite well but unfortunately it is completely outside the OBR spec. So I hope we see improvements in the spec so we can have both a solution that is sec compliant and works well for maven builds. Actually I think this is not only about maven builds. It is about using maven repos which is also very relevant for gradle and other builds. Christian 2017-06-15 8:51 GMT+02:00 David Leangen <apa...@leangen.net>: > > Hi Christian, > > Thanks for this information. > > > There is one big downside to OBR unfortunately. Inside OBR the content > of bundles needs to be refered as a url. While karaf can work with mvn urls > other systems like bndtools can not. Now the problem is that you can not > populate an OBR well without maven urls if your artifacts reside in maven > and you also want to use maven SNAPSHOTs. > > My understanding is that this is very much by design. The reason is to > have a “strongly” curated repository to promote well-behaved and > predictable builds and deployments. > > I could be wrong. Maybe would be good to verify with some of the alliance > peeps. > > > > Another solution is to consider the OBR just as a cache and define the > list of bundles in a pom. Bndtools is going that way and I think karaf > could do the same. So a feature could simply point to a pom or when > deployed to maven we could assume to use the pom of the project the feature > resides in as default. This would allow to simply define OBRs by using a > pom. > > You think bndtools is going that way? Or rather, they are just trying to > bring in more Maven people? I don’t understand what the purpose would be. > If the bundles are already defined in the OBR, why have a second list? > > > Cheers, > =David > > > > > On Jun 15, 2017, at 3:18 PM, Christian Schneider < > ch...@die-schneider.net> wrote: > > > > There is one big downside to OBR unfortunately. Inside OBR the content > of bundles needs to be refered as a url. While karaf can work with mvn urls > other systems like bndtools can not. Now the problem is that you can not > populate an OBR well without maven urls if your artifacts reside in maven > and you also want to use maven SNAPSHOTs. > > > > So I think there is a gap in OBR that needs to be closed. One solution > would be to add the mvn urls to the spec so they are universally accepted. > > > > Another solution is to consider the OBR just as a cache and define the > list of bundles in a pom. Bndtools is going that way and I think karaf > could do the same. So a feature could simply point to a pom or when > deployed to maven we could assume to use the pom of the project the feature > resides in as default. This would allow to simply define OBRs by using a > pom. > > > > Christian > > > > > > 2017-06-14 23:58 GMT+02:00 David Leangen <apa...@leangen.net>: > > > > Hi Guillaume, > > > > Thank you for this assessment. > > > > I agree that Features adds value. Your post explains a lot of good > reasons why this is so. > > > > My question is more about “why compete with OBR?”. Instead of embracing > OBR and working on top of it, it seems that Features want to replace it. > This is causing me to have to make a lot of choices in my deployment > mechanism. > > > > Features could be really helpful for deployment by managing OBRs, > configurations, and other deployment information. They could also manage > versioning better etc. Maybe something like what Apache ACE was trying to > do. However, instead of “adding” value, currently Features are completely > replacing OBR, which I find interesting. But I understand that there is > some legacy to this. Now that it works, it would take some momentum to move > to a more standards-based approach. > > > > > > My current issue is: how can I use Features for Continuous Deployment? I > am having trouble with automation. That is what got me interested in the > idea behind the Features… > > > > > > Cheers, > > =David > > > > > > > >> On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <gno...@apache.org> wrote: > >> > >> So if you consider an OBR as being a collection of resources, each > resource having capabilities and requirements, then a feature repository is > an OBR repository, it's just the syntax is more concise. > >> If you want to look at what the repository look like, you can launch > the following command in karaf: > >> > feature:install --store resolution.json --verbose --simulate scr > >> > >> Then, look at the resolution.json file, it will contain the OBR > repository used by the resolver in a json format. The xml syntax would be > slightly different of course, and a bit more verbose too, but roughly the > same data. > >> I do think the features syntax is a bit more understandable. > >> > >> But you do not want to compare OBR and features. I haven't seen any > OBR repository used which would contain other things than just OSGi bundles. > >> Features is more a deployment artifact than an OSGi bundle, so it's > more to be compared with OSGi subsystems. > >> > >> With pure OBR, you can't group bundles together, you usually don't want > to edit such a repository file manually, so at the end, you can never > really hack the content. It has to be generated, and is mostly generated > only from a set of OSGi bundles. You can't capture all the constraints by > using bundles only. > >> > >> 2017-06-14 7:49 GMT+02:00 David Leangen <apa...@leangen.net>: > >> > >> Hi! > >> > >> I am trying to wrap my head around the differences between an OBR and a > Karaf Feature. The concepts seem to be overlapping. > >> > >> An OBR has an index of the contained bundles, as well as meta > information, which includes requirements and capabilities. An OBR is > therefore very useful for resolving bundles, and partitioning bundles into > some kind of category. It can also be versioned, and can contained > different versions of bundles. An OBR could potentially be used to keep > snapshots of system releases. I believe that this is somewhat how Apache > ACE works. (A Distribution can be rolled back by simply referring to a > different OBR and allowing the system to re-resolve.) The actual bundles > need to be stored somewhere. The OBR index needs to provide links to that > storage. > >> > >> A Karaf Feature is basically an index of bundles (and configurations), > too. I think that it can also be versioned, and can contain different > versions of bundles. Like an OBR, it is very useful for partitioning > bundles into some kind of category, so the groups of bundles can be > manipulated as a single unit. Just like an OBR, the Karaf Feature also > needs to provide a link to the bundles. AFAIU, resolution is done somehow > in Karaf, based on the bundles available via the Features, so in the end > the entire mechanism seems almost identical to what the OBR is doing. > >> > >> > >> So many similarities! > >> > >> > >> I understand that a Feature can include configurations, which is nice, > but why have a competing non-official standard against an official > standard? If configurations is the only problem, then why not build it on > top of OBRs, rather than creating something completely new and different > and competing? > >> > >> Is it to try to force lock-in to Karaf? Or am I completely missing > something? > >> > >> > >> Thanks for explaining! :-) > >> > >> > >> Cheers, > >> =David > >> > >> > >> > >> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> > > > > > > > > > > -- > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
