27 Jul
2012
27 Jul
'12
4:04 p.m.
On Jul 26, 2012, at 7:29 PM, jannik.laval wrote:
On Jul 25, 2012, at 3:59 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
A separate MSE file or the same where the famix model is in ?
i tried to write down a list of all the meta-data needed:
- project name
- project version
- verveineJ version (i would use the SVN revision number)
is it enough ?
should we include the FAMIX version ?
I didn't include the supported moose version, because i don't think it's
relevant and i don't see how this information should be interpreted.
The rest of the data should be the following:
- MSE of FAMIX model
- source code
If there are multiple versions of a project, it would be also interesting to distribute an
Orion model of all the versions.
Is it possible to build such a model having an MSE file for each version as input ?
How much effort is needed to fix the bugs and make it work ?
How do you look for changes between subsequent versions ? Do you diff the source code of
the analyzed code entities ?
Would it make sense to distribute also a FUEL file containing the famix model ?
Would it make loading faster ?
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
why xml?
We could use use as use as well. It is usually much more readable than xml.
iep,
Just that xml is verbose :)
But mse is good too.
> - keeping source code (and much more) is important because you never know what people
would like to do in the future.
> It happened to a team in Brazil recently, they correlated some metrics to bugs.
> So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
> Anyway, people want to see source code. If something looks strange in a
visualization, you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus.
This means that MSE files would be generated and hosted by us and source code can be
downloaded from qualitascorpus.com.
Ok, all the MSE files are generated, I have them.
I will share them.
For the metadata, I propose to use an xml file that is independent of mse files / source
files.
Jannik
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
It could contains all the informations that we
discussed here.
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev