Can we configure the Maven Enforcer plugin to say "no runtime deps"? Presumably not that helpful... but still _something_
Gary On Mon, Feb 15, 2021 at 11:48 AM Thomas Schapitz <t...@online.de> wrote: > ... right into https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem. > I thought more about something like a guide to be consulted before > introducing a new dependency, instead of a dashboard disclosing the sins > post fact :-) > > I take that as a no. > > Thomas > > > > Gesendet: Montag, 15. Februar 2021 um 16:59 Uhr > Von: "Gary Gregory" <garydgreg...@gmail.com> > An: "Commons Developers List" <dev@commons.apache.org> > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable > I do not think we need a wiki since each project should have a Maven > generated page like > https://commons.apache.org/proper/commons-lang/dependencies.html > > Gary > > > On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <t...@online.de> wrote: > > > Oh, maybe I should pull more often... > > As far as I'm concerned, by all means, remove it, although I'm probably > > the least one to call for that. > > > > And since we are at it: Are you aware of any explicit mentioning of a > > dependency policy wrt. commons? > > Maybe commons should set up some Wiki page, and start actively managing > > that? > > A convenient place to point to, when discussions about that occur? > > > > Thomas > > > > Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr > > Von: "Gary Gregory" <garydgreg...@gmail.com> > > An: "Commons Developers List" <dev@commons.apache.org> > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable > > This is already in Commons Lang master which is why I want to remove it > > until there is a long term plan we can agree on. > > > > Gary > > > > On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <t...@online.de> wrote: > > > > > > > > Short Answer: No, but Yes in the long term... > > > > > > Long Answer: > > > Originally, (as of February 1.) Jochen proposed to introduce them into > > > commons-lang, with mixed results for the answers. > > > So i think they've not yet have made it into master, or do they? > > > > > > I rummaged through central, and of the modules to be found there > beneath > > > org/apache/commons there are just two, that actually reference the > > > com.google.code.finbugs:jsr305:jar, and both are maven plugins: The > > > commons-release-plugin and the commons-weaver-maven-plugin (not yet > > > checked, whether they do transitively so). So I guess, this isn't a > > > pressing issue for commons in general or lang specifically. > > > > > > I also take it, that commons always has been cautions not to light > > > heartedly introduce dependencies, and foreign dependencies at that, > into > > > its core modules lang, collections, math etc. > > > > > > If commons made it this far without jsr305, don't start introducing > this > > > doomed package now. > > > > > > > > > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr > > > Von: "Gary Gregory" <garydgreg...@gmail.com> > > > An: "Commons Developers List" <dev@commons.apache.org> > > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable > > > So... it is my impression now that we should remove these annotations. > Is > > > that right? > > > > > > Gary > > > > > > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <t...@online.de> > wrote: > > > > > > > Not exactly, although that also seems, what the author of > > > > > https://jspecify.dev/_sources/index.rst.txt[https://jspecify.dev/_sources/index.rst.txt] > is thinking. > > > > But given, that the last attempt at this went nowhere, and has been > > > > abandoned about 10 years ago, I think it is rather unlikely, that > this > > > one > > > > would make the difference. > > > > > > > > And why should it be necessary for the user, to know the details of > the > > > > interpretation of the checking framework? > > > > Annotations are kind of interfaces, and as such may be interpreted > just > > > as > > > > any other interface as defining element of a contract, which could be > > > > detailed in Javadoc. The same way as Eclipse Link and Hibernate do > with > > > JPA > > > > annotations, while at least hibernate still also works with its own > > > > annotations. > > > > > > > > In fact, @NotNull and its compannions can all be interpreted as > > > describing > > > > a predicate applying to certain elements of the source tree. So all > > what > > > is > > > > needed, is to match the annotations with the predicates, the > framework > > > can > > > > support. The challenge is in the inference, when these predicates are > > > > applied to the source tree. > > > > > > > > This way, a checker framework may take also advantage of the > knowledge > > > > hidden in foreign annotations: JPA, Hibernate, Jackson all have > > > constructs > > > > for indicating nullability and attribute sizes, that might be of use. > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr > > > > Von: "Gary Gregory" <garydgreg...@gmail.com> > > > > An: "Commons Developers List" <dev@commons.apache.org> > > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable > > > > Isn't the root issue is that all toolchains need to agree on the new > > > > annotations? What's that going to be? > > > > > > > > On Sun, Feb 7, 2021, 17:56 si...@ochsenreither.de < > > > si...@ochsenreither.de> > > > > wrote: > > > > > > > > > > > > > > Agree on that – adding a dependency on the JSR-305 jar is a really > > > really > > > > > bad idea for all the reasons already outlined. I'll add another > one: > > > > > > > > > > At my place, we have actively been removing any usage of these > > > > annotations > > > > > as you simply can't use these annotations and the "real" > > > > javax.annotations > > > > > package (javax.annotation:javax.annotation-api) under the module > > system > > > > > (that was introduced in Java 9, for the record). > > > > > > > > > > People are already working on a replacement library (Jetbrains, > > Google, > > > > > others), but I forgot the exact URL due to a lack of interest. > > > > > (The JSR-305 approach to nullability is wrong, broken, and will > never > > > > work > > > > > reliably from my POV.) > > > > > > > > > > Cheers, > > > > > > > > > > Simon > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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 > >
