Retrieve path to xtend-gen folder in the doTransform Method of an ActiveAnnotation Processor

[djgum...@gmail.com]

Hi!

I have a large class I'm running through an active annotation processor to fill the method stubs with templated code.

In addition, I would like to create an xml file containing atomic permissions entries for our authentication framework based on the method names.

In tests it works like a charm, however I still need a way to find out where to put that xml file. Is there a way to retrieve the location where xtend is putting the class it is currently transforming to?

kind regards,

Johannes

[Sven Efftinge]

You can retrieve the location of the currently process compilation unit, it’s target folder and the project’s root folder.

// Obtain the path to the currently processed file:

val sourcePath = myElement.compilationUnit.filePath

// Obtain the target folder for the currently processed file

val targetFolder = sourcePath.targetFolder

// the project root

val projectRoot = sourcePath.projectFolder

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

[djgum...@gmail.com]

Hey!
Sorry but that is not working here..
I get this error:
46: Error during annotation processing:
java.lang.IllegalStateException: Couldn't determine file path. The file ('/E:/a/b/c/d/e/src/.../ProxyConnectorDelegate.xtend') doesn't seem
 to be contained in the workspace ('/e:/a/b/c/d/')

(I changed the names).
I do recognize that it is checking for E:/ vs e:/, could this be the reason and, if so, how can I fix that?

Kind regards, Joahnnes

[Sven Efftinge]

Oh, it could be a bug on windows. Could you please submit a bugzilla, with a small example, that reproduces the issue?

We will try to fix it for 2.7.1 (to bee released soon), although our only windows user (Stefan) is on vacation currently :-(

[Sven Efftinge]

Here’s the URL for bugzilla:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Xtend&component=Core

[Sven Efftinge]

When do you get that error in the IDE, when running tests, or when executing a build?

On 04 Sep 2014, at 10:45, djgum...@gmail.com wrote:

[djgum...@gmail.com]

This occurs when invocating the build via maven.

[djgum...@gmail.com]

Just tried to create an example but that example fails to fail, i.e. it works there... What the f....

Anyways I've been looking some more at my error message... what does "workspace" at this exception even mean and how is it generated? Is it in any way related to the eclipse workspace? 

Kind regards,
Johannes

[djgum...@gmail.com]

Ok I now managed to create a working (failing) example and put it to bugzilla. 

Can you please give me feedback asap because this is effectively blocking my further development in this regard.

Kind regards,

Johannes

[Sven Efftinge]

I have fixed the problem and commented on the bugzilla [1] that you should be able to work around that issue for now.

Also please update your code, auch that you are using the code generation phase and the mutable filesystem support.

This is mandatory to ensure a proper behavior (e.g. Eclipse will recognize file changes and so on.)

Sven

[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=443319

[djgum...@gmail.com]

Hey I'm trying your workaround, however it seems that it does not work properly under maven. Well, to be precise, It seems that the doGenerate Method is not even called when running the build from maven. This is my current (experimental) doGenerate Method

    override doGenerateCode(ClassDeclaration annotatedClass, extension CodeGenerationContext ctx) {
        val sourceFile = annotatedClass.compilationUnit.filePath

        val f = new File("E:/outputtttt.txt")
        val writer = new BufferedWriter(new FileWriter(f));
        writer.write(sourceFile.toString +"\n")
        writer.write(sourceFile.sourceFolder.toString +"\n")
        writer.write(sourceFile.targetFolder.toString +"\n")
        writer.write(sourceFile.projectFolder.toString +"\n")
        writer.close

        //        val targetFile = sourceFile.projectFolder.append("target/permissions/080_Permission/Output.txt")
        val targetFile = sourceFile.projectFolder.append("/Outputttt.txt")
        targetFile.contents = '''
            Source file is «sourceFile»
            Source folder is «sourceFile.sourceFolder»
            Target folder is «sourceFile.targetFolder»
            Project folder  is «sourceFile.projectFolder»
        '''
    }

Note I'm again using the java File API to generate an absolute file as a mean of introducing a second way of writing files. However, after successful building via maven, neither file is generated. When building via Eclipse, the generation works fine.

Kind regards,
Johannes

[Sven Efftinge]

Outch. Seems like you stumbled over another bug.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=443582

Fixed it and if it doesn’t break the test suite or cause other trouble it will be part of 2.7.1 (tomorrow).

[Sven Efftinge]

Hi Johannes,

the 2.7.1 builds are now available on maven central.

Regards,

Sven

[DJ Gummikuh]

Thanks a lot, will try asap

[djgum...@gmail.com]

Ahem.. sorry to jinx that again, but with 2.7.1 I suddendly get this:
[ERROR] Failed to execute goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compil
e (default) on project yada.yada.yada.server: Execution default
of goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compile failed. ConcurrentMod
ificationException -> [Help 1]

:-( Neverending story

[Sven Efftinge]

Could you please open a bugzilla and attach the stack trace?

Also steps to reproduce would be helpful.

[Sven Efftinge]

Seems like Sebastian already found it :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=443739

[Sven Efftinge]

Could you maybe add your stack trace to this bugzilla?

Just to make sure it’s the same issue. Thanks.

[Sven Efftinge]

It seems to be a different issue, as Xtend isn’t using the code mentioned in the bugzilla.

So please, help me fix it by providing the stack trace!

[djgum...@gmail.com]

Hi!
Sorry, I got held up with other business and just today managed to get back to my original Project :-)

Took me a minute to figure out how to actually show the stack trace since maven usually only displays the message. However, mvn -X gave me the following:


[ERROR] Failed to execute goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compile (default) on project de.kisters.bundle.kidsm.kisrpc.server: Execution default of goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compile failed. ConcurrentModificationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compile (default) on project de.kisters.bundle.kidsm.kisrpc.server: Execution default of goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compile failed.
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
        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.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        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:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.eclipse.xtend:xtend-maven-plugin:2.7.1:compile failed.
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        ... 19 more
Caused by: java.util.ConcurrentModificationException
        at org.eclipse.emf.common.util.AbstractEList$EIterator.checkModCount(AbstractEList.java:758)
        at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:706)
        at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:692)
        at org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler.generateJavaFiles(XtendBatchCompiler.java:598)
        at org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler.compile(XtendBatchCompiler.java:400)
        at org.eclipse.xtend.maven.AbstractXtendCompilerMojo.compile(AbstractXtendCompilerMojo.java:133)
        at org.eclipse.xtend.maven.XtendCompile.compileSources(XtendCompile.java:67)
        at org.eclipse.xtend.maven.XtendCompile.internalExecute(XtendCompile.java:59)
        at org.eclipse.xtend.maven.AbstractXtendMojo.execute(AbstractXtendMojo.java:39)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:101)
        ... 20 more

