2016-10-19 16:13 GMT+02:00 Christian Schneider <[email protected]>:
> 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. Something like: <bundle>mvn:...</bundle> <bundle>mvn:...</bundle> ... That sounds like a feature to me ;-) Anyway, a custom osgi resource repository can be easily created for an external file by inheriting org.apache.karaf.features.internal.repository.BaseRepository. Just add your new repository into org.apache.karaf.features.internal.region. getRepository and it should work. Again, in the simple cases, if this list of bundles can be generated, it means that the feature itself can be generated, so I'm not sure where the benefit is... > > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
