Strange type mismatch error when using standalone compiler

[c.j.h...@gmail.com]

Hi,

we use buckminster and ant to headlessly build multiple eclipse projects which depend on each other. Some of thoses projects use xtend and xtext. To generate java source files from .xtend files we call the standalone xtend compiler from ant (we tried the ant task and directly calling org.eclipse.xtend.core.compiler.batch.Main). Up until recently this setup worked very well.

When I added some new projects, which build fine within eclipse, I started to get strange type mismatch errors during the headless build:

[ant] 0 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 1742: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 16   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 1516: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 16 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 1516: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 21   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 544: Type mismatch: cannot convert implicit first argument from ComponentDescription to ComponentDescription
[ant] 21 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 544: Type mismatch: cannot convert implicit first argument from ComponentDescription to ComponentDescription
[ant] 37   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 1353: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 37 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 1353: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 40   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 685: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 40 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 685: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 43   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 695: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 43 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 695: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 45   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 705: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 45 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 705: Type mismatch: cannot convert from InterfaceRoleInfo to InterfaceRoleInfo
[ant] 53   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 628: Type mismatch: cannot convert implicit first argument from ComponentDescription to ComponentDescription
[ant] 53 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 628: Type mismatch: cannot convert implicit first argument from ComponentDescription to ComponentDescription
[ant] 59   ERROR XtendBatchCompiler -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 734: Type mismatch: cannot convert implicit first argument from ComponentDescription to ComponentDescription
[ant] 59 [main] ERROR org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler  -
[ant] ERROR:     GeneratorWrapper.xtend -
[ant] 734: Type mismatch: cannot convert implicit first argument from ComponentDescription to ComponentDescription
[ant] 72   ERROR XtendBatchCompiler -

My first thought was that the classpath might be incorrect but since all the classes the xtend compiler complains about are defined within the src dir of the same project I do not think that the classpath is responsible for these messages.

I am kind of lost on this one since it builds fine in eclipse. Is there a difference between the standalone xtend compiler and the one used in eclipse? Am I missing something?

The xtend call in my ant script looks like this:

[...]
<target name="xtendGen" description="run xtend compiler">
    <pathconvert pathsep="${path.separator}"
                 property="classpath-string"
                 refid="buildClasspath"
        ></pathconvert>
    <java classpathref="buildClasspath"
          classname="org.eclipse.xtend.core.compiler.batch.Main"
          fork="true"
          failonerror="yes">
        <arg value="-cp" />
        <arg value="${classpath-string}" />
        <arg value="-d" />
        <arg value="${basedir}/xtend-gen" />
        <arg value="${basedir}/src-gen${path.separator}${basedir}/src" />
    </java>
</target>
[...]

 

Thanks
Chris

[c.j.h...@gmail.com]

Sorry for double post. For some reason my first post was not shown to me until I had posted the second one...

[Lorenzo Bettini]

On 19/01/2015 16:41, c.j.h...@gmail.com
wrote:

> Hi,
>
> we use buckminster and ant to headlessly build multiple eclipse projects
> which depend on each other. Some of thoses projects use xtend and xtext.
> To generate java source files from .xtend files we call the standalone
> xtend compiler from ant (we tried the ant task and directly calling
> org.eclipse.xtend.core.compiler.batch.Main). Up until recently this
> setup worked very well.

Hi

have you tried the approach described here?

http://www.lorenzobettini.it/2013/09/using-the-xtend-compiler-in-buckminster-builds/

this uses a .launch configuration and it automatically reuses the
classpath of the project

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

[Stefan Oehme]

The "chicken and egg" problem you talk about in the article is solved by the xtend compiler itself. It creates stubs for the Java files and compiles against those. Could you please remove that paragraph, because it could give people the impression that Xtend is unsophisticated.

I guess the real problem is that the classpath you pass only contains the first level dedependencies, but no transitive ones. Hence the errors in the Xtend build log. As a result, Xtend cannot compile properly.

[Stefan Oehme]

To the original poster: What version of Xtend are you using?

[oe...@itemis.de]

Also, please make sure that the classpath-string does not contain the classes folder of the current project. That can lead to these kind of duplicate errors.

[c.j.h...@gmail.com]

Hi,

we tried the launch file approach when we did the initial setup, but choose not to use it for two reasons:
1. We did not find enough documentation/specification about launch files. To always depend on eclipse did not feel comfortable.
2. For some projects we build we can not control the dependencies.
I did not find the time to retry it with the current problem, yet. But I will try to make room for it next week.

Our temporary solution is to checkin the xtend-gen dir for the one project that does not build headlessly otherwise.

Currently we are using xtend 2.6.2. The jar file is: org.eclipse.xtend.standalone_2.6.2.v201407030533.jar

