You need both. During active development you want to use the newest dependency .. at least for your own artifacts .. sometimes also for remote ones. Then once you do a release you of course want it to be completely static and not change over time.
Christian 2017-06-15 13:12 GMT+02:00 David Leangen <apa...@leangen.net>: > > 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 <ch...@die-schneider.net> > 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 <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> > > > -- -- 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>
