I agree with Christian. <resources-repo/> element in feature, with the
existing global resources repo property (and the commands that I gonna
push) are good for now.
Regards
JB
On 12/02/2015 01:54 PM, Christian Schneider wrote:
On 02.12.2015 13:34, Guillaume Nodet wrote:
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.
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.
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.
I will talk to Tim Ward if he can maybe add such a validation in the
bnd-indexer plugin. I think such a validation would also help projects
that create indexes. Often such projects do not do OSGi tests and the
validation would already give them some safety net.
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.
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.
I think it should also be possible to use the Configurer from enroute if
you like it. As you just need to also install the extender.
So the feature file should be pretty simple. I think it would be
absolutely possible to generate it but it would not save you a lot of
effort.
Christian
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
