There is no need to rush - however if there has been no change in a module since the last release (and I think that applies for many of them), doing a release is a no brainer
Regards Carsten Konrad Windszus wrote > 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] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