Side note about chicken-egg problem:
Our build scripts also include intermediate build steps with --continueonerror since we had the same problems described in Lorenzos blog post.
If the xtend compile step is supposed to work without that we are probably missing somethin on the buildpath. If I rememeber correctly adding all src dirs of projects in the dependency list was not sufficient. Instead I have the feeling, that xtend is only reading .class files and ignores the .java files. But I have to rety that to be sure.

#Off topic:
Imho one should not have to rely on launch files to be able to pass the projects classpaths/buildpaths to the xtend compiler, but instead buckminster should pass those paths in a usable format to ant.

[oe...@itemis.de]

Am Mittwoch, 11. Februar 2015 10:57:57 UTC+1 schrieb c.j.h...@gmail.com:

If I rememeber correctly adding all src dirs of projects in the dependency list was not sufficient. Instead I have the feeling, that xtend is only reading .class files and ignores the .java files. 

I'm afraid there is some misunderstanding:

- The currently compiled project sources go on the source path. Xtend will read both .java and .xtend

- All dependencies go on the classpath as .jar or classes-folders. No source folders here!

[c.j.h...@gmail.com]

First of all: Thanks for your help!

You were right. We had the bin directory of the current project on the class path. Removing it fixed the issue.

Just to clarify this (and document it):

Is the following approach correct?

Assuming I have project C which depends on project A and B. There are no other dependencies and Projects A, B and C. All have java and xtend source files.

1. I run the xtend compiler for project A with the src dir of project A on the source path.
2. I build project A. (or the whole workspace with -contiuneonerrors since buckminster does not easily let us to build one specific project.)
3. I run the xtend compiler for project B with the src dir of project B on the source path.
4. I build project B.
5. I run the xtend compiler for project C with the src dir of project C on the source path and the bin dir of projects A and B on the classpath.
6. I build project C.

[Lorenzo Bettini]

On 11/02/2015 09:59, Stefan Oehme wrote:
> The "chicken and egg" problem you talk about in the article is solved
> by the xtend compiler itself. It creates stubs for the Java files and
> compiles against those. Could you please remove that paragraph,
> because it could give people the impression that Xtend is
> unsophisticated.
>

Hi Stefan

I admit that article is old; do you mean that now the xtend compiler,
even when launched from mwe2, can deal with that chicken and egg
problem? At that time it didn't work, but I seem to remember it was
already working when run from maven, so I thought it was a problem
related to the use of mwe2.

I'll try to reproduce/update that example in the next few days.

> I guess the real problem is that the classpath you pass only contains
> the first level dedependencies, but no transitive ones. Hence the
> errors in the Xtend build log. As a result, Xtend cannot compile
> properly.

I guess this is for the original poster :)

[Stefan Oehme]

Hi Lorenzo,

the Xtend compiler has always solved this problem. You should not need to build a project twice.

The second paragraph was my theory for why you get errors like "org.eclipse.jdt.Something not found".

Best Regards,

Stefan

--
You received this message because you are subscribed to a topic in the Google Groups "Xtend Programming Language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xtend-lang/wmrjcf_2BWY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xtend-lang+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorenzo Bettini]

On 12/02/2015 13:56, Stefan Oehme wrote:
> Hi Lorenzo,
>
> the Xtend compiler has always solved this problem. You should not need
> to build a project twice.
>
> The second paragraph was my theory for why you get errors like
> "org.eclipse.jdt.Something not found".
>

Hi

If I remember correctly the errors were not due to missing dependencies
on org.eclipse.jdt stuff, but due to Java classes not found on the very
same project... however, as I said, that was an old experiment, I'll try
to reproduce it nowadays.

[Lorenzo Bettini]

On 12/02/2015 13:56, Stefan Oehme wrote:

> Hi Lorenzo,
>
> the Xtend compiler has always solved this problem. You should not need
> to build a project twice.
>
> The second paragraph was my theory for why you get errors like
> "org.eclipse.jdt.Something not found".
>

Hi

some updates:

the initial build is definitely not necessary, as you said. My mistake
was due to the fact that I was only specifying src as source folder:
adding src-gen allows the xtend compiler to find all the needed Java
sources to compile everything (see
https://github.com/LorenzoBettini/Xtext-Xtend-Buckminster-Example/commit/e8ed65aebc8f76d4a957dce42bdd9d4608809979
)

so there's definitely no "chicken-and-egg" problem, I'll update the blog
post (sorry about my initial misunderstanding, but it was not clear to
me that Java sources were enough for the Xtend compiler to work; I got
it now from one of your answers).

I kept all the other intermediate build commands, since when you build
the next projects that depend on the first one, then you need the class
files... of course one could specify in the launch configuration the
source folders of all the projects the current project depends upon, but
I find it less practical to maintain.

[Stefan Oehme]

Sounds good and thanks for the update =)

I guess we have to market some features more aggressively ;)

[Lorenzo Bettini]

On 18/02/2015 09:39, Stefan Oehme wrote:
> Sounds good and thanks for the update =)
>
> I guess we have to market some features more aggressively ;)
>

Indeed! ;)