Also, if the use case is a simple one, we still have the features-generate-descriptor goal in our plugin that can generate simple features descriptors and I we could also add a goal (or enhance the existing one) to generate the features xml from the resource repository.
Guillaume 2015-12-02 13:34 GMT+01:00 Guillaume Nodet <[email protected]>: > > > 2015-12-02 11:04 GMT+01:00 David Leangen <[email protected]>: > >> >> Hi Guillaume, >> >> Thank you very much for looking into this so quickly! >> >> >> So i've just experimented a bit with this repository. >> I've added the following repository to karaf which could easily be >> generated. >> >> <features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"; >> name="enroute-demo"> >> <resource-repository> >> file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release/index.xml</resource-repository> >> <feature name="enroute-demo"> >> >> <requirement>karaf.identity;filter:="(&(karaf.identity=enroute-demo)(type=karaf.feature))"</requirement> >> </feature> >> </features> >> >> >> What do you mean by “generated”? Do you mind providing a few more details? >> > > 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. > > 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. > > I think we end up with really two different things here: bndtools is > certainly a nice toolchain to build OSGi bundles. It does not look like a > runtime deployment mechanism. And that's what karaf features are. > They should contain enough information for the whole application to be > deployed, eventually the container to be modified (karaf provides > "profiles" which may contain non ConfigAdmin configuration, libraries to > add to the class path, etc...) > It's one thing to generate the bundles, it's a different one to deploy > them in a system, manage the lifecycle of the applications, upgrade > applications, etc... > > 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. > 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. > > Anyway, once the 4.0.x branch has been created, I'll push what I have so > far to master, that will allow you to use the <resource-repository> element > inside features and fix a bunch of other problems related to deploying > resources from those repositories. > > >> >> >> After having fixed a few problems in Karaf, I was at a point where I >> couldn't deploy the feature, because the above feature is not transitively >> closed. It requires 2 extenders (osgi.component >> and osgi.enroute.configurer), but those are not provided in the xml. >> I suppose the information is somewhat given from the list below: >> >> https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/org.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bndrun#L11-L22 >> >> But those informations should appear somewhere, else you can't figure >> what to deploy in order to solve those requirements. >> >> >> Hmmm… >> >> In enRoute, these just get resolved, so I have never really thought about >> it. >> >> My main worry now is about those un satisfied requirements. >> If the generated xml repository only contains the bundles that you are >> writing, we need a way to give a list of bundles that will actually solve >> the requirements that are not satisfied by the generated bundles (such as >> the 2 extenders above), but it could be different requirements on packages, >> services, etc… >> >> >> Maybe it could be a standard "enRoute" repository that we can provide as >> <resources-repository/> or global resource repository ? >> >> >> I personally think this is a great idea! :-) >> >> >> Cheers, >> =David >> >> >
