WIP doc: Differences between JavaParser and Spoon

[pvojtechovsky]

Here is first raw draft of page which lists differences between Spoon and JavaParser.

1. @monperrus, ... AND @ftomassetti, ... do you agree to have such (after content is agreed by both sides) documentation page as part of Spoon web?

2. if both sides agree, then please contribute your content and fixes of my bad English ;-)

Note: @monperrus I am not sure how to link new docu to spoon web menus.

The intention is that both sides can later contribute content here so it is as more fair then #1303.

WDYT?

[ftomassetti]

Where is the page?
Ok, I now noticed this is a PR

Well, I do not feel you need our authorization to write on the Spoon's website :)

However, as I wrote in the other documentation, I think it is hard to have something that is totally unbiased and "approved" by both sides. For sure anyone can feel free to write their own vision on the comparison.

[pvojtechovsky]

Well, I do not feel you need our authorization to write on the Spoon's website

sure ;-) It is reaction on your

Well, I am a JavaParser contributor and it seems to me that some statements about JavaParser are wrong.

So you are welcome here to write your vision or at least link to your visions in JavaParser documentation, so it is no more our fail that information provided about JavaParser are wrong.

[ftomassetti]

Good point. I will review it and give you feedback based on my opinion. Thank you for this opportunity

…

On Sun, 4 Nov 2018 at 12:09, Pavel Vojtechovsky ***@***.***> wrote: Well, I do not feel you need our authorization to write on the Spoon's website sure ;-) It is reaction on your Well, I am a JavaParser contributor and it seems to me that some statements about JavaParser are wrong. So you are welcome here to write your vision or at least link to your visions in JavaParser documentation, so it is no more our fail that information provided about JavaParser are wrong. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2744 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAazJq09v3LVD5HHUOwHdyPW7yyTxfVBks5ursrXgaJpZM4YNPfv> .

-- Website at https://tomassetti.me GitHub https://github.com/ftomassetti

[monperrus]

@monperrus, ... AND @ftomassetti, ... do you agree to have such (after content is agreed by both sides) documentation page as part of Spoon web?

Yes, definitely. Thanks for this great initiative, full of respect and constructive discussions.

[ftomassetti]

Do you support lexical preservation? I mean, can someone parse some code, modify it using the library, and printing it back with the original formatting?

[pvojtechovsky]

Yes, we call it Sniper printer. It is brand new feature, which is not well tested, but we already used it several times successfully.
There is one remaining problem, which I am actually working on: preserving compilation unit imports.

[pvojtechovsky]

@ftomassetti if I did it in the way which is incorrect, then it was not intentional. Let me know with another comment or PR on this PR.

[ftomassetti]

Hi, I wanted just to let you know that in the end we finally published the article on Spoon. You can find it here: How and Why to Analyze, Generate and Transform Java Code Using Spoon

[monperrus]

Awesome, thanks Federico!

do we have the right to respond :-)?

[ftomassetti]

Sure, please feel free to write me an email at any time to correct/update things or just add your view

[ftomassetti]

I shared with you here precisely for that.
I am sorry it took me so long to write this article but it was not easy for me to learn how to use Spoon and it was a bit of a busy period. I am glad I managed to finish the article and I hope it helps showing the potential of your framework

[monperrus]

Cool!

About the technical content:

• Generating code: using patterns may be more elegant (but more complicated)
• "type casts on snippet expressions seemed not to work": I'm not sure to understand, could you open an issue explaining the problem?

About the philosophy (this is where your post hurt a little bit, but no bad feelings, don't worry :-):

• License: you're right Cecill-C is painful, and we plan to change it see License: change license to double-license Cecill-C/MIT #2898
• Dependency: the dependency to an artifact not in Maven Central is fixed since 7.2.0 (and it was a mistake, fully agree with that)
• Collaboration: we are open to collaborating, but I'd say our two communities haven't found the right opportunity / structure to do so (so far! :-)
• Mindset: we aim to be as open-minded as you are and to listen to our users as you do :-). Apologies if you felt a "we're right" attitude, that was not intended.

(+typo "hilosophy" -> "philosophy")

[ftomassetti]

I realized I did not re-read properly the final part of the article and some notes ended up sounding much harsher than I originally intended. Sorry abou that.

I also realize that sometimes I could have not used the best approach because of my ignorance (i.e., the lack of usage of patterns"

[ftomassetti]

Thank you about the typo, I fixed it

[ftomassetti]

BTW, the article got some visits as it was reposted by the Java account on twitter. Hope eventually it leads to more users

[monperrus]

Really cool! In your post, could you remove the last paragraph of 'Philosophy' about dependencies, which is incorrect (the problem was a mistake for a specific version, it's fixed). Thanks!

…

--Martin

[ftomassetti]

@monperrus I added a note at the end of the article to explain you fixed that and you are discussing changing the license

[monperrus]

Thanks. Simply removing the paragraph would be less misleading for the reader. By reading this section, it sounds like the dependency problem has always been there and is still there, which is incorrect.

[monperrus]

I would propose to close this PR then.