| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
We've split up the build dirs for various phases of the lombok compile process,
and evidently `javadoc` doesn't work unless it can find all types involved on the classpath,
even for types that only show up internally. I was thinking javadoc should just look at
(protected/public) signatures, not internals, but, alas.
|
|
I've no idea if this produces a working intellij project, but at least it doesn't fail during the build.
|
|
vulnerable, just ensuring your vulnerability scanners dont give off false positives.
|
|
|
|
dependency on log4j, solely for testing purposes, and no user input is ever logged with it. Nevertheless, pushing the dep to 2.17 to avoid false positives from vulnerability scanners ruining the day.
|
|
dependency on log4j, solely for testing purposes, and no user input is ever logged with it. Nevertheless, pushing the dep to 2.16 to avoid false positives from vulnerability scanners ruining the day.
|
|
from dep scanners - lombok is not affected by CVE-2021-44228.
|
|
|
|
|
|
in it!
|
|
the support for records
|
|
|
|
The ant task we use for streaming test reporting in the ant script needs deps we don't wanna include in eclipse, so I moved it to a src dir that we don't include in eclipse by default.
|
|
|
|
|
|
the new formatter is nice, but needed to be compile with 1.6, otherwise running junit on older VMs doesn't work.
|
|
|
|
|
|
On windows, Eclipse keeps annotation processors open, which means putting spiProcessor in 'build' is annoying, as you can't delete open files on windows. Fixed by moving it to dist
|
|
--add-opens lines anymore.
|
|
|
|
|
|
|
|
As I don't use intellij, no idea if it works. Feedback welcome!
|
|
|
|
We used to use the mango SPI processor, but this had two major issues:
* ecj wouldn't run annotation processors, requiring a separate proc:only compile run with javac
* mangoSPI couldn't do incremental compilation, so this required a full rebuild just to generate SPI files, every time.
Addressed by updating to IPP40 which does support explicit annotation processors even for ecj, and
adding our own SPI generating annotation processor to the build which can deal with incrementals.
There are some limits; removing a `@Provides` annotation on an existing type will need a full clean to pick that up, for example.
These limits seem quite exotic, though.
|
|
The `test.javac6` job causes a ton of errors because many tests use java8+ features. Marking them off as java8+ targeted only.
|
|
|
|
add/addAll do not work in j6.
|
|
|
|
hurt.
|
|
Tiered compilation used to dump every stage into the same build dir, and included that dir on the classpath,
which means any ordering issues introduced into a build aren't going to result in a failed build,
thus breaking the build for everybody except those who already had a working lombok in their
build dir before starting a build. The opposite of bootstrapping, in other words.
Fixed by having each stage build into its own private stage phase.
|
|
autocleaning means that the build system detects that the usual incremental mode,
where the build artefacts are not deleted and instead used to skip steps already performed,
is not an option due to changes in the build script itself or a change in deps not detectable.
It works by having a version number which can be incremented, and a system that checks
for mismatches and forces a clean.
|
|
|
|
|
|
java8 class files.
|
|
|
|
patching
|
|
This makes lombok better at handling e.g. javac15.
|
|
|
|
|
|
javac8 has a bizarre dependency situation: we need the stubs in src/stubs there to compile, but if they are there
at runtime during a test run of javac8, they take precedence over the JDK's javac (because we include this
as a separate cp entry, and thus it is not a bootclasspath item), and messes everything up.
The fix is to tell eclipse to compile various src/X folders to different 'bin' targets, which required
an update to ivyplusplus as well.
also it was just broken in general, fixed that too :)
|
|
We now test generating a level2-DOM from our level1-AST (eclipse has 3 levels of ASTs, more or less), only if
that is possible, i.e. only if the full eclipse is available. This requires using a test target named `eclipse-X`, and not
one of the `ecjX` ones. This is the change that requires the massive update to the build system. About 6 tests,
including a newly added one about @Delegate, now fail. These failures would usually not cause instant failure in
eclipse, but can cause errors during save actions and will likely mess with other things in weird ways, such as
messing up syntax highlighting.
Yes, this commit now makes a bunch of cases fail the unit tests, but that is representative of actual errors in lombok,
so I'm checking it in as is (without this commit, the problem is still there, the tests are just incapable of detecting it).
|
|
Fix tests under Windows, fix test.javac11 and test.javac14, fix issue #1745
|
|
this serves the site locally and opens your browser
|
