lombok should run flawlessly as agent in ecj environment. Lombok as AP in ecj is broken.

lombokissues commented 9 years ago

Migrated from Google Code (issue 212)

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz :clock8: May 29, 2011 at 04:38 UTC

public <X> X[] toArray(X[] foo) {} <-- this won't compile in ecj if lombok is on the classpath, even if there are no lombok annotations anywhere in the project.

As a fix, make lombok detect whether its on ecj or eclipse when running as an agent, so that lombok can still be used with ecj via a -javaagent VM parameter.

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz :clock8: Jun 06, 2011 at 18:14 UTC

Actions to be taken for this one:

Test in ecj

Test in GWT

Test with play-lombok plugin (https://github.com/aaronfreeman/play-lombok)

This should now work by passing -javaagent:lombok.jar=ECJ on the command line (-cp lombok.jar does nothing special anymore).

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz :clock8: Jun 06, 2011 at 20:17 UTC

Latest edge now works in ecj. Next up: Does it work in gwt and play-lombok?

https://projectlombok.org/download-edge.html

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz :clock8: Jun 06, 2011 at 22:59 UTC

Stephan Habermann reports it works in GWT!

lombokissues commented 9 years ago

:bust_in_silhouette: rgransberger@gmx.de :clock8: Jun 07, 2011 at 18:29 UTC

Doesn't work with Maven Tycho, by using it with MAVEN_OPTS=-javaagent:lombok-edge.jar=ECJ

Problem initializing lombok java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/ast/ASTNode at lombok.eclipse.TransformEclipseAST.(TransformEclipseAST.java: 63) at org.eclipse.jdt.internal.compiler.parser.Parser.endParse(Parser.java: 8380) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:938 9) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:960 5) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:956 2) at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java :8155) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Com piler.java:712) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.ja va:377) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:422)

    at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.

java:3716) at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1666) at org.eclipse.tycho.compiler.jdt.JDTCompiler.compileInProcess(JDTCompil er.java:315) at org.eclipse.tycho.compiler.jdt.JDTCompiler.compile(JDTCompiler.java:1 12) at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractC ompilerMojo.java:392) at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.execute(AbstractO sgiCompilerMojo.java:159) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default BuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu ild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 352) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.a st.ASTNode at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 36 more

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz :clock8: Jun 07, 2011 at 22:05 UTC

Try adding -Xbootclasspath/p:lombok-edge.jar

lombokissues commented 9 years ago

:bust_in_silhouette: rgransberger@gmx.de :clock8: Jun 08, 2011 at 05:54 UTC

The problem is, that the jdt.core classes and lombok are not in the same classloader. When lombok is used as agent it's loaded by the AppClassLoader, as you can see, and not by the OSGI ClassLoader. That's why it doesn't have access to the jdt.core classes.

But you gave me the right clue. It works when using -Xbootclasspath/p:lombok-edge.jar;org.eclipse.jdt.core-3.6.2.v_A76_R36x.jar

In some places lombok patches the classloader to be able to access the jdt.core classes. Is this also possible for this scenario? It would be better not to have jdt.core on the bootclasspath.

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz :clock8: Jun 13, 2011 at 20:13 UTC

Weird; lombok triggers on stuff inside that very jar so this works out fine in eclipse. Adding org.eclipse.jdt.jar to all OSGI ClassLoaders is a bit of a machine gun that might have drastic side-effects. We'd also have to detect that we're running in Tycho as doing that to eclipse definitely strikes me as a very bad idea.

Where is that org.eclipse.jdt jar coming from? Tycho, or your own eclipse install (i.e. unrelated to tycho itself)? We could at least detect that this happened and produce an error message telling you add that to the VM parameter.

lombokissues commented 9 years ago

:bust_in_silhouette: marcel.bruch :clock8: Jan 03, 2012 at 07:46 UTC

What's the current state of integration into Tycho? Does it work with 0.10.6? If so, is there an example configuration?

lombokissues commented 9 years ago

:bust_in_silhouette: matthew.painter@import.io :clock8: Dec 05, 2012 at 16:18 UTC

Hi guys,

Any news on this?

Desperate to use lombok with tycho without having to delombok!

Matt

lombokissues commented 9 years ago

:bust_in_silhouette: r.spilker :clock8: Dec 06, 2012 at 10:13 UTC

Sorry, no, we didn't have time to investigate this any further yet.

lombokissues commented 9 years ago

:bust_in_silhouette: michielwerk :clock8: Dec 05, 2013 at 14:04 UTC

Exactly one year further, is there any progress on this issue? We also like to use Lombok in our Tycho project! :-)

lombokissues commented 9 years ago

:bust_in_silhouette: matthew.painter@import.io :clock8: Dec 07, 2013 at 21:34 UTC

We got Lombok working with Tycho and maven.

