Hi Christian, I don’t know. I think I rather like the idea of the curated repositories that I know won’t shift over time. I can package up a small OBR (with URLs related to the index file) and deploy it somewhere. I can have very fine grained management of my “sets” (I’ll refrain from calling them “features”), including versioned “sets” so I can easily roll back to a previously known working state if needed.
I believe that this is how bnd/enroute is intended to work. Otherwise, you get pure chaos, like the npm world, which works one day and is broken the next because a butterfly in China flapped its wings. (By the way, OBR or Maven, either way I don’t mind, but it’s the predictability/stability that is important to me.) Cheers, =David > On Jun 15, 2017, at 4:54 PM, Christian Schneider <[email protected]> > wrote: > > 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 <[email protected] > <mailto:[email protected]>>: > > 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>>: > > > > 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 <[email protected] > >> <mailto:[email protected]>> 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 <[email protected] > >> <mailto:[email protected]>>: > >> > >> 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 <http://www.liquid-reality.de/> > > > > Open Source Architect > > http://www.talend.com <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>
