glad to hear about this. this is what I always want... I wished for this for months...
Gary Gregory <garydgreg...@gmail.com> 于2021年2月16日周二 上午9:37写道： > Yes of course, that's fine, but I was only referring to [lang], which is > the component this thread is about. > > Gary > > On Mon, Feb 15, 2021, 19:03 sebb <seb...@gmail.com> wrote: > > > On Mon, 15 Feb 2021 at 18:43, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > > > Can we configure the Maven Enforcer plugin to say "no runtime deps"? > > > Presumably not that helpful... but still _something_ > > > > Some components legitimately depend on others at runtime. > > e.g. VFS on NET. > > > > > 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 > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
