Stef, you seem to be talking about a Gofer-like tool for fetching and loading MSEs (and source files) within a moose image from a squaksource-like repository. is that correct ? 
Having an easy to use API would surely be helpful. 

what we were thinking about was a bit simpler but i believe that the two things can come together. 

we thought about: 
- setting up a server capable of generating MSEs from given source code files
- uploading the latest version of qualities corpus (http://qualitascorpus.com/ - both evolutionary and regular version)
- generating MSEs (and maybe moose images with preloaded MSEs)
- inviting users to download the contents via shell scripts (fetching source code from the qualities corpus web site and everything else from our server)  

most of the metadata related to the single projects are already provided as part of the qualities corpus in textual format.
the verveineJ issue still has to be clarified. 
If there is a way to know more about the version being used for generating the models, it would be easy to write this information in a text file or simply including it in the filename.  


On Jul 23, 2012, at 10:35 AM, Stéphane Ducasse wrote:


On Jul 22, 2012, at 3:53 PM, Fabrizio Perin wrote:

Hi Jannik,
you should definitely talk with Mircea who is planing to create a FAMIX Corpus. He wanted to create something more complex than a bunch of mse files on a server. He was trying to identify useful metadata to add to the files to.  

Anyway, I like the idea and yes from the point of view having a mse files repo I think the only mandatory meta-data are: name and version of the extractor used to create the mse and the version of Moose that can load the file. Other simple meta-data could be: name and version of the extracted system, language of the system, and number of classes and methods (just to have an idea of the system size).

Indeed this was in really early version of famix and after we lost it.
Metadata is important. Guillaume and andre also worked on how to manage versions so that we can compute different trend analysis.
We discussed also with usman about the structure of a typical project

- original files
- maximum import mse files
- shrunk mse files (because to compute certain metrics we do not need to load the complete use files - size problem)

A project should be a FAMIX entity so that we do not fill up code with path and other uglies.
And so that we can query
Project
allProjects
Project
named: 'Azureus';
loadLatestVersion



If people want to discuss and join I think that this is needed for moose.

Stef


Cheers,
Fabrizio



2012/7/21 jannik.laval <jannik.laval@gmail.com>
Hi guys,

Each time we need to do case studies in Moose, we have to select the software application, in a certain version and probably without all the source code needed. This results on evaluations that are probably not reproducible.

I think that we need to unify our efforts and share the mse files of our models. With that, it will be not necessary to generate a FAMIX model each time we need one.

For now, I begun to generate the model from the Qualitas Corpus 'e' (http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems. The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the info.plist file of Moose 4.6.

I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the version(s) of Moose that can load the file. I tried one mse file with Moose4.6.

We also need a server that can accept all the files.
Any suggestion ?

Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev