Status: New
Owner: andreho...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-Famix
New issue 509 by andreho...(a)gmail.com: Modularization Quality Metric
http://code.google.com/p/moose-technology/issues/detail?id=509
We implemented the Bunch metrics of coupling and cohesion as quality
metrics for existing packages (FAMIXPackage) and namespaces
(FAMIXNamespace).
Now the idea is to implement the Modularization Quality Metric as a quality
metric for existing group of packages (FAMIXPackageGroup) and namespaces
(FAMIXNamespaceGroup).
Pointer to the papers that propose the metrics:
Using Automatic Clustering to Produce High-Level System Organizations of
Source Code (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=693283)
Bunch: A Clustering Tool for the Recovery and Maintenance of Software
System Structures
(http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=792498)
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 767 by sean.p.d...(a)gmail.com: Book: presentation names are
confusing
http://code.google.com/p/moose-technology/issues/detail?id=767
For example, on
http://www.themoosebook.org/book/internals/glamour/presentations/action-list
ActionListPresentation is referenced, but the class name is
GLMActionListPresentation. So, when I pasted it into a workspace, it was
highlighted red as an unrecognized class. I think it'd be clearer to either
use full presentation class names or spaces between camel case
(e.g. "Action List Presentation").
The same is true for some of the other presentations e.g. DiffPresentation
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 644 by cy.delau...(a)gmail.com: A fly by help to show each time the
source code of an entity
http://code.google.com/p/moose-technology/issues/detail?id=644
Maybe it would be interesting when navigating in moose, to always have a
fly by help that show the source code of an element
Status: New
Owner: ----
CC: georgega...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-ExternalTools
New issue 782 by tudor.gi...(a)gmail.com: inFamix should export basic metrics
for methods
http://code.google.com/p/moose-technology/issues/detail?id=782
inFamix should export basic method metrics:
- LOC (lines of code)
- NOS (number of statements)
- CYCLO (cyclomatic complexity)
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Glamour
New issue 582 by tudor.gi...(a)gmail.com: Watcher support in Glamour
http://code.google.com/p/moose-technology/issues/detail?id=582
Like we now have a statusbar, we should also have a detailed preview shown
in a floating Watcher window. The behavior would be similar to Quick Look
on Mac.
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6
New issue 763 by tudor.gi...(a)gmail.com: VerveineJ generates wrong paths in
source anchors when there is a . in the root folder
http://code.google.com/p/moose-technology/issues/detail?id=763
Do this:
- download:
http://sourceforge.net/projects/jfreechart/files/latest/download
- go to: jfreechart-1.0.14
- execute:
/PATH_TO_verveine.extractor.java/verveinej.sh -Xmx2000m -- -autocp . .
The fileNames all start with "0.14/./" instead of "./"
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-ExternalTools
New issue 721 by tu...(a)tudorgirba.com: VerveineJ should mark constructors
http://code.google.com/p/moose-technology/issues/detail?id=721
Constructors should be marked with isConstructor.
Hi fellows,
I'm starting to use VerveineJ to parse java projects to MSE format. I want
to know if there's a way to set the output path/filename as a parameter of
the execution, instead of the default: "output.mse"
thanks in advance for your answer,
Matías Barahona.
Stef and I think that Kontractor should be include in Moose by default to
offer a tool for reducing title length.
Do you think it's a good idea and do you know a better tool to do this?
--
*Guillaume Larcheveque*
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-MooseTools
New issue 786 by anquetil...(a)gmail.com: MooseQueryResult>>intersection: is
broken
http://code.google.com/p/moose-technology/issues/detail?id=786
calling intersection between two MooseQueryResult produces an error
because "MooseQueryResult is not a variable type"
This is raised in basicNew:
A possible workaround is to redefine MooseQueryResult>>intersection:
aCollection
| result |
result := self class new.
aCollection do: [ :each|
((self includes: each) and: [(result includes: each) not])
ifTrue: [ result add: each]].
^ result
But it might not be the best solution since I assume basicNew: might be
called from other methods ...