On Oct 26, 2010, at 7:33 PM, Johan Fabry wrote:
That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
On 26 Oct 2010, at 13:40, Nicolas Anquetil wrote:
Hi all,
We have been mentionning it in past emails on the list, but we are pleased to announce officially the first release of VerveineJ : a Java to MSE exporter.
You can get it from https://gforge.inria.fr/projects/verveinej/
Anonymous checkout is possible with the command:
svn checkout svn://scm.gforge.inria.fr/svn/verveinej/verveine.extractor.java
VerveineJ is based on the Eclipse JDT parser (JDT = Java Development Toolkit) and binding resolver. However, you don't need to install eclipse to run it, the necessary libraries are included.
VerveineJ can be ran more or less as a java compiler, you specify the source path, the class path, possibly the java version (1.2, 1.3, ...) etc. and it should create an "output.mse" file with all your entities and their relationship (inheritances, accesses, references, and invocations).
A shell script "verveine.sh" should help the new comers to execute their first export:
$ verveinej <some-Java-sourcedir>
VerveineJ has already been used to create an MSE model of Eclipse (v. 3.1): >346000 FAMIX.Entities ; >7800 classes, >53500 methods, >147000 invocation, etc.
And of course it is free software, so you can get your hands dirty and hack it to do what you need. It is as simple as visiting an AST (i.e. Abstract Syntax Tree, of course!).
nicolas
PS: If I can find the time to get CDT (Eclipse C/C++ Development Toolkit) to work in batch mode, a VerveineC is planned in the not-too-distant-I-hope future. Help welcome :-)
-- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 26 Oct 2010, at 15:19, Stéphane Ducasse wrote:
That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
Yes, I know, but that does not tell me how this performs wrt infusion. Did you do any comparison of its output versus infusion's output? Any Java code that kills infusion but not verveinej? I dont say you have to do it, I am just curious ...
and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
OK, let me rephrase: do you consider dedicating time to it in the future to bugfix, to update for new releases of Java or do you consider it out of the scope of the project?
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
For the comparison with infusion, one point is that I could never get infusion to work properly (or at all) for me :-( So this limits my ability to compare them. :-)
I understand that infusion has well known limitations. The point of verveine is that the code is there for anyone to overcome the limitations that hurt him/her most.
So as steph said: you have access to the code.
I don't know either how old/recent is the last version of infusion? Does it support Java 1.6, for example ? Actually verveineJ does not :-) Well, in the sense that it does not output anything particular for parameterized types for example. But it parses java 1.6 without problem and the information is available in the AST. If someone needs it, s/he just needs to figure out how to fit this in the meta model and write the piece of code that will create the proper Famix Entities.
As for the resources, I plan to use it in the short to medium term. So I will be maintaining it in the near future as well as my limited time allows. After, it will depend on people. If nobody feels the need to maintain it it will be because it is not needed. Which can be happen because Moose is no longer in use or because java became irrelevant :-)
One strength is that it uses JDT, so the parser itself is maintained by another entity which does have more resources than us. VerveineJ in itself "just" visit the AST produced by the JDT parser ...
But try it and see for yourself. Tell us what you think
I tried to document thoroughly the source code so that it would be easier to get in ...
nicolas
On Tue, Oct 26, 2010 at 9:02 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
On 26 Oct 2010, at 15:19, Stéphane Ducasse wrote:
That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
Yes, I know, but that does not tell me how this performs wrt infusion. Did you do any comparison of its output versus infusion's output? Any Java code that kills infusion but not verveinej? I dont say you have to do it, I am just curious ...
and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
OK, let me rephrase: do you consider dedicating time to it in the future to bugfix, to update for new releases of Java or do you consider it out of the scope of the project?
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Nicolas,
For the comparison with infusion, one point is that I could never get infusion to work properly (or at all) for me :-( So this limits my ability to compare them. :-)
What part of it does not work for you? Here is a short how to: http://www.themoosebook.org/book/externals/import-export/java
I understand that infusion has well known limitations.
It does have limitations, but it would be very interesting to compare the two.
The point of verveine is that the code is there for anyone to overcome the limitations that hurt him/her most.
So as steph said: you have access to the code.
So, what is the license? :)
I don't know either how old/recent is the last version of infusion? Does it support Java 1.6, for example ? Actually verveineJ does not :-) Well, in the sense that it does not output anything particular for parameterized types for example. But it parses java 1.6 without problem and the information is available in the AST. If someone needs it, s/he just needs to figure out how to fit this in the meta model and write the piece of code that will create the proper Famix Entities.
inFusion is the same in this area.
As for the resources, I plan to use it in the short to medium term. So I will be maintaining it in the near future as well as my limited time allows. After, it will depend on people. If nobody feels the need to maintain it it will be because it is not needed. Which can be happen because Moose is no longer in use or because java became irrelevant :-)
One strength is that it uses JDT, so the parser itself is maintained by another entity which does have more resources than us. VerveineJ in itself "just" visit the AST produced by the JDT parser ...
Perhaps an interesting thing would be to export a complete AST.
But try it and see for yourself.
I will :)
Tell us what you think
I tried to document thoroughly the source code so that it would be easier to get in ...
Cheers, Doru
nicolas
On Tue, Oct 26, 2010 at 9:02 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
On 26 Oct 2010, at 15:19, Stéphane Ducasse wrote:
That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
Yes, I know, but that does not tell me how this performs wrt infusion. Did you do any comparison of its output versus infusion's output? Any Java code that kills infusion but not verveinej? I dont say you have to do it, I am just curious ...
and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
OK, let me rephrase: do you consider dedicating time to it in the future to bugfix, to update for new releases of Java or do you consider it out of the scope of the project?
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Nicolas, thanks for the clarifications! I hope to be able to find some time in Dec/Jan to further work on AspectMaps. I will then certainly try VerveineJ!
On 26 Oct 2010, at 17:14, anquetil.nicolas@gmail.com wrote:
For the comparison with infusion, one point is that I could never get infusion to work properly (or at all) for me :-( So this limits my ability to compare them. :-)
I understand that infusion has well known limitations. The point of verveine is that the code is there for anyone to overcome the limitations that hurt him/her most.
So as steph said: you have access to the code.
I don't know either how old/recent is the last version of infusion? Does it support Java 1.6, for example ? Actually verveineJ does not :-) Well, in the sense that it does not output anything particular for parameterized types for example. But it parses java 1.6 without problem and the information is available in the AST. If someone needs it, s/he just needs to figure out how to fit this in the meta model and write the piece of code that will create the proper Famix Entities.
As for the resources, I plan to use it in the short to medium term. So I will be maintaining it in the near future as well as my limited time allows. After, it will depend on people. If nobody feels the need to maintain it it will be because it is not needed. Which can be happen because Moose is no longer in use or because java became irrelevant :-)
One strength is that it uses JDT, so the parser itself is maintained by another entity which does have more resources than us. VerveineJ in itself "just" visit the AST produced by the JDT parser ...
But try it and see for yourself. Tell us what you think
I tried to document thoroughly the source code so that it would be easier to get in ...
nicolas
On Tue, Oct 26, 2010 at 9:02 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
On 26 Oct 2010, at 15:19, Stéphane Ducasse wrote:
That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
Yes, I know, but that does not tell me how this performs wrt infusion. Did you do any comparison of its output versus infusion's output? Any Java code that kills infusion but not verveinej? I dont say you have to do it, I am just curious ...
and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
OK, let me rephrase: do you consider dedicating time to it in the future to bugfix, to update for new releases of Java or do you consider it out of the scope of the project?
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Thanks Nicolas for the clarification, I like the idea to have it open...
Alexandre
On 26 Oct 2010, at 17:14, anquetil.nicolas@gmail.com wrote:
For the comparison with infusion, one point is that I could never get infusion to work properly (or at all) for me :-( So this limits my ability to compare them. :-)
I understand that infusion has well known limitations. The point of verveine is that the code is there for anyone to overcome the limitations that hurt him/her most.
So as steph said: you have access to the code.
I don't know either how old/recent is the last version of infusion? Does it support Java 1.6, for example ? Actually verveineJ does not :-) Well, in the sense that it does not output anything particular for parameterized types for example. But it parses java 1.6 without problem and the information is available in the AST. If someone needs it, s/he just needs to figure out how to fit this in the meta model and write the piece of code that will create the proper Famix Entities.
As for the resources, I plan to use it in the short to medium term. So I will be maintaining it in the near future as well as my limited time allows. After, it will depend on people. If nobody feels the need to maintain it it will be because it is not needed. Which can be happen because Moose is no longer in use or because java became irrelevant :-)
One strength is that it uses JDT, so the parser itself is maintained by another entity which does have more resources than us. VerveineJ in itself "just" visit the AST produced by the JDT parser ...
But try it and see for yourself. Tell us what you think
I tried to document thoroughly the source code so that it would be easier to get in ...
nicolas
On Tue, Oct 26, 2010 at 9:02 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
On 26 Oct 2010, at 15:19, Stéphane Ducasse wrote:
That is excellent news. It seems that it would integrate nicely with the Eclipse plugin I wrote that exports aspect information. This way I can have all the data visualized in AspectMaps coming from a single source.
I have two questions: How does it compare to the infusion tool in funcionality/correctness
you can modify the code and have access to it freely.
Yes, I know, but that does not tell me how this performs wrt infusion. Did you do any comparison of its output versus infusion's output? Any Java code that kills infusion but not verveinej? I dont say you have to do it, I am just curious ...
and are there any resources available to dedicate time on this in the future to keep it up to date?
There is no resources except us.
OK, let me rephrase: do you consider dedicating time to it in the future to bugfix, to update for new releases of Java or do you consider it out of the scope of the project?
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
anquetil.nicolas＠gmail.com -
Johan Fabry -
Stéphane Ducasse -
Tudor Girba