Comment #5 on issue 476 by anquetil.nicolas: VerveineJ should export some metrics http://code.google.com/p/moose-technology/issues/detail?id=476
I am not sure I want to follow you on this one.
Both metrics can easily be computed from the data already available. I would like to keep Verveine as lean as possible.
The compatibility argument does not convince me either. I suppose you mean compatibility with infusion? I mean no harm to infusion and it does provide good inspiration, but it is not a standard, it is only one tool to export java code to MSE (just as VerveineJ is another one).
Comment #6 on issue 476 by tudor.girba: VerveineJ should export some metrics http://code.google.com/p/moose-technology/issues/detail?id=476
When I said "for compatibility" I not only meant the way inFusion does it, but also for the meaning is supposed to be. The source anchor of a method should include annotations, comments and javadoc. I am not sure what the status of VerveineJ is in this area, but it should be like that. However, LOC should ignore the javadoc and the annotations to preserve the intended meaning of the metric as we use it in Moose.
Comment #7 on issue 476 by anquetil.nicolas: VerveineJ should export some metrics http://code.google.com/p/moose-technology/issues/detail?id=476
In VerveineJ, I have attached the javadoc to the entity, but it is not part of the source anchor.
One of the issue is that I don't really have access to it. I can more or less reconstruct the javadoc through the list of its tags, but this is not the "real" comment that is in the source code.
I believe I could get the line number of the javadoc, but I am still not convinced that it would be the ideal solution.
I prefer the idea of doing the minimum processing (and interpretation) possible on the data, and leave the user decide what s-he wants to do with it (given that s-he has the needed elementd for that). I added Cyclomatic and Number of Statement metrics because as you point out, they cannot be computed from the MSE. I am giving the user the possibility to compute the LOC s-he wants, by attaching the source anchor to the code entity (did not do it for the javadoc, but I believe I could). From that s-he is able to compute the LOC s-he wants (with or without javadoc).
Anybody else as an opinion on this to try to find a consensual decision .... ?
Comment #8 on issue 476 by jfabry: VerveineJ should export some metrics http://code.google.com/p/moose-technology/issues/detail?id=476
Two comments, thinking about extra/duplicated work: Where would the LOC-computing code be? I use LOC in AspectMaps, Polymetric views use LOC ... If multiple users need to implement this in their own codebase, it would be better instead to have this as a feature of Moose itself right?
From a Java-import-user point of view, ideally I would be able to switch from inFusion to VerveineJ without having to modify code (except for the invocation of the importer). Anything that makes the switch harder makes a new importer more trouble for everybody that wants to make the switch.
-
moose-technology＠googlecode.com