snmp4sdn master has dependency on very old controller:sal artifact (with felix.dm remnant)


Michael Vorburger <vorburger@...>
 

Hi,

I'm trying to clean up the last few remaining un-used felix.dependencymanager dependencies in https://git.opendaylight.org/gerrit/#/q/topic:rm-felix.dependencymanager, and think I'm almost there, but in https://git.opendaylight.org/gerrit/#/c/65189/ have hit an... "interesting" problem in snmp4sdn:

[INFO] --- maven-surefire-plugin:2.18.1:test (default) @ odl-snmp4sdn-snmp4sdn ---
[INFO] Surefire report directory: /home/vorburger/dev/ODL/git/releng-autorelease/snmp4sdn/features/odl-snmp4sdn-snmp4sdn/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 54.297 sec <<< FAILURE! - in org.opendaylight.odlparent.featuretest.SingleFeatureTest
installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl: file:/home/vorburger/dev/ODL/git/releng-autorelease/snmp4sdn/features/odl-snmp4sdn-snmp4sdn/target/feature/feature.xml, Feature: odl-snmp4sdn-snmp4sdn 0.7.0.SNAPSHOT]  Time elapsed: 51.578 sec  <<< ERROR!
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=odl-snmp4sdn-snmp4sdn; type=karaf.feature; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; filter:="(&(osgi.identity=odl-snmp4sdn-snmp4sdn)(type=karaf.feature)(version>=0.7.0.SNAPSHOT)(version<=0.7.0.SNAPSHOT))" [caused by: Unable to resolve odl-snmp4sdn-snmp4sdn/0.7.0.SNAPSHOT: missing requirement [odl-snmp4sdn-snmp4sdn/0.7.0.SNAPSHOT] osgi.identity; osgi.identity=org.opendaylight.snmp4sdn; type=osgi.bundle; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve org.opendaylight.snmp4sdn/0.7.0.SNAPSHOT: missing requirement [org.opendaylight.snmp4sdn/0.7.0.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.opendaylight.controller.sal.packet)(version>=0.7.0)(!(version>=1.0.0)))" [caused by: Unable to resolve org.opendaylight.controller.sal/0.7.0: missing requirement [org.opendaylight.controller.sal/0.7.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.apache.felix.dm)(version>=3.0.0)(!(version>=4.0.0)))"]]]

The package org.opendaylight.controller.sal.packet has, apparently, long been removed from controller - BUT snmp4sdn/snmp4sdn/pom.xml still directly refers to a very old org.opendaylight.controller:sal:0.7.0 - huh?!

I'm surprised building against release artifacts of previous release trains even passes autorelease... shouldn't we detect, prvent and forbid this kind of cross-release mix ups?

Shall we remove snmp4sdn from the release?

Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch


Stephen Kitt <skitt@...>
 

Hi Michael,

On Mon, 6 Nov 2017 18:32:10 +0100
Michael Vorburger <vorburger@...> wrote:
[...]
The package org.opendaylight.controller.sal.packet has, apparently,
long been removed from controller - BUT snmp4sdn/snmp4sdn/pom.xml
still directly refers to a very old
org.opendaylight.controller:sal:0.7.0 - huh?!
Yes... SNMP4SDN depends on AD-SAL, or at least parts of it, I haven’t
looked into the details for a while. Every release, the project manages
to get fixed enough to work, so it’s part of the distribution.

I'm surprised building against release artifacts of previous release
trains even passes autorelease... shouldn't we detect, prvent and
forbid this kind of cross-release mix ups?
We could; the current release refactoring might end up “fixing” this
kind of thing in a different way. The whole thing (SNMP4SDN’s
dependency on AD-SAL, and the release refactoring) brings up the issue
of whether we want to support smaller projects with complex
requirements but limited resources. We have historically, we’ll see
what the community decides going forward...

Shall we remove snmp4sdn from the release?
If the project fails to meet the release requirements, yes. Turning
“removing felix.dm” into a release requirement deserves broader
discussion ;-). (If it comes to that.)

Regards,

Stephen