Ignore annotations in the Java source (such as @XmlRootElement)

[ghost]

I am trying to use jSweet to translate DTOs (data transfer objects) from Java to Typescript so that I can easily serialize the same object on both ends (Java server and - currently - Typescript client).

I have a DTO tagged with javax.xml.bind.annotation.XmlRootElement annotation so that it can be serialized in JSON using Jackson. I also have some methods that do not translate (equals/hashCode for instance).

It would be nice to simply ignore things that do not translate to Typescript (such as Java annotations - although now it starts existing in the latest Typescript).

And it would be nice to add a ignore annotation on methods/fields, etc... that do not need to be translated.

What do you guys think?

[ghost]

After digging around a bit further, I stumbled upon @Erased which does exactly what I was asking as the first item (I could add it to my hashCode() equals()).

So the only problem that remains for me here is the ability to ignore the code that does not yield any generated code (such as a@XmlRootElement annotation).

[renaudpawlak]

This sounds like a legitimate request, but I am surprised because I thought that Java annotations were ignored anyways. Could you please give me some sample code of what does not transpile right, so that I know exactly what needs to be ignored (and so that I have some cases to add to the test suite...). Thanks.

[ghost]

I have created my test case here: https://gist.github.com/angexis/80cb494196bc66eb1e14 Hope this is enough... otherwise, I will commit and push my change in a branch (until it works) if you need to see the whole project. Thanks and... bravo !

[ghost]

Just a comment: the generated js is fine... it is the error (and the intermediate ts) which bug me.... The typescript compiler is working in a "best effort" mode which explains the correct final output...

[renaudpawlak]

Ok. I have added your test case and support in the transpiler. If you want to have this fix, use the 1.1.0-SNAPSHOT versions for both the transpilers and the maven plugin (the transpiler may complain about inconsistent candy versions, but it is not a problem).

You may now run into problems if you want to use collections in your objects. But don't panic, I have planed to add some basic support for core collections so that people can share basic data objects (this is one of the JSweet goals). I just need to think a little bit more about it so that it does not contaminate the JSweet approach. If you have some use cases with data objects and collections, please share them with us so that we can fully support your use cases.

Thanks!

[ghost]

Many thanks for the quick reply! However, I failed to make it work. Since I am using Gradle, I cloned and updated the gradle plugin to use 1.1.0-SNAPSHOT (a PR to come later....) and launched the jsweet task which failed (notice how it grabs a jsweet-core-strict artifact from two days ago... )

jan@jan-lx:~/code/orientbase$ ./gradlew jsweet 
:compileJava
Download http://repository.jsweet.org/artifactory/libs-snapshot-local/org/jsweet/jsweet-core-strict/1.1.0-SNAPSHOT/jsweet-core-strict-1.1.0-20160208.151859-2.jar
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jsweet
package javax.xml.bind.annotation does not exist at /home/jan/code/orientbase/src/main/java/org/orientbase/dto/YRunner.java(21)
cannot find symbol
  symbol: class XmlRootElement at /home/jan/code/orientbase/src/main/java/org/orientbase/dto/YRunner.java(29)
:jsweet FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jsweet'.
> transpilation failed with 2 error(s) and 0 warning(s)

Wondering whether this could be due to the 2-days-old core artefact, I cloned jsweet repo and built it, but it only holds the transpiler, the core lib does not seem to be on GitHub is it?

Wondering what to do from now on...

[renaudpawlak]

Ouch. Where did you get your Gradle conf from? I believe that the first thing to do is to try to remove the jsweet-core-strict and use only the org/jsweet/candies/jsweet-core-1.1.0-SNAPSHOT artifact. The strict mode prevents you from using any Java API (even from Java), which is probably not what you are trying to achieve here.

[renaudpawlak]

Note that this looks more like a conf issue than anything else. If it continues failing even without the strict mode, try to delete the org/jsweet directory in your local repo (to make sure that no older version is conflicting).

[ghost]

:+1: it works like a charm with jsweet-core ... I have guessed my configuration by browsing the maven repo by hand... I had not expected the core stuff to be in the candies area... so I could only stumble upon the -strict one... and since it kept Eclipse JDT happy, I did not anticipate an issue...

Thanks for your help!!

BTW, the collection issue is indeed going to be the next problem, so I am hoping that you will find an elegant solution!

Last question: the core & candies are not on GitHub, correct? Is that open-source at all? Best regards!

[renaudpawlak]

Of course we will find an elegant solution ;) You are right, it is quite confusing to have the core in the candies.

Candies (and core) are translated from TSD, which is Open Source. So the resulting candies are also Open Source. The translator itself is not open source for many good and less good reasons. But soon we will set up an online service so that the users will be able to generate their own candies from any d.ts files.