On 19.10.2016 15:53, Guillaume Nodet wrote:
2016-10-19 15:28 GMT+02:00 Christian Schneider <[email protected]>:
On 19.10.2016 15:22, Guillaume Nodet wrote:
I disagree.
All the problems come when you start using maven transitive dependencies
in
real projects and hit lots of dependencies which are not OSGi bundles or
not OSGi ready. Think about simple examples like spring, or all the
bundles that we do re-wrap in servicemix.
I think this idea is nice in theory, but it just does not work in real
life.
The idea is to not simply use the transitive dependencies of an existing
project.
Instead you create a pom where you tune the dependencies using excludes
that only the bundles remain that you really want.
I agree that just using any pom will produce bad results.
That sounds like years ago when we migrated from maven 1 to maven 2. Maven
1 did not use transitive dependencies, so suddenly, a lot of unwanted
artifacts were included in the build and we had to use exclusions and
such. The main difference, is that the fact that everyone would be
migrating from maven 1 to maven 2 was quite sure, so it was a transition.
However, I doubt everyone will support OSGi ever, so that's a state, not a
transition.
I think that's the difference.
In order to push user to a direction, we need to make sure it scales to
real projects. Nice tools for beginners can become a pain when you realize
you need to change to something else because they are too limited. Maven
metadata will never be able to support the metadata than a karaf feature
can carry...
I agree it is quite some work. The good thing is that such repository
poms can be used by karaf and bndtools.
I already started providing such poms in Aries RSA and CXF DOSGi. I was
able to build some nice demos for CXF DOSGi using these
poms. So I think it can work and at least scale to support CXF.
I think it will not work as well with camel as the nature of camel is to
integrate many things. So for camel writing features by hand might be
the better option.
On the other hand I found that writing a pom for the depenencies you
need from camel in an actual project is not that difficult. I did this
for the OSGi chat example
were I used camel-irc.
I agree with the problem that maven is not the only build system. So
people who build with gradle will not like the idea of using a pom as a
repo.
Maybe we can supply a simple maven plugin that just outputs a list of
the bundles with maven coordinates. That would also remove the need to
fully resolve pom files.
For gradle we could then simply have a gradle plugin that does the same.
So the effort in karaf would only be to create an OBR index on the fly
from a simple text file with mvn urls.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