Kind regards,
Johannes

[djgum...@gmail.com]

Just to clarify, all I'm doing is running mvn -X install now.

[Sven Efftinge]

Yes, this was fixed for 2.7.2. 

Seems like you are still using 2.7.1?

[djgum...@gmail.com]

Woops there is a 2.7.2 already ?!? How long have I been off the face of the Earth? :S Can't remember reading about that.

Will try with 2.7.2 then.

Thanks a lot :)

[djgum...@gmail.com]

Ok, 2.7.2 does no longer raise this exception. Thank you for pointing out I'm dumb ;)

Kind regards,
Johannes

[djgum...@gmail.com]

Ok now I have for the first time an issue that actually is not caused by a bug but me not really understanding xtend good enough.
you gave me an example that wrote a file in doGenerateCode instead of doTransform.
First I tried to use that example in the doTransform Method of mine but fail to do so because I do not get the setContent method for the path from the TransformationContext.
Then I tried doing everything in the doGenerateCode method, however I have the issue that I'm writing the xml permissions file while iterating through the declared methods - which I cannot access from the CodeGenerationContext extension methods...

Is there any chance I can call you by phone or skype for advice on that topic?

Kind regards,
Johannes

Am Donnerstag, 18. September 2014 09:12:42 UTC+2 schrieb Sven Efftinge:

[Sven Efftinge]

Comments inline…

Ok now I have for the first time an issue that actually is not caused by a bug but me not really understanding xtend good enough. 
you gave me an example that wrote a file in doGenerateCode instead of doTransform.
First I tried to use that example in the doTransform Method of mine but fail to do so because I do not get the setContent method for the path from the TransformationContext.

Yes, the file system is only mutable (has setContents etc.) during doGenerateCode.

You can only read during the other phases.

Then I tried doing everything in the doGenerateCode method, however I have the issue that I'm writing the xml permissions file while iterating through the declared methods - which I cannot access from the CodeGenerationContext extension methods…

Why not? the following should work:

override doGenerateCode(ClassDeclaration annotatedClass, extension CodeGenerationContext context) {

for (member : annotatedClass.declaredMembers) {

}

}

Note that during doGenerateCode you get passed in the original unmodified source elements and there is currently no way to get access to the mutated Java elements. I think that is false and should be changed to be the same as in ValidationParticipant, i.e. you get an unmodifiable view of the Java elements and can navigate to the original Xtend elements if necessary.

So if the information you want to generate into the XML is not directly present in the source tree, You’ll have to do some computation twice for now.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=444437

Is there any chance I can call you by phone or skype for advice on that topic?

Why not using this group? Others could benefit from our exchange as well.

Sven

[djgum...@gmail.com]

Hi!
Just to inform you that I did what you told me, the compilation errors were because as said I had the entire code generation method copied over to doGenerateCode and since the context is not mutable this caused all kinds of compilation errors. Now I'm computing twice like you suggested and it seems that now my generation does everything I want from it.

I thank you a lot for helping me through this, I was just about to throw it all away because I started having a feeling that this would never fly :-)

[Sven Efftinge]

You are welcome!

Also note that we provide “professional" help, i.e. give trainings or help onsite with more involving tasks. 

Just ping me if you are interested. :-)