Dear Radu and members of the Moose-List,
I am not sure whether my question is specific to moose or iPlasma, but I think that it is of a general interest. Are dependencies between Java classes extracted using iPlasma from the .java files? To illustrate this, let's assume I have these two classes:
public class A {} public class C { A a;}
The relation "C refers to A" does not seem to be contained in the .mse file. The attribute 'a' is defined as:
(FAMIX.Attribute (id: 17) (name 'a') (belongsTo (idref: 15)) (hasClassScope false) (accessControlQualifier package) (NMAV 0.0) )
No ref to 'A' therefore.
In Java4Moose, I extended the FAMIXClass with dependentClasses, that returns a list of FAMIXClass that are statically referenced in the receiver famix class. I principally did this as an exercise, but it seems that this information is missing in famix. Doru, you told me at the famoosr workshop that iPlasma extract static dependency. Where does this appear?
Regards, Alexandre
On Nov 18, 2008, at 2:35 PM, Alexandre Bergel wrote:
Dear Radu and members of the Moose-List,
I am not sure whether my question is specific to moose or iPlasma, but I think that it is of a general interest. Are dependencies between Java classes extracted using iPlasma from the .java files? To illustrate this, let's assume I have these two classes:
public class A {} public class C { A a;}
You could also have A new
which should be a reference.
The relation "C refers to A" does not seem to be contained in the .mse file. The attribute 'a' is defined as:
(FAMIX.Attribute (id: 17) (name 'a') (belongsTo (idref: 15)) (hasClassScope false) (accessControlQualifier package) (NMAV 0.0) )
No ref to 'A' therefore.
In Java4Moose, I extended the FAMIXClass with dependentClasses, that returns a list of FAMIXClass that are statically referenced in the receiver famix class. I principally did this as an exercise, but it seems that this information is missing in famix. Doru, you told me at the famoosr workshop that iPlasma extract static dependency. Where does this appear?
Regards, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
public class A {} public class C { A a;}
You could also have A new
which should be a reference.
Yes, but still static references have their importance. I did few visualizations, it seems that having static references does not differ much from getting dependencies from method invocations.
Alexandre
iPlasma has this information, it's just that indeed the iPlasma exporter does not export the field for declaredClass. This is a minor detail that could be easily fixed.
Cheers, Doru
On Nov 18, 2008, at 2:35 PM, Alexandre Bergel wrote:
Dear Radu and members of the Moose-List,
I am not sure whether my question is specific to moose or iPlasma, but I think that it is of a general interest. Are dependencies between Java classes extracted using iPlasma from the .java files? To illustrate this, let's assume I have these two classes:
public class A {} public class C { A a;}
The relation "C refers to A" does not seem to be contained in the .mse file. The attribute 'a' is defined as:
(FAMIX.Attribute (id: 17) (name 'a') (belongsTo (idref: 15)) (hasClassScope false) (accessControlQualifier package) (NMAV 0.0) )
No ref to 'A' therefore.
In Java4Moose, I extended the FAMIXClass with dependentClasses, that returns a list of FAMIXClass that are statically referenced in the receiver famix class. I principally did this as an exercise, but it seems that this information is missing in famix. Doru, you told me at the famoosr workshop that iPlasma extract static dependency. Where does this appear?
Regards, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."