I also think the impedance mismatch between maven and osgi is a big
problem when doing OSGi work.
What I do not like though in the bndtools projects I saw till now is
that they all seem to contain a complete set of jars inside the checked
in source.
I know they use this to populate the obr (or similar) repository they
then work with.
This kind of setting up your environment reminds me a lot of the pre
maven era and I think it is a step back. Is there some better solution
to this?
I would at least want all my jars to come from maven so they do not
pollute git.
A similar thing applies for most of the eclipse projects. Most of them
seem to use tycho even when they are completely server side. In the end
they provide their jars in eclipse features that contain the whole wars.
Most of the time they also do not seem to publish to maven central. So
in the end you have a mixture of dependencies that are only in maven and
some that are only in eclipse update sites. This is a really bad situation.
Christian
On 12.12.2014 04:40, David Jencks wrote:
Hopefully you are not using any require-bundle headers.
So you can think in terms of package requirements rather than bundle
dependencies. OBR is pretty much the solution to this, but AFAIK there is no
reasonable way to automate figuring out what set of bundles should be in your
repository. IIRC some versions of nexus (maybe all by now) can generate an xml
file for obr, but I don't think running obr against maven central is likely to
produce results you are happy with.
After being a maven fanatic for many years I now think the impedance mismatches between
maven and osgi are pretty large and given a free hand with a project would probably use a
gradle + bndtools build with a local file system repository (generally under
"cnf" in these builds IIUC for reasons I don't know).
hopefully I haven't misunderstood your question too much...
david jencks
On Dec 11, 2014, at 12:38 PM, Benson Margulies <[email protected]> wrote:
So, here I am, setting up an application that embeds Felix. I need it
to contain a certain collection of bundles -- and then some
dependencies of those bundles.
Plain-old-maven can't help very much with managing those dependencies,
since it can only deal with one version per Group/Artifact, and I
expect to have cases where we need more than one major version of some
things (e.g. Guava).
is there a commonly-used solution to all of this? I'm contemplating
writing a Maven plugin, but I would like to avoid recreating the
wheel.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
