| Age | Commit message (Collapse) | Author |
|---|
|
|
|
shadowloader classpath, but only if you have lombok.jar in there. This solves exotic problems if you try to add some features to lombok in a separate jar, and addresses issue #1523
|
|
The bugfix was originally created by mateusz-matela
|
|
|
|
This reverts commit c489b49c3684e0d8cc52c5180207375d1313dbc5.
|
|
This reverts commit 43d91281d0a298df72b38c43d87769c3a33e950b.
|
|
|
|
|
|
Patch for renaming fields with Getter/Setter/Data in eclipse #210
|
|
ecj (google's dagger project has this, don't know of any others), when run inside eclipse, bombs with a LinkageError. Fixed.
|
|
|
|
|
|
purposes. This has no effect on lombok running normally.
|
|
then eclipse would hang.
|
|
|
|
integration with patcher.
|
|
-target 1.4 style class files (such as eclipse indigo). It’s a doozy.
|
|
shadowloader treatment. This commit makes it happen.
|
|
Right now the rules are:
* _IF_ a class is being loaded, sourced by a lombok-jar originating class, we FIRST search the lombok jar, and if we can’t find it, farm out the job to the originating equinox-side loader.
* _IF_ the equinox-side loader attempts to load a class, and it does NOT start with lombok, we don’t interfere and would never serve up any content from the lombok-jar (so if we have deps, they do NOT get loaded, by design). If it DOES start with lombok, we load it, and the loading class is SCL, not the equinox-side loader.
* getResource() to load classes did not work (because internally classes end in .SCL.lombok and not .class). This breaks a bunch of things. Fixed by having getResource() be aware that it should try rewriting any request for a .class to .SCL.lombok.
* launchified annotationprocessor, and cleaned up the launchified agent, which now, like all other launchers, just sets up classloader stuff and then calls into the lombok loader side to finish the actual processing, instead of trying to do it itself in a handicapped environment that can’t load much.
|
|
have to solve the problem with adding our shadow loader to the equinox infrastructure (solved in lombok currently by adding all of lombok to the bootclasspath), and all the public API still has to be kept as actual class files by build.xml. Currently it is all shadowed away.
|
|
being broken.
|
|
transplanted. It shouldn't matter (runPostCompiler will call lombok.jar code, so if there is a classloader issue, transplanting won't help), and roel thinks it might help debug an issue with Springsource gradle plugin for eclipse.
|
|
|
|
IllegalArgumentExceptions in certain cases, but with no message, thus making it very hard to figure out what went wrong. The patch throws the same exceptions in the same cases, but gives the exception a useful error message.
|
|
the portal itself has lost it's function (Eclipse help is
currently failing, but this also seems to be caused by val).
Major point though is that the Extention methods functionality
works both in javac as in Eclipse.
|
|
|
|
commits ago).
isGenerated was being transplanted twice, resulting in a ClassFormatError.
NB: This is my fault - transplanting was the only fix I introduced on top of Philipp's work.
|
|
|
|
Issue 316 rename with multiple types II
|
|
2) Annotations are now handled, but @SuppressWarnings is skipped
|
|
(just like "SimpleName"'s)
This fixes "Rename" when inner types are used (for both the main type and the inner type)
|
|
eclipse releases and ways to boot up eclipse. Now it does. Also added an item for this in the changelog.
|
|
patching. This can be used to check that lombok is managing to successfully inject code into the eclipse VM instance.
|
|
|
|
|
|
|
|
patchExtractInterface method
|
|
with @Data)
comments for generated methods are now skipped
|
|
For all methods even generated by lombok;
comments for generated methods are placed above the "managing" annotations
@Override for generated methods are skipped (since there is no valid position for this annotation)
|
|
|
|
|
|
(ClassNotFoundError).
|
|
For all methods even generated by lombok;
comments for generated methods are placed above the "managing" annotations
@Override for generated methods are skipped (since there is no valid position for this annotation)
|
|
annotation
|
|
generatedBy's. convertToFieldDeclaration now als marks the resulting FieldDeclaration as isGenerated
|
|
jvanderhel-Highlighting
Conflicts:
src/eclipseAgent/lombok/eclipse/agent/PatchFixes.java
|
|
jvanderhel-Issue_81
Conflicts:
src/eclipseAgent/lombok/eclipse/agent/PatchFixes.java
|
|
2) Put the method declaration in the interface instead of the annotation
|
|
|
|
|
