|
|
| Re: headless Xtend2 code generation with Ant [message #783766 is a reply to message #783453] |
Thu, 26 January 2012 12:17   |
|
Hi,
On 25.01.12 19:42 , Christian Dietrich wrote:
> Hi,
>
> i got it running without having a own AntTask
>
> <java classpathref="cp"
> classname="org.eclipse.xtext.xtend2.compiler.batch.Main"
> fork="false"
> >
> <arg value="-d"/>
> <arg value="xtend-bin"/>
> <arg value="src-xtend"/>
> </java>
I found that standalone launcher, too, being playing around a bit.
The interessting part is how to determine "cp" :-)).
Does it (almost) work out-of-the-box if the build file is
processed by the Eclipse antRunner application??
>
> ~Christian
Christian
|
|
|
|
| Re: headless Xtend2 code generation with Ant [message #790125 is a reply to message #783775] |
Fri, 03 February 2012 21:19 |
|
On 26.01.12 13:40, Christian Dietrich wrote:
> Hi, no I had to figure out my class path myself
Hi again,
I managed to establish the generic headless java code generation
within our continuous integration by deploying your template.
Curiously, it works for all but one bundle for a reason I absolutely don't get!
With this bundle it always fails with the following output:
[java] [java] Exception in thread "main" java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.batch.Main.compile([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;Lorg/eclipse/jdt/core/compiler/CompilationProgress;)Z
[java] [java] at org.eclipse.jdt.core.compiler.batch.BatchCompiler.compile(BatchCompiler.java:80)
[java] [java] at org.eclipse.jdt.core.compiler.batch.BatchCompiler.compile(BatchCompiler.java:52)
[java] [java] at org.eclipse.xtext.xtend2.compiler.batch.Xtend2BatchCompiler.preCompileStubs(Xtend2BatchCompiler.java:302)
[java] [java] at org.eclipse.xtext.xtend2.compiler.batch.Xtend2BatchCompiler.compile(Xtend2BatchCompiler.java:220)
[java] [java] at org.eclipse.xtext.xtend2.compiler.batch.Main.main(Main.java:46)
[java] [java] Java Result: 1
Since org.eclipse.jdt.internal.compiler.batch.Main and org.eclipse.jdt.core.compiler.batch.BatchCompiler are
situated in the same bundle I have no clue about it.
Tried to overcome with some memory tuning without any success.
Do you guys have any idea?
Christian
|
|
|
|
| Re: headless Xtend2 code generation with Ant [message #792026 is a reply to message #791651] |
Mon, 06 February 2012 14:23 |
|
Hi Andy,
you should provide both the src and the src-gen folder to the code generator, like this:
<java classname="org.eclipse.xtext.xtend2.compiler.batch.Main classpathref="cp" >
<arg line="-d xtend-gen src:src-gen"/>
</java>
(using line is just similar to various 'value' args).
Your classpath config has to provide both the whole xtend-runtime as well as classes
used in your transformation if they aren't declared in src or src-gen.
My path definition looks like
<path id="cp">
<fileset dir="${eclipseLocation}/plugins/">
<patternset>
<include name="*antlr*.jar"/>
<include name="*/*antlr*.jar"/>
<include name="*guava*.jar"/>
<include name="*inject*.jar"/>
<include name="*icu*.jar"/>
<include name="*common*.jar"/>
<include name="*log4j*.jar"/>
<include name="*emf*.jar"/>
<include name="*jdt.co*.jar"/>
<include name="*xtext*.jar"/>
<include name="*xbase*.jar"/>
<include name="*xtend2*.jar"/>
<exclude name="*ui*.jar" />
<exclude name="*source*.jar" />
</patternset>
</fileset>
<path refid="xtend2codegen.classpath" />
</path>
whereas xtend2codegen.classpath is the path definition determined by the pde tools in
the generated plugin specific build.xml files (a copy of @dot).
Good luck,
Christian
On 6.02.12 5:51 , Andy.ca.ma ma wrote:
> I also had a problem with using standalone xtend compiler with ant
> build, I used it like:
>
> <target name="xtend-gen" description="Generate xtend file to java files">
> <path id="cp">
> <pathelement location="src"/>
> <pathelement location="src-gen"/>
> <path refid="lib.path.id"></path>
> </path>
>
> <java classname="org.eclipse.xtext.xtend2.compiler.batch.Main"
> classpathref="cp" >
> <arg value="-d"/>
> <arg value="xtend-gen"/>
> <arg value="src"/>
> </java>
> </target>
>
> But I always get errors like:
> 21156 [main] INFO text.xtend2.resource.Xtend2Resource - Types can't be
> null or empty []
> java.lang.IllegalArgumentException: Types can't be null or empty []
> at
> org.eclipse.xtext.common.types.util.TypeConformanceComputer.getCommonSuperType(TypeConformanceComputer.java:190)
>
> at
> org.eclipse.xtext.xtend2.resource.Xtend2Resource.commonType(Xtend2Resource.java:191)
>
> at
> org.eclipse.xtext.xtend2.resource.Xtend2Resource.getEObject(Xtend2Resource.java:111)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:219)
>
> at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:207)
> at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:263)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1483)
>
> at
> org.eclipse.xtext.common.types.impl.JvmFormalParameterImpl.getParameterType(JvmFormalParameterImpl.java:154)
>
> at
> org.eclipse.xtext.common.types.impl.JvmFormalParameterImpl.eGet(JvmFormalParameterImpl.java:269)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
>
> at
> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:409)
>
> at
> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.next(EContentsEList.java:559)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:179)
>
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143)
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:184)
>
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143)
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:184)
>
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143)
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:126)
> at
> org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:108)
>
> at
> org.eclipse.xtext.xtend2.compiler.batch.Xtend2BatchCompiler.validate(Xtend2BatchCompiler.java:303)
>
> at
> org.eclipse.xtext.xtend2.compiler.batch.Xtend2BatchCompiler.compile(Xtend2BatchCompiler.java:215)
>
> at org.eclipse.xtext.xtend2.compiler.batch.Main.main(Main.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> at
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.Main.runBuild(Main.java:801)
> at org.apache.tools.ant.Main.startAnt(Main.java:218)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
>
> It seems a little different error, I also hope any people can give me
> some help.
>
|
|
|
| Re: headless Xtend2 code generation with Ant [message #792243 is a reply to message #790125] |
Mon, 06 February 2012 19:50 |
|
My patience has been rewarded :-)
I integrated the codegen into our headless pde tools based build process
and re-used the generated classpath for compiling the sources.
No idea why - pde adds the org.apache.jasper bundle to the classpath.
This bundle contains org.eclipse.jdt.internal.compiler.batch.Main as well - sucker!!
Excluding this bundle from the classpath leads to success!
Christian
On 3.02.12 22:19 , Christian Schneider wrote:
> On 26.01.12 13:40, Christian Dietrich wrote:
>> Hi, no I had to figure out my class path myself
>
> Hi again,
>
> I managed to establish the generic headless java code generation
> within our continuous integration by deploying your template.
>
> Curiously, it works for all but one bundle for a reason I absolutely don't get!
> With this bundle it always fails with the following output:
>
> [java] [java] Exception in thread "main" java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.batch.Main.compile([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;Lorg/eclipse/jdt/core/compiler/CompilationProgress;)Z
> [java] [java] at org.eclipse.jdt.core.compiler.batch.BatchCompiler.compile(BatchCompiler.java:80)
> [java] [java] at org.eclipse.jdt.core.compiler.batch.BatchCompiler.compile(BatchCompiler.java:52)
> [java] [java] at org.eclipse.xtext.xtend2.compiler.batch.Xtend2BatchCompiler.preCompileStubs(Xtend2BatchCompiler.java:302)
> [java] [java] at org.eclipse.xtext.xtend2.compiler.batch.Xtend2BatchCompiler.compile(Xtend2BatchCompiler.java:220)
> [java] [java] at org.eclipse.xtext.xtend2.compiler.batch.Main.main(Main.java:46)
> [java] [java] Java Result: 1
>
> Since org.eclipse.jdt.internal.compiler.batch.Main and org.eclipse.jdt.core.compiler.batch.BatchCompiler are
> situated in the same bundle I have no clue about it.
>
> Tried to overcome with some memory tuning without any success.
>
> Do you guys have any idea?
>
> Christian
|
|
|
Powered by
FUDForum. Page generated in 0.03059 seconds
] 
Search
Help
Register
Login
Home