Ill find out how and post back :)

lombokissues commented 9 years ago

:bust_in_silhouette: matthew.painter@import.io :clock8: Dec 09, 2013 at 12:02 UTC

To get it to work we had to set maven options like this, similar to the above - which is a hack, but it works.

export MAVEN_OPTS="$maven_opts -Djava.io.tmpdir=.maven/tmp -Xmx1g -javaagent:${this_script_dir}/../build-jars/lombok_0.11.8.jar=ECJ -Xbootclasspath/p:${this_script_dir}/../build-jars/lombok_0.11.8.jar:${this_script_dir}/../build-jars/org.eclipse.jdt.core-3.8.2.v20120814-155456.jar"

Let me know if this helps :)

lombokissues commented 9 years ago

:bust_in_silhouette: michielwerk :clock8: Dec 10, 2013 at 16:17 UTC

Hi Matthew, thanks a lot for your solution!

It is a workaround, however we prefer an official solution. We are still considering if we want this workaround in our production code.

Again, thanks a lot.

Michiel

lombokissues commented 9 years ago

:bust_in_silhouette: matthew.painter@import.io :clock8: Dec 10, 2013 at 17:30 UTC

You only need it to compile - it doesn't need to touch production.

lombokissues commented 9 years ago

:bust_in_silhouette: michielwerk :clock8: Dec 11, 2013 at 16:15 UTC

It does touch your continuous integration environment, which consists of several products. We like to keep this one 'hack' free too. However we are still considering.

Thx, M

lombokissues commented 9 years ago

End of migration

rgra commented 5 years ago

I worked on getting Tycho to compile with the lombok agent yesterday and it seems to work when not loading the classes directly but from the ClassLoaders of the objects which are passed in like this (not optimal at the moment, just a POC):

public static final class ExtensionMethod {
  public static TypeBinding resolveType(TypeBinding resolvedType, MessageSend methodCall, BlockScope scope) {
    Class<?> shadowed = Util.shadowLoadClass("lombok.eclipse.agent.PatchExtensionMethod");
    Class<TypeBinding> TypeBinding =  (Class<org.eclipse.jdt.internal.compiler.lookup.TypeBinding>) load(resolvedType.getClass().getClassLoader(),"org.eclipse.jdt.internal.compiler.lookup.TypeBinding");
    Method RESOLVE_TYPE = Util.findMethod(shadowed, "resolveType", TypeBinding,  load(methodCall.getClass().getClassLoader(),"org.eclipse.jdt.internal.compiler.ast.MessageSend"),  load(scope.getClass().getClassLoader(),"org.eclipse.jdt.internal.compiler.lookup.BlockScope"));
    return TypeBinding.cast(Util.invokeMethod(RESOLVE_TYPE, resolvedType, methodCall, scope));
  }

The other methods without return types work but this one still gives me a ClassNotFoundException because of the return type 'TypeBinding'.

Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.lookup.TypeBinding
    at java.net.URLClassLoader.findClass (URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass (Launcher.java:349)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:357)
    at lombok.launch.PatchFixesHider$ExtensionMethod.resolveType (PatchFixesHider.java:293)
    at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType (MessageSend.java:921)
    at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve (ReturnStatement.java:342)
    at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements (AbstractMethodDeclaration.java:634)
    at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements (MethodDeclaration.java:307)
    at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve (AbstractMethodDeclaration.java:544)
    at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve (TypeDeclaration.java:1218)

@rzwitserloot Any idea how to work around this? Can the wrapReturnValue be extended with a type cast?

sm.addScript(wrapReturnValue()
  .target(new MethodTarget(MESSAGE_SEND_SIG, "resolveType", TYPE_BINDING_SIG, BLOCK_SCOPE_SIG))
  .request(StackRequest.RETURN_VALUE)
  .request(StackRequest.THIS)
  .request(StackRequest.PARAM1)
  .wrapMethod(new Hook(PATCH_EXTENSIONMETHOD, "resolveType", TYPE_BINDING_SIG, TYPE_BINDING_SIG, MESSAGE_SEND_SIG, BLOCK_SCOPE_SIG))
  .build());

rzwitserloot commented 5 years ago

@rgra That doesn't appear to add up; as far as I know, j.l.Class's 'cast' method either does nothing whatsoever, or, it throws a ClassCastException, depending on whether the passed object is a subtype of the type represented by the j.l.C instance. Well, that, and it makes javac compile the code versus complaining that the types don't align, just like an actual cast-via-normal-java-syntax (TypeBinding tb = (TypeBinding) x; versus Class.forName("...").cast(x). the scripts are bytecode modifiers so that part is not relevant, which leaves just the 'does nothing or throws' part, which, therefore.. also does nothing.

I don't see how that would possibly make any difference.

I assume you were thinking of adding the reflection based cast (Class.forName(string, classloader).cast()) and not an actual syntactic typecast. We can do that. It's a significant chunk of bytecode but if it fixes the issue, I'm game!

I just don't yet see how this could possibly fix it.

Perhaps the best next step is to file a new bug issue with a self contained test case along the lines of 'download tycho from here, run this example project, watch it not work', so we have a playground to get to the bottom of this issue.

rgra commented 5 years ago

Sorry I was a bit unclear.

The code in lombok.launch.PatchFixesHider$ExtensionMethod is loaded by AppClassLoader and not by the OSGI ClassLoader.

public static TypeBinding resolveType(TypeBindingresolvedType, MessageSend methodCall, BlockScope scope) The type loaded by the declared return value of the resolveTypemethod thus is not the same as the parameter TypeBinding resolvedType which gets passed in from org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType and thus from a class loaded by the OSGI Classloader.

This is why I'm trying to get rid of the return type here public static TypeBinding resolveType and replace it with Object: public static Object resolveType

Then add this to the ASM generated code along the lines of wrapReturnValue() so that it will insert: resolvedType =resolvedType.getClass().cast(lombok.launch.PatchFixesHider$ExtensionMethod.resolveType(resolvedType,methodCall,scope)); instead of resolvedType = lombok.launch.PatchFixesHider$ExtensionMethod.resolveType(resolvedType,methodCall,scope);

rzwitserloot commented 5 years ago

D'oh, no, that was clear, I was just having a dumb moment. Yeah, that makes sense. I'm on it.

rgra commented 5 years ago

@rzwitserloot Heres a Tycho example which you can use: https://github.com/rgra/tycho-example master branch

You can import this in Eclipse and activate the target from the target plugin to make it compile in eclipse. On the command line just type mvn clean install -DskipTests in the main dir to make it build.

Go to this dir and find the product for your platform and start it: tycho-example\releng\com.vogella.tycho.product\target\products\Tycho\

Switch to the lombok branch and add -javaagent:path/to/lombok.jar to MAVEN_OPTS, rerun the build and see it fail with ClassNotFound.

rzwitserloot commented 5 years ago

@rgra okay, lombok.patcher is now at version 0.32 with support for this. I've updated the wrapreturnvalues test in lombok.patcher to show off the new cast functionality.

I've also pushed a commit on lombok itself to update to this new 0.32 version of lombok.patcher.

Let me know if there's anything more that's needed :)

rgra commented 5 years ago

@rzwitserloot Thank you. I got it working. Just needs some speedup and I have to check if it breaks the eclipse support.

rgra commented 5 years ago

@rzwitserloot Is there a performance reason that transplant() is not used all the time in EclipsePatcher?

rgra commented 5 years ago

A working version is now committed.

There are three testcase which fail for test-tycho ant build:

ExtensionMethodPlain
ValErrors
ValInBasicFor

ExtensionMethodPlain does not work in Tycho because the used jdt-ecj version is newer. The MessageSend in that jar contains an new field argumentTypes. The patched resolveType Method for PatchExtensionMethod.resolveType(TypeBinding, MessageSend, BlockScope) will overwrite the arguments array but not argumentTypes. This results in a mismatch of array length and ArrayIndexOutOfBounds. I'm not sure if there is a requirement for a specific JDT version to be used for testing or if this could be changed?

ValErrors and ValInBasicFor emit more error messages in tycho. I guess this is due to the different JDT version as well.

rgra commented 3 years ago

Hi @rzwitserloot. Are you still interested in merging this at some point? In this case I will update the patch to the new master whenever you have time to look at it.

rzwitserloot commented 3 years ago

Apologies for letting this one fall by the wayside. @rgra I've used your work in 6503177 linked above as the blueprint, but there were a bunch of things going on there that I wasn't sure about, so I solved the problem in a somewhat different way:

Instead of making a classloader that sits on top of shadowloader, I've expanded shadowloader's abilities. By asking the 'initial' loader for the raw bytes and calling defineClass ourselves, I've also removed the need to figure out if we're in tycho or not - the loader of the parser class is now always involved.
I've fully eliminated any hard-coded reference to Parser, CompilationUnitDeclaration etc in the crucial path. I believe this has eliminated the need to use MethodHandle. The problem with MH is that it's not in java 1.6, and whilst we're strongly considering dropping support for java1.6 (it's about time, I guess), it would complicate this fix.

I ran into problems with the tycho-example project; it doesn't work on java14 (still using unpack200 which is gone at this point), but it seems to do allright on java11. With the current edge release I end up at:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.2.0:compile (default-compile) on project com.vogella.logging.config: Fatal error compiling: Annotation processing got disabled, since it requires a 1.6 compliant JVM

Which is weird, because surely adoptopenjdk11 is a 1.6 compliant VM. However, this is far fewer errors than before this fix, so I'm hoping it's fixed.

Can you test the current edge for me?

NB: A lot of your commit involves adding a test for tycho to the build, which is a good idea, but I want to investigate that a little further. On my system, a simple mvn compile -DskipTests would take well over a minute and download a ton of stuff, every time I ran it (and it was.. a LOT of stuff). That kind of test needs to be squirreled away in something we rarely run, it'd slow down the feedback cycle far too much if it's part of the standard suite. I'm probably doing something wrong, though. At any rate, the test infra isn't part of this commit yet.

rgra commented 3 years ago

Hi @rzwitserloot. Thanks for picking this up again.

I tried the edge release, it doesn't work :-( Java 11 is funny. It shows the "Annotation processing" message when an "argument type mismatch" is happening when applying transform_swapped. So there's cleary an issue with class loading.

You can see the full error with mvn clean verify -Xe

I still think it is necessary to let the original class loader load the classes like I did. But your design is clearer.

If you want to attach a debugger after starting Maven: -Xms900m -ea -javaagent:D:\git\lombok-orig\dist\lombok-1.18.17.jar=TYCHO -Dlombok.debug.reflection=true -Dlombok.patcher.patchDebugDir=D:\temp\patch -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000

I was just testing MethodHandles hoping they might be faster, but didn't get to do the comparison yet.

Actually I'm not sure what I did with the tests there ;) Tycho is assembling the target platform each time you run it, so this already loads some stuff. It's possible to mirror those to make it run faster. And the test cases in the project are not need. I turned them off now. You might want to check it out again. I also updated it to use a newer Tycho version which runs a little faster.

rzwitserloot commented 3 years ago

I've done this and I have no idea what I'm doing, so I need some help:

# (in the tycho-example dir)
git pull
export JAVA_HOME=/path/to/adoptopenjdk8
export MAVEN_OPTS=-javaagent:/path/to/lombok.jar
mvn clean compile -DskipTests

and then to give it a try:

mvn -o -X -e compile -DskipTests

This causes the following nasty things to occur:

It takes 41.26s to get to an error and that's with offline mode on, and not cleaning. Ludicrous, no?
Halfway through, I get this error echoed:

java.lang.ClassCastException: org.eclipse.tycho.p2.remote.RemoteMetadataRepositoryManager cannot be cast to org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager
    at org.eclipse.equinox.internal.p2.metadata.repository.LocalMetadataRepository.setProperty(LocalMetadataRepository.java:301)
    at org.eclipse.equinox.p2.repository.spi.AbstractRepository.setProperty(AbstractRepository.java:194)
    at org.eclipse.equinox.internal.p2.updatesite.metadata.UpdateSiteMetadataRepositoryFactory.resetCache(UpdateSiteMetadataRepositoryFactory.java:84)
    at org.eclipse.equinox.internal.p2.updatesite.metadata.UpdateSiteMetadataRepositoryFactory.load(UpdateSiteMetadataRepositoryFactory.java:63)
    at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:63)
    at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:775)
     ...

Bizarrely, this does not occur if I omit -o (offline mode), but then the build is even slower and does a bunch of network fetches every time, even though I'm not cleaning. That seems broken, but some web searches seems to indicate this is normal maven behaviour?

Nevertheless, this error doesn't seem to stop the build. We then eventually get to...

It ends with this error:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.7.0:compile (default-compile) on project com.vogella.logging.config: Fatal error compiling: argument type mismatch -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.7.0:compile (default-compile) on project com.vogella.logging.config: Fatal error compiling
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling
    at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:414)
    at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.execute (AbstractOsgiCompilerMojo.java:293)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.codehaus.plexus.compiler.CompilerException: argument type mismatch

    at org.eclipse.tycho.compiler.jdt.JDTCompiler.compileInProcess (JDTCompiler.java:374)
    at org.eclipse.tycho.compiler.jdt.JDTCompiler.performCompile (JDTCompiler.java:120)
    at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:411)
    at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.execute (AbstractOsgiCompilerMojo.java:293)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)

which isn't the error I had before. Is this lombok's doing, or is something else wrong?

A way I can cycle a test in a second or two instead of 45 would help a lot.

rgra commented 3 years ago

@Rawi01 Thank you so much for making it work in the official releases. Just tested it with the newest lombok. No need for patching this part myself anymore. Yeah 🥇

bllngr commented 3 months ago

Sorry for bumping this old thread, but I couldn't find any working instructions. What is the suggested way to get Lombok working with current Tycho versions? @rgra @rzwitserloot

rgra commented 3 months ago

@bllngr For us it works with environment variable MAVEN_OPTS -javaagent:D:\programme\lombok.jar=TYCHO

I think the =TYCHO can be omitted.

projectlombok / lombok

lombok should run flawlessly as agent in ecj environment. Lombok as AP in ecj is broken. #285