| Age | Commit message (Collapse) | Author |
|---|
|
-target 1.4 style class files (such as eclipse indigo). It’s a doozy.
|
|
|
|
|
|
stuff is now flagged as an error.
|
|
|
|
|
|
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.
|
|
|
|
|
|
projectlombok.org hosted download.
|
|
feature.
|
|
|
|
|
|
sources for this to aid in debugging.
|
|
they should now be able to handle running JDK8 etc tests.
CAREFUL: You MUST name your JDK8 'JavaSE-1.8' or it won't work.
Also added a basic test for JDK8 features.
|
|
against ecj8 to the lineup, and to force compilation with the bootstrap classpath of JDK6 so that we won't accidentally add deps on things that JVM6es don't have.
|
|
Conflicts:
build.xml
src/core/lombok/eclipse/HandlerLibrary.java
src/core/lombok/eclipse/handlers/EclipseHandlerUtil.java
src/core/lombok/javac/HandlerLibrary.java
src/core/lombok/javac/handlers/JavacHandlerUtil.java
|
|
|
|
|
|
* Conflict due to adding topic() feature to logger in master, and 'field name' feature in config branch.
* master has since updated to shiny new eclipse dep versions and the 'ant eclipseForDebugging' feature, but this branch added deps. Addressed that.
* Renamed 'loggerCategory' to 'loggerTopic'. I know, that wasn't exactly right to do in a merge, but, there you have it.
* Test infrastructure changed in configuration branch, and tests had been added in master branch.
Conflicts:
build.xml
buildScripts/ivy.xml
src/core/lombok/eclipse/handlers/HandleLog.java
src/core/lombok/extern/apachecommons/CommonsLog.java
src/core/lombok/extern/java/Log.java
src/core/lombok/extern/log4j/Log4j.java
src/core/lombok/extern/log4j/Log4j2.java
src/core/lombok/javac/handlers/HandleLog.java
test/transform/resource/after-ecj/ValInTryWithResources.java
|
|
lombok.patcher.
|
|
alternative you want in the face of multiple plugin versions.
|
|
|
|
to backslashes in paths getting eliminated when using a path in a regexp replace string.
|
|
from your eclipse so that line numbers etc line up with your eclipse.
|
|
For now, it fails.
|
|
it has major refactorings to make JDK6-8 support
possibly with much prettier code.
|
|
Conflicts:
src/core/lombok/javac/handlers/JavacHandlerUtil.java
src/utils/lombok/javac/CommentCatcher.java
src/utils/lombok/javac/Javac.java
|
|
This caused a bunch of weirdness because eclipse changes a bunch of warnings and quickfixes based on this (such as complaining about lack of @SafeVarargs, a 1.7-only feature).
|
|
where _ANY_ mention of com.sun.tools.javac.tree.TreeMaker,
anywhere in a source file, would disable pretty much every
intelligent part of what makes the 'I' in IDE in eclipse:
No auto-complete, no 'go to declaration', etcetera, but only
since Eclipse Juno (not fixed in Kepler either). It's the
presence of src/stubs/com/sun/tools/javac/util/Context.java.
I've moved Context to a special stubs directory that's only used
for javac (so that we still get the benefit of getting some
warnings and such when making command line builds), and removed
the @Override annotations for where the stubbing is relevant
(for methods that exist in javac7 but not in javac6 on interfaces
we create implementations of). Furthermore, I did some extremely
tricky work in making our version actuall compatible with the
exact class signatures of both javac6- and javac7+'s versions;
generation of synthetic methods for reified type parameters was
causing havoc.
A big stack of 'here be voodoo' comments unfortunately added to
explain it all; necessary evil.
|
|
|
|
|
|
to be organization-name.jar instead of just name.jar, in order to account for
the ever lovely and wonderful apache's crazy decision to call the entirely
separate log4j v2.0 also 'log4j'. This does mean you'll have to 'ant clean'.
|
|
|
|
Only Oracle provides builds for JDK8 atm, and there is no OpenJDK
build, so the setup is slightly different. Files have to be copied
manually from an installed JDK. For comparison purposes, an Oracle JDK7
option has been added too. This should be removed before merging to master.
|
|
eclipse launch targets IF the project has been treated as eclipse project ('.project' is present).
|
|
|
|
in our tests, the tests are in the unfortunate scenario where we always compile against a given javac (lib/build/javac6.jar), and always run the tests against a given javac, but that javac tries to use the bootclasspath of the host JRE, and if that is JRE7, you get all sorts of errors.
I fixed it by still compiling against a given javac (we can only ship one lombok.jar after all), but having the test task run with a given bootclasspath and a given javac.jar.
There are 2 tasks that download both rt.jar and javac.jar for either OpenJDK6 or OpenJDK7, and it writes a properties file with those locations. The test task will use this property file, and explain what you need to do if it is not there.
Incidentally, this brought to light issue 422: Delombok in java7 produces VerifyErrors.
|
|
|
|
|
|
|
|
|
|
running on a 1.6 VM.
The test run now has more fine-grained dependency control, in preparation for running tests against multiple different platform versions (javac1.6, old eclipse, new eclipse, etc)
|
|
|
|
|
|
|
|
|
|
|
|
|
