Closed lombokissues closed 3 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.
: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).
: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?
:bust_in_silhouette: reinierz :clock8: Jun 06, 2011 at 22:59 UTC
Stephan Habermann reports it works in GWT!
: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.
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
:bust_in_silhouette: reinierz :clock8: Jun 07, 2011 at 22:05 UTC
Try adding -Xbootclasspath/p:lombok-edge.jar
: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.
: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.
: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?
: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
: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.
: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! :-)
: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 :)
: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 :)
: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
: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.
: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
End of migration
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());
@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.
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(TypeBinding
resolvedType, MessageSend methodCall, BlockScope scope)
The type loaded by the declared return value of the resolveType
method 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);
D'oh, no, that was clear, I was just having a dumb moment. Yeah, that makes sense. I'm on it.
@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.
@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 :)
@rzwitserloot Thank you. I got it working. Just needs some speedup and I have to check if it breaks the eclipse support.
@rzwitserloot Is there a performance reason that transplant() is not used all the time in EclipsePatcher?
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.
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.
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:
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 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.
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.
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:
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...
[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.
@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 🥇
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
@bllngr For us it works with environment variable MAVEN_OPTS -javaagent:D:\programme\lombok.jar=TYCHO
I think the =TYCHO can be omitted.
Migrated from Google Code (issue 212)