2015-12-02 14:59 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> On 02.12.2015 14:46, David Leangen wrote: > >> >> Fully agree about the transitive closedness of a repository. I think we >>>> will need a mechanism to validate this. Ideally already at build time. >>>> Though I am not sure if each repository must be transitively closed. >>>> >>> I also agree. >> >> Actually, bndtools already has a resolution tool for this, but it is >> based on the repositories installed in the workspace. By envoking the >> resolution function, (i) the resolution is validated, and (ii) the runtime >> descriptor (bndrun) file is generated. >> > This is a bit of a different case. bndtools only validates that the > requirements you list can be resolved. > > What we meant is that we should also validate the whole repository. I > think currently it could happen that some bundles in a repository can not > be resolved. > If the repository is created during a build this could point to a problem. > So validation would help to get a good quality for the repository. > >> For example if you would create a repository for your application but >>>> also use a repository for hibernate that is already provided (at some >>>> point) by hibernate. Then you would not want to reiterate all the >>>> bundles from hibernate >>>> in your repository. So maybe we can say that a set of repositories must >>>> be transitively closed. We could use this concept similarly to the >>>> feature validation where you can give the validator maven plugin >>>> additional feature repos to >>>> include. >>>> >>> Remember resource repositories can also point to other resource repositories. > Very well explained. :-) >> >> Or instead of giving additional feature repos, perhaps the other OBRs >> could be provided as arguments. If all the correct OBRs are provided, then >> the system becomes transitively closed. >> > Exactly. There should be a validation that you can call with a list of > obrs. > > >> Perhaps what is missing in enRoute is a karaf runtime integration for >> testing that everything in a bnd workspace properly resolves at runtime. If >> the right OBRs are not provided, and the system is not transitively closed, >> the resolution will throw an error. This would be a quick and easy >> development-time validation of the requirements. If a OBR-referencing >> “feature resolution” works at development time, then normally it should >> also work at runtime. >> > As soon as we also have obr indexes for the karaf features it should be > easier to work with this in bndtools. I read in the bndtools doc that it support multiple kind of repositories. Can't we just add support for feature repositories ? > > The more I think about it, the less I think it's a good idea to have >>>>> too much support for applications. It will lack support for some >>>>> features at a later point, and those have been already solved and >>>>> would only support simple use cases. >>>>> >>>> I think that “application” is a misnomer, and leads to a >> misunderstanding of what the “driving” bundle is supposed to accomplish. >> All the “application” bundle does is act as the driving bundle to pull in >> all the requirements. It is actually very similar to the idea of a feature, >> I think. It describes all the requirements to get the >> application/unit/feature/whatever to run. It is best to disassociate the >> concept with an actual “application”. I feel that this is causing confusion. >> >> By the way, bndtools does have a concept of a deployment descriptor >> (bndrun). All it is, really, is just an index of the resolved bundles, i.e. >> the bundles that are available in the workspace, and are therefore >> available to the runtime. The list is simply the output of the resolve >> operation, nothing more. This could easily be done at runtime as well. >> > The result of the resolve in bndtools is not the list of bundles in the > workspace. It is the list of the bundles to be installed. > > Karaf does the same internally in the feature service. You just do not yet > see it as we are lacking support for an obr index that backs a feature > file. As soon as Guillaume pushes his changes it should become clearer what > karaf can do there. Then you just add your indexes and the application > bundle to the feature file and karaf does the resolve step at runtime.t What we would need is the input that was given to the bndtooling during resolution / validation. If we have this, we could certainly have a successful resolution too. Tough having a list of bundles, i.e. the output of the resolution would work too. > > > Christian > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
