for c) I would rather argue, there is no need to hurry with the releases if JSR 305 still works with the bundle proposed in https://issues.apache.org/jira/browse/SLING-7135 <https://issues.apache.org/jira/browse/SLING-7135>. So we should rather include that bundle in Sling (as it is anyhow needed for Sling Models Java 9+ compatibility) and do the releases one by one without rush. Konrad
> On 3. Aug 2018, at 08:01, Carsten Ziegeler <[email protected]> wrote: > > I did a similar exercise for the Apache Felix Http bundles and although > the script did not work for me, a simple find/replace for the two > annotations did the trick. > > I think we're discussing three things here in parallel: > > a) which annotations we should use > > b) should we change existing usage > > c) how to deal with existing releases > > I have the feeling that for a) we all agree that the jetbrains > annotations are the preferred way. Therefore once the vote is over we > should go ahead adjust our parent pom, release it. > > For b), I think we should definitely change existing usage in our source > code after we did a) and replace it. Hopefully someone is able to run > the script (or comes up with a working one). > > > Finally we have different options for c). I personally think if we have > done a) and b), then simply doing a release of all modules is the way to > go. We're working on some of the affected modules anywhay, so a release > will happen soon and for the others its not that much of a big deal, > especially if we can spread the process amongst some of us. > > Carsten > > Stefan Seifert wrote >> as recently discussed in SLING-7312 and the mailing list the JSR-305 >> annotations for null-analysis (javax.annotations) we are currently using >> break our compatibility with Java 9. the problem is that JSR-305 was never >> accepted and thus it's hard and troublesome to use them in Java 9 (see [1]). >> there are several alternatives for nullable annotations with good tool >> support, but some of them (e.g. findbugs/spotbugs annotations) use a license >> not fully compatible with the apache license (discussed in [2]). >> >> the jackrabbit/oak team has decided to switch to jetbrains annotations >> [3][4][5] and developed some tooling to ease the migration. although coming >> from the manufacturer of IntelliJ there is wide tool support for them e.g. >> in FindBugs/SpotBugs, Sonar and can be configured in Eclipse as well. >> >> i've created a ticket [6] to describe the steps we need to go and which >> sling modules are affected. this ticket is about to get a consensus that the >> jetbrains annotations are the way we want to go. >> >> benefits: >> - removes a blocker from achieving Java 9 compatibility >> - same annotations as used by jackrabbit/oak >> - tooling for migration available >> - jetbrains annotations use apache 2.0 license >> - wide-spread tooling support for jetbrains annotations (which would not be >> the case if we develop our own annotations) >> >> drawbacks: >> - the jetbrains annotations include some more (mostly IntelliJ-specific) >> annotations than only the nullable annotations >> - the jetbrains annotations are no "standard annotations" >> >> >> Please vote to approve switching to Jetbrains Annotations: >> >> [ ] +1 Switch to Jetbrains Annotations >> [ ] 0 Don't care >> [ ] -1 Don't switch to Jetbrains Annotations >> >> >> stefan >> >> >> [1] https://blog.codefx.org/java/jsr-305-java-9/ >> [2] https://issues.apache.org/jira/browse/JCR-4301 >> [3] https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html >> [4] http://repo1.maven.org/maven2/org/jetbrains/annotations/16.0.2/ >> [5] https://github.com/JetBrains/java-annotations >> [6] https://issues.apache.org/jira/browse/SLING-7798 >> >> > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
