re-assigning from default assignee to k.faseela who already started looking into this... copy/paste of private email exchange:
On Thu, Feb 15, 2018 at 12:07 PM, Faseela K <faseela.k@ericsson.com> wrote:
Hi,I was trying to correct infrautils ready’s feature pom, based on Robert’s mail.
The generated feature.xml shows : <bundle>wrap:mvn:org.opendaylight.odlparent/bundles-test-lib/3.0.2</bundle>
However I do not see any bundle dependency in the respective pom, only odlparent feature is there.How will that happen?
With reply:
ready/impl/pom.xml has the dependency to bundles-test-lib you are looking for.
but that POM has the maven-bundle-plugin configuration instructions for BND to <Embed-Dependency> bundles-test-lib (and awaitility & hamcrest-core...), so I'm surprised that the generated feature.xml shows <bundle>wrap:mvn:bundles-test-lib ... it should not, we do not need that - because bundles-test-lib is embedded in ready-impl-1.3.0-SNAPSHOT.jar (it is; I just double checked, just to be sure).
It's funny BTW that in common/features/odl-infrautils-ready/target/feature/feature.xml this problem only affects bundles-test-lib, but not awaitility & hamcrest-core... but that's just a lucky coincence (I suspect because the latter 2 are <scope>test in odlparent, overridden to be scope compile in ready/impl, but that does not affect odl-infrautils-ready).
So the real problem here, and possibly elsewhere as well
, is that the automatic feature generation apparently adds bundle wrap to features for dependencies which are embedded. And I kind of see why... it cannot really know (at the time it generates the feature) that some of dependencies were embedded (in another POM). Some proposed ideas to address this, in the order I would try them:
1. Perhaps playing with the <scope> of such dependencies, say provided instead of runtime for bundles-test-lib in ready/impl/pom.xml, can convince the feature generation to ignore them? Just make sure that the embedding then actually still works with that...
Worth a try... do you want to try that, first?
2. Otherwise, try adding an <exclusions> to the ready-impl <dependency> of common/features/odl-infrautils-ready/pom.xml for bundles-test-lib. This is more likely to work I expect - but it's a bit uglier than 1. because we would duplicate this in two POM.
I expect this problem may affect other features in ODL which depend on bundles which use embedding; I know e.g. in AAA there are some - and think it would be worthwhile to share this more widely - perhaps best after the solution?
merged - thanks k.faseela!