You can use the provided scope to make it compile-time only and avoid requiring it as a runtime dependency.
On Tue, 2 Feb 2021 at 05:34, sebb <seb...@gmail.com> wrote: > > On Mon, 1 Feb 2021 at 22:39, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > Well, it's in a 3rd party jar, just like JUnit and whatever else is needed > > to complete a decent build... > > In which case it should surely be listed as a compile dependency so > that it is picked up automatically? > > Users don't have to do anything to extra to use JUnit for testing. > They should not have to do anything extra in order to compile. > > > On Mon, Feb 1, 2021, 17:22 sebb <seb...@gmail.com> wrote: > > > > > On Mon, 1 Feb 2021 at 17:56, Matt Sicker <boa...@gmail.com> wrote: > > > > > > > > Compile time annotations would only be necessary to build the commons > > > > component. > > > > > > i.e. consumers of the source code would be required to provide the > > > annotations in some form. > > > > > > This does not sound ideal. > > > > > > > Unless they're runtime scope, but even that can work > > > > without class loader errors provided you're not reflecting on it. > > > > > > > > On Mon, 1 Feb 2021 at 11:45, sebb <seb...@gmail.com> wrote: > > > > > > > > > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <suzt...@google.com.invalid> > > > wrote: > > > > > > > > > > > > I like "javax.annotation namespace" too. > > > > > > > > > > > > Would you be willing to share more about why the annotation > > > dependency > > > > > > should have "provided" scope? If a library (commons-lang) requires a > > > > > > dependency at runtime, I believe it should declare it as "compile" > > > > > > dependency. > > > > > > > > > > In either case, surely the user will have to provide the relevant > > > > > annotation jar in order to use the component? > > > > > > > > > > > In past, I did troubleshooting for > > > > > > missing javax.annotation.Nullable > > > > > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917 > > > > > > > > > > That link does not work; it ends up displaying the irrelevant issue: > > > > > > > > > > > > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues > > > > > > > > > > The following link works better: > > > > > https://issues.apache.org/jira/browse/BEAM-8917 > > > > > > > > > > > > > > > > On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann < > > > jochen.wiedm...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > as a followup to a discussion, that we had in August 2020, I'd > > > like to > > > > > > > propose, that we introduce the @NonNull, and @Nullable annotations > > > > > > > into commons-lang. > > > > > > > > > > > > > > Since that discussion, I began to gradually introduce those > > > > > > > annotations into my own code. From that, I have learned three > > > things: > > > > > > > > > > > > > > 1.) Although those annotations have RetentionPolicy.RUNTIME, > > > they are > > > > > > > still > > > > > > > invisible at runtime. In particular, they do not impose > > > any > > > > > > > runtime requirements. > > > > > > > We *can* use those annotations, but still remain a > > > standalone > > > > > > > library. > > > > > > > 2.) There is no problem with mixed code: You can have some > > > > > > > classes, that use > > > > > > > those annotations, while others don't. Or, to rephrase > > > that: > > > > > > > Even, if the ultimate > > > > > > > target should be, to use those annotations everywhere, > > > they > > > > > > > can be introduced > > > > > > > gradually on a per-class base. We can have the target as > > > a > > > > > > > long time goal, but > > > > > > > start small. > > > > > > > 3.) Although the annotations aren't present in the compiled > > > code, > > > > > > > they still provide > > > > > > > valuable information, if the source code is present in > > > the > > > > > > > users IDE, because > > > > > > > the user can quickly jump into the respective file. (IDE > > > > > > > support could be enhanced, > > > > > > > for example Eclipse doesn't provide them as quick hints, > > > but > > > > > > > that's something we > > > > > > > can work on. > > > > > > > Besides, static code analysis clearly *does* help (at > > > least > > > > > > > in the current case) to > > > > > > > avoid errors. In my opinion, we are the ones, who are > > > > > > > setting the standards in good > > > > > > > code style, and this would clearly be an enhancement in > > > that > > > > > > > area). > > > > > > > > > > > > > > So, assuming that my proposal should be accepted: How do we > > > proceed? I > > > > > > > see two alternatives: > > > > > > > > > > > > > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope > > > > > > > "provided" to our dependencies. The scope will guarantee, that > > > users > > > > > > > aren't affected at all. > > > > > > > b) We create our own annotations, say > > > > > > > org.apache.commons.lang3.annotations.NonNull, etc. When using > > > > > > > Spotbugs, or the respective IDE's, we need to adjust the > > > > > > > namespace, > > > > > > > but that should be doable. > > > > > > > > > > > > > > Personally, I'm in favour of using the javax.annotation namespace, > > > thus a). > > > > > > > > > > > > > > From my experiences, I conclude that we should also do the > > > following: > > > > > > > > > > > > > > - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to > > > have > > > > > > > a @NonNull result, > > > > > > > because in practice, they are going to be used frequently. (In > > > > > > > cases, where the compiler > > > > > > > doesn't understand, that a value is, in fact, not nullable.) > > > > > > > - Convince the maintainers of the maven-compiler-plugin, that use > > > of > > > > > > > those annotations > > > > > > > is something, that should be documented in the plugin > > > configuration. > > > > > > > If that is given, > > > > > > > then IDE's might configure themselves automatically without the > > > need > > > > > > > for IDE specific > > > > > > > files. > > > > > > > > > > > > > > > > > > > > > Jochen > > > > > > > > > > > > > > > > > > > > > 1.) > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Look, that's why there's rules, understand? So that you think > > > before > > > > > > > you break 'em. > > > > > > > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Tomo > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
