Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 781 by santiago...(a)gmail.com: VerveineJ should mark getters
setters and constants
http://code.google.com/p/moose-technology/issues/detail?id=781
The property "kind" of the MSE models should be used to mark if a method is
a getter, a setters or constant.
Currently is only used to mark if a method is constructor
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Milestone-4.7
New issue 811 by anquetil...(a)gmail.com: Create more virtual association in
MooseChef
http://code.google.com/p/moose-technology/issues/detail?id=811
Famix recognizes 4 types of associations (reference, access, inheritance,
invocation) and Moosechef was built upon these dependencies
(queryAllOutgoingReferences, ...)
But this will miss a good deal of actual dependencies, because many of them
are not expressed by associations:
- exceptions caught, thrown
- parameter types in parameterized classes
- use of annotations
- other?
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 734 by tu...(a)tudorgirba.com: VerveineJ does not export parameters
for stub methods
http://code.google.com/p/moose-technology/issues/detail?id=734
If we analyze this code, the print method will appear without parameters.
public class NoParametersInStubMethods {
public void invoking() {
System.out.print("aString");
}
}
Status: Accepted
Owner: ----
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 761 by anquetil...(a)gmail.com: Missing method invocation with
VerveineJ
http://code.google.com/p/moose-technology/issues/detail?id=761
see discussion on mailing list: "invokingMethods broken in moose or inFamix"
source code:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/engines/ke…
The method getLinkedEntityTypes in
org.apache.stanbol.enhancer.engines.keywordextraction.linking.EntityLinker
has an empty collection of invokingMethods even though the method is
invoked for example by "process()".
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
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium
New issue 762 by usman.bh...(a)gmail.com: VerveineJ keeps the history of old
entities, when invoked from the Moose interface
http://code.google.com/p/moose-technology/issues/detail?id=762
First, I invoke VerveineJ from Moose menu to analyse a program A. It
analyses the program and imports its entities in a moose model. I invoke VJ
once more from moose menu to analyse another program B. When VJ is executed
and the entities of program B are imported, I also find in the same model
the entities related to the program A. So, VerveineJ keeps the history of
old entities, when invoked from Moose interface.
I think the problem can be resolved by deleting output.mse once VJ has
finished its analysis and the entities are imported in a moose model.
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6
New issue 746 by tu...(a)tudorgirba.com: VerveineJ should create parameters
for methods with different signatures
http://code.google.com/p/moose-technology/issues/detail?id=746
In some cases, calls to external libraries get reified as methods with
proper signatures, but without parameters.
I am trying to reproduce this using the following example (in
ad_hoc/MultipleSignatures.java):
package ad_hoc;
import java.io.PrintWriter;
import java.io.StringWriter;
public class MultipleSignatures {
public void callToRegularPrintStackTrace(Throwable t) {
t.printStackTrace()
}
public void callToPrintStackTraceWithParam(Throwable t) {
t.printStackTrace(new PrintWriter(new StringWriter()))
}
}
I encountered a similar code in a case study. However, in this case, I
cannot even get the parser to recognize both printStackTrace calls.
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Milestone-4.6 Component-Glamour
New issue 769 by tudor.gi...(a)gmail.com: Glamour should support drag and drop
http://code.google.com/p/moose-technology/issues/detail?id=769
Something like this:
a list
allowItemDrag: [:item :list | ... ];
itemDrag: [:item :list | ... ]
a list
allowDropOnItem: [:draggedObject :targetItem :list | ... ];
dropOnItem: [:draggedObject :targetItem :list | ... ]
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.7
New issue 809 by tudor.gi...(a)gmail.com: Glamour selection should happen
through an action
http://code.google.com/p/moose-technology/issues/detail?id=809
Right now, selecting an item in the user interface will directly populate
the #selection port. However, this is less than ideal because it does not
allow the developer to intervene in this process.
One possibility would be to introduce a selectionAction that is triggered
by the ui, and to provide the default behavior is simply setting the
#selection port.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-MooseCore Milestone-4.6
New issue 708 by tudor.gi...(a)gmail.com: Fame should accept comments both
for properties and for meta descriptions
http://code.google.com/p/moose-technology/issues/detail?id=708
Currently, the MSEComment: is used to define comments of a property.
SomeEntity>>someProperty
<MSEProperty: ...>
<MSEComment: 'comment'>
This is used by the MetaBrowser but not by Fame.
At the very least, we should add a means to add MSEComment: to the class
side for the overall class.