Bug 6341 Remove copy of dependencies from karaf-parent 49/54449/3
authorEd Warnicke <eaw@cisco.com>
Fri, 5 Aug 2016 22:00:46 +0000 (15:00 -0700)
committerRobert Varga <robert.varga@pantheon.tech>
Thu, 6 Apr 2017 18:53:19 +0000 (20:53 +0200)
commit374d863c760e0584663eeffa40df58fd6729caa5
treea0b491f07edd521e2ba66b6490f5c691a36e629a
parent9efcc59a0ac81ef39186204f44a4b63d49ee909b
Bug 6341 Remove copy of dependencies from karaf-parent

It appears that a lot of bloat is based on the manner in which the transition of
integration/distribution/distribution-karaf was transitioned to using karaf-parent.

There-in lies a tale.  Way back in Helium days... we used a 'dependency' hack for populating system/.
It basically just copied all the dependencies into system/ from the whole shebang.  This had two issues:

a)  Massive overinclusion , as you don't need most of the maven dependencies.
b)  Maven only ever copies *one* version of a thing via the maven dependency mechanisms... so *any* version skew borks you.

To fix this, in Li timeframe I wrote karaf-plugin.  Karaf-plugin walks the features.xml files
and makes sure that we have the needed bundles so all possible features can run.  This radically
reduces the overinclusion, as you are only pulling in the stuff you actually need.
It also solves the version skew problem... which is important because while we don't *want* version skew... it happens.

Because we were at the end of Li, and I did not wish to possibly break someone's
project local distribution, I *only* deployed karaf-plugin to integration/distribution, *not* to karaf-parent.

Since then, others have done good work on karaf-parent (and migrated it to odlparent).
Many thanks to them.  As part of that work, integration/distribution was migrated to use
karaf-parent (again, a good thing).

*But*... this suddenly caused integration/distribution to start doing massive overinclusion again (not good) :(
This appears to account for around 100mb of our size growth since Be.

The correct solution here IMHO would be:

a) To remove the dependency copying behavior of karaf-parent
b) Have the karaf-parent use karaf-plugin

Note: If you do #a without #b... you will likely break the project local distributions.

Sadly, doing #a and #b puts us back in the late breaking change that might impact the
project local distributions place I decided to avoid in Li.  However,
we now have a couple of releases of experience with the karaf-plugin, and thus the risk is somewhat lower.

This patch does #a and #b.

PatchSet #5: Fix karaf-plugin to also install bundles listed in startup.properties as well.

Change-Id: Ie4d99e86cf364fd4fc6d7d99622991133fa3e006
Signed-off-by: Ed Warnicke <eaw@cisco.com>
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
(cherry picked from commit 99f5917863a8bcf66e723fba94dad8e25618a212)
karaf/karaf-parent/pom.xml