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.
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.
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.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
