Hi, >>> What could be done is a command that would create the features >>> repository, given the resource xml repository generated by bnd. It's >>> just about parsing the repository, finding the "application" bundles, >>> and create the above blob of xml. Nothing very difficult from a >>> technical pov.
Cool! >>> Again, the real problem is that I think those repositories should be >>> transitively closed, i.e. they should contain everything needed to >>> actually install and run the application. It's currently not the >>> case, as it seems that bnd will only generate the xml repository for >>> the bundles in the project, not their dependencies. >> 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. >> 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. 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. >>> 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. >>> Imho, if you plan on deploying your bundles in Karaf, you should >>> generate a feature inside your build. For the above, it's just a >>> matter of adding a dependency on the felix scr feature and a bundle >>> dependency on the other extender. The requirement is already there, so perhaps I am missing something. :-( Do you mean that a requirement on that feature would cause the feature to be installed? Why would a requirement on osgi.component not be sufficient, if there is a bundle in an OBR that provides the capability? The enRoute resolver is able to pick it up. I suppose that the idea above about referencing other OBRs would work. It seems to work very well in enRoute. BTW, I am still having trouble understanding why you are advocating that the runtime environment should be fixed during bundle development. Perhaps it is a usual practice, but doesn’t it limit the component-based approach that OSGi is supposed to promote? Components are developed to provide services, and they are developed out of context. The components get composed into a dynamic runtime system. Seems that it is a waste of a very good opportunity to decouple bundle development from deployment, IMHO. Perhaps somebody has already explained, but I would think that such decoupled would be a very good thing. I have bought into the OSGi vision, but coupling deployment to development does not seem compatible with this vision. >> I also think that for the moment the best way is to create the feature >> during the build. Apart from the resource-repository element this should >> not require any enhancements in karaf. >> So it would be a fast way to start and we can gather some experience >> before deciding about further enhancements. As an immediate solution, I would be very happy with this. :-) It is entirely possible that I may end of changing my mind once I see this in action. ;-) Cheers, =David
