Extension to generate NullMarked package-info#550
Conversation
|
The "Validate External Links" failure is because this change adds a new documentation page and links to it. |
|
Also I messed up the commit history 👎🏻 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #550 +/- ##
=========================================
Coverage 91.17% 91.17%
Complexity 1223 1223
=========================================
Files 76 76
Lines 3185 3185
Branches 489 489
=========================================
Hits 2904 2904
Misses 173 173
Partials 108 108 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
edward3h
force-pushed
the
feature/nullmarked
branch
from
37049b9 to
4037b2f
Compare
| <contentType>Html</contentType> | ||
| <extensions> | ||
| <extension> | ||
| <className>gg.jte.nullmarked.NullMarkedExtension</className> |
There was a problem hiding this comment.
Should this be gg.jte.jspecify.NullMarkedExtension?
| .collect(Collectors.toList()); | ||
| } | ||
|
|
||
| private Path writePackageInfo(Path sourcesRoot, String packageName) { |
There was a problem hiding this comment.
Should we annotate packages or rather the generated classes? What if you want to progressively upgrade to nullmarked? Should we have annotations on templates similar like annotations on parameters?
There was a problem hiding this comment.
@NullMarked is applied at class, package or module level. While a template is generated into a class, in practice it behaves as a single method. Therefore, a package is the right level. (Since we aren't supporting modules.)
So the question is, do we want a way to include or exclude by package?
If you want more progressive, add @NonNull or @Nullable to individual params.
2 participants
To help with JSpecify support, #528
Adds a new extension, jte-nullmarked. When enabled, it will generate a
package-info.javain each package of generated template code, with the@NullMarkedannotation.