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 > >
