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-300 odlparent <p>When we build in Eclipse or VisualStudio we get the following errors:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>The type org.eclipse.jdt.annotation.NonNullByDefault cannot be resolved. It is indirectly referenced from required type org.opendaylight.yangtools.yang.parser.api.YangParserConfiguration{color}{color:#d4d4d4}Java(16777563) </pre> </div></div> <p>This as per the below analysis, this seems to stem from &lt;scope&gt;provided&lt;/scope&gt; dependencies provided by odlparent/pom.xml. Downstreams which do not have those implicit dependencies can observe such missing references.</p> ODLPARENT-300

Revisit annotation artifact dependencies

Improvement Medium Resolved Done Robert Varga mikael petterson pt Fri, 10 Mar 2023 12:46:06 +0000 Sun, 4 Jun 2023 17:10:13 +0000 Tue, 30 May 2023 13:26:59 +0000 13.0.0 General 0 2 <p>Can you provide an example project?</p> <p>You can close it. I could bypass in Eclipse.</p> <p>Thinking about this a bit &#8211; I think I know what is going on.</p> <p>ODL projects are all derived from odlparent, which provides Eclipse annotations as &lt;scope&gt;provided&lt;/scope&gt;, so we do not generally see this issue &#8211; but it kinda is a real one, as for our docs artifacts we need to spell them out.</p> <p>While annotations are completely optional at runtime, at least some of them end up being visible in our API contracts, hence rather than being scope=provided, they should be optional dependencies. This is certainly true of immutables.org and checker-qual (for which we already do some amount of dancing). JDT annotations seem to also fall into this category.</p> <p>At the end of the day these end up falling into three buckets based on their RetentionPolicy:</p> <ul class="alternate" type="square"> <li>RetentionPolicy.SOURCE are clearly scope=provided, as they do not leak outside of build project (@MetaInfServices falls here)</li> <li>RetentionPolicy.CLASS are probably scope=compile, optional=true, which means we need to deal with their packaging (i.e. filter for features)</li> <li>RetentionPolicy.RUNTIME are an extension of RetentionPolicy.CLASS, but we also need to evaluate how our supported runtimes interact with them</li> </ul> <p>Hi <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> <br/> Yes I just found a way to get around this in Eclipse. I disabled Null analysis.</p> <p><span class="image-wrap" style=""><img src="https://jira.opendaylight.org/secure/attachment/18611/18611_image-2023-03-15-14-02-18-101.png" style="border: 0px solid black" /></span></p> <p>So there will be no fix until version 13? We use 8.0.9</p> <p>I guess I can live with it. Thanks for the explanation though.</p> <p>//mikael</p> <p> </p> <p>That's odlparent-13, which may or may not be Potassium.<br/> The project you are seeing this in can be fixed by adding either</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> &lt;dependency&gt; &lt;groupId&gt;org.eclipse.jdt&lt;/groupId&gt; &lt;artifactId&gt;org.eclipse.jdt.annotation&lt;/artifactId&gt; &lt;version&gt;2.2.700&lt;/version&gt; &lt;scope&gt;provided&lt;/scope&gt; &lt;/dependency&gt; </pre> </div></div> <p>(which is what all ODL projects do implicitly) or</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> &lt;dependency&gt; &lt;groupId&gt;org.eclipse.jdt&lt;/groupId&gt; &lt;artifactId&gt;org.eclipse.jdt.annotation&lt;/artifactId&gt; &lt;version&gt;2.2.700&lt;/version&gt; &lt;optional&gt;true&lt;/optional&gt; &lt;/dependency&gt; </pre> </div></div> <p>(which what this issue will end up doing, I think)</p> <p>In both cases you can omit the version if you pick it from odlparent (through a <a href="https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#importing-dependencies" class="external-link" target="_blank" rel="nofollow noopener">dependencyManagement import</a>)</p> <p>An unfortunate side-effect of this is that <a href="https://issues.apache.org/jira/browse/MNG-5227" class="external-link" target="_blank" rel="nofollow noopener">optional stanza is not propagate via dependencyManagement</a>, requiring users to repeat the declaration.</p> <p>So the first cut is in – it requires all dependencies to be explicitly declared, which in turn ends up being quite invasive. We'll see where this goes.</p> <p>Okay, so this ends up being ugly beyond words.</p> <p>The problem is not jdt.annotation, which ends up being an API contract – and hence we just end up 'requires static transitive' it.</p> <p>The problem are other annotations on public class, which DO NOT form API contracts, like:</p> <ul> <li>@SuppressFBWarnings, which we definitely do not want to require transitive to, as they are purely local things to make SpotBugs behave. For that we essentially need to create package-private utility method holders, which are annotated and provide enough rope for the usual code</li> <li>@SuppressModernizer, where we explicitly provide things like bridges to Future.transform(), which invariantly must take Guava's Function. For those we drop the annotation and widen suppression to cover the entire artifact</li> </ul> <p>So we end up battling what is essentially insane tool semantics. I just do not get why a tool like Eclipse would need to resolve an upstream annotation on a private method in a subclass. It is <b>private</b> and <b>retention=CLASS</b> for $DEITY's sake, so the world is not fluffing coming down – but hey, we absolutely <b>MUST</b> resolve it. Okay, yeah, that make some sense – in which universe?! It is by JLS definition a private detail (especially in JPMS world). Why in the seven circles of anti-Valhalla would a subclass ever even care about that?!</p> Relates ODLPARENT-302 Development Rank 0|i044if: