https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/ODLPARENT-4 odlparent <p>SingleFeatureTest does not test integration correctly and relies on Maven and compile time dependencies to download and resolve referenced third-party features.</p> <p>This does not test how user will observe installation of features, since any assumtion<br/> about feature already present in local m2 repository could not be made.</p> <p>Operating System: All<br/> Platform: All</p> ODLPARENT-4

SingleFeatureTest requires used features to be present in local m2 Repo

Bug Confirmed Unresolved Unassigned Tony Tkacik Thu, 25 Sep 2014 12:54:49 +0000 Wed, 24 Jan 2018 14:27:06 +0000 General 0 4 <p>SingleFeatureTest moved to odlparent.</p> <p>There are two problems we are facing here:</p> <p>1) features artifacts require an explicit declaration of dependecies to artifacts mentioned in features.xml, so that maven ensures presence of these artifacts in .m2/repository. Failure to do so can lead to downstream breakage, like the one addressed in <a href="https://git.opendaylight.org/gerrit/#/c/35317/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/35317/</a>, where a config file was added to a feature, but openflowplugin tests started failing. Note that in real life feature:install would have worked without any issues.</p> <p>2) artifacts are resolved via .m2 repository only, which does not match what karaf does, as it consults also remote repositories &#8211; hence the above failure. Allowing resolution of artifacts from nexus can lead to the test not validating projects layout correctly, as for example it will not catch the case when a project removes an artifact, but its feature still refers to it, as it would just fetch a stale one from nexus. That would lead to the failure being silent until autorelease happens, which will fail to resolve the artifact due to version bump.</p> <p>These seem to be conflicting requirements, until we realize that there are two distinct cases here: required artifact comes from the project being built, or it comes from an external project (either ODL or third-party).</p> <p>If the artifact is part of the current project, it should only be resolved from .m2/repository, where it is expected to be populated by the current maven build reactor If the artifact is not part of the current project, it should only be resolved from external repository.</p> <p>The core problem lies in how do we determine that a particular artifact is part of build or not. There are two base strategies which are usable:</p> <p>1) rely on ${project.groupId}, which is assigned to projects. This is a good indication whether the artifact is produced in the local project and this mapping is enforced by OpenDaylight infrastructure. Unfortunately it does not quite work for autorelease, as that builds all projects in one maven reactor.</p> <p>2) rely on maven reactor. This is works nicely in autorelease, as it will treat any dependency not part of the reactor as a third-party. Unfortunately if fails to detect removed artifacts and doesn't do the right thing in manual testing (e.g. will not use local artifacts and download immediately).</p> <p>A solution needs to somehow combine these two strategies and find the right set of rules to cover both scenarios. To deal with autorelease case, we may get help from outside in the form of an environment variable/maven property being present, which can give us clue about the build scope in which the test is executing.</p> <p>Is this still relevant after recent <span class="error">&#91;0&#93;</span> strengthening of distribution-check jobs?</p> <p><span class="error">&#91;0&#93;</span> <a href="https://git.opendaylight.org/gerrit/47575" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/47575</a></p> Development External issue ID 2084 External issue URL Issue Type Rank 0|i022pr: