Status: New Owner: ---- Labels: Type-Defect Priority-Medium
New issue 560 by usman.bh...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Describe the problem: what do you get? what do you expect? I import Java mse (VerveineJ) and I want to run a small program to calculate all outgoing relationships of all the classes present in the mse. I get this message below:
FAMIXClass(Object)>>doesNotUnderstand: #parentType Receiver: FontChooserMain in org::jhotdraw::samples::font (Type) Arguments and temporary variables: aMessage: parentType exception: MessageNotUnderstood:
How to reproduce the problem: step by step if necessary import java mse with VerveineJ Add SoftEngMetrics package from Montecello. CohesionCouplingReport generateReportv7ForModel: 'JHotDraw_7.6-swing-awt-VerveineJ' fileName: 'JHotDraw_7.6-swing-awt-VerveineJ-',(Date today printString),'.csv'.
Additional information: platform, context which may impact the problem Last three message from execution context: FAMIXClass(Object)>>doesNotUnderstand: #parentType Receiver: FontChooserMain in org::jhotdraw::samples::font (Type) Arguments and temporary variables: aMessage: parentType exception: MessageNotUnderstood: FAMIXClass>>parentType resumeValue: nil Receiver's instance variables: mooseID: 564997 state: a MooseDefaultState sourceAnchor: a FAMIXFileAnchor #noname sourceLanguage: nil comments: an Array(/** * FontChooserMain....:31:24Z rawcoder $ */ (comment ...etc... declaredSourceLanguage: nil name: 'FontChooserMain' isStub: false receivingInvocations: #() modifiers: a Set(#isPublic) parentPackage: nil outgoingReferences: #() types: #() incomingReferences: #() subInheritances: #() methods: an Array(FontChooserMain>>FontChooserMain() (Method) FontChooserMain>>...etc... container: org (Namespace)::jhotdraw (Namespace)::samples (Namespace)::font (Na...etc... superInheritances: an Array(FontChooserMain -> JPanel (Inheritance)) attributes: #() isInterface: nil
FAMIXInvocation>>getReceivingFAMIXClass Receiver: FontChooserMain -> self#initComponents() (Invocation) Arguments and temporary variables: tmpReceiver: FontChooserMain.self (ImplicitVariable) belongsTo: nil Receiver's instance variables: mooseID: 679516 state: a MooseDefaultState sourceAnchor: nil sourceLanguage: nil comments: #() declaredSourceLanguage: nil previous: nil next: FontChooserMain -> self#add(Component) (Invocation) sender: FontChooserMain>>FontChooserMain() (Method) receiver: FontChooserMain.self (ImplicitVariable) receiverSourceCode: nil signature: 'initComponents()' candidates: an Array(FontChooserMain>>initComponents() (Method))
Please fill in the labels with the following information: * Type-Defect, Type-Enhancement, Type-Engineering, Type-Review, Type-Other * Component-XXX
Comment #1 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Could you please put somewhere the MSE file and provide a link?
Comment #2 on issue 560 by usman.bh...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
http://dl.dropbox.com/u/11804892/JHotDraw_7.6-swing-awt-VerveineJ.mse
Comment #3 on issue 560 by andreho...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
The problem is in VerveineJ, not in Moose. VerveineJ should be updated according to what Doru said in a previous email ("the implicit variable used to be attached to the class and now it is attached to the method"):
http://code.google.com/p/moose-technology/issues/detail?id=16
Updates: Labels: Component-VerveineJ Milestone-4.4
Comment #4 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Thanks for looking into this, Andre.
OK guys
let me just briefly keep you updated.
There as been changes in the meta-model for Moose 4.3 that needs to be ported to VerveineJ
I have been working on it these last three weeks.
Because VerveineJ was kind of a one shot development + several extensions, the source code was not as nice as I would have like it. So I took the opportunity to restructure it seriously (unfortunately, my first try at it led to a dead end and loosing one week of work)
I have also been detained by a stupid JDT parser issue.
The summary is: - I am slowly working on it. - Some of the new things have already been implemented (parameterizable class) - some other are on their way - tests are slowly turning back to their original nice green color
As soon as I have something at least equivalent to what it was in moose 4.1, I will post it.
nicolas
----- Mail original -----
De: moose-technology@googlecode.com À: moose-dev@iam.unibe.ch Envoyé: Lundi 21 Mars 2011 14:08:17 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model Updates: Labels: Component-VerveineJ Milestone-4.4
Comment #4 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Thanks for looking into this, Andre.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hello Nicolas,
I am happy to hear that work is going forward, a pity that it is not so straightforward.
I have a question: do you think that with your restructuring it would be possible/easy to have VerveineJ as an Eclipse plugin, generating .mse files on recompile ?
On 22 Mar 2011, at 08:59, Nicolas Anquetil wrote:
OK guys
let me just briefly keep you updated.
There as been changes in the meta-model for Moose 4.3 that needs to be ported to VerveineJ
I have been working on it these last three weeks.
Because VerveineJ was kind of a one shot development + several extensions, the source code was not as nice as I would have like it. So I took the opportunity to restructure it seriously (unfortunately, my first try at it led to a dead end and loosing one week of work)
I have also been detained by a stupid JDT parser issue.
The summary is:
- I am slowly working on it.
- Some of the new things have already been implemented (parameterizable class)
- some other are on their way
- tests are slowly turning back to their original nice green color
As soon as I have something at least equivalent to what it was in moose 4.1, I will post it.
nicolas
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
this is a nice idea
I will think about it.
I would tend to say that it is possible because it solely based on the result of JDT parser. So a plugin should not have difficulty doing this ...
nicolas
----- Mail original -----
De: "Johan Fabry" jfabry@dcc.uchile.cl À: "Moose-related development" moose-dev@iam.unibe.ch Envoyé: Mardi 22 Mars 2011 17:02:36 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model Hello Nicolas,
I am happy to hear that work is going forward, a pity that it is not so straightforward.
I have a question: do you think that with your restructuring it would be possible/easy to have VerveineJ as an Eclipse plugin, generating .mse files on recompile ?
On 22 Mar 2011, at 08:59, Nicolas Anquetil wrote:
OK guys
let me just briefly keep you updated.
There as been changes in the meta-model for Moose 4.3 that needs to be ported to VerveineJ
I have been working on it these last three weeks.
Because VerveineJ was kind of a one shot development + several extensions, the source code was not as nice as I would have like it. So I took the opportunity to restructure it seriously (unfortunately, my first try at it led to a dead end and loosing one week of work)
I have also been detained by a stupid JDT parser issue.
The summary is:
- I am slowly working on it.
- Some of the new things have already been implemented
(parameterizable class)
- some other are on their way
- tests are slowly turning back to their original nice green color
As soon as I have something at least equivalent to what it was in moose 4.1, I will post it.
nicolas
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks nicolas! VerveineJ is important for us. May be usman can also have a look because I think that the C# logic should be close to the one of verveineJ.
Stef On Mar 22, 2011, at 1:59 PM, Nicolas Anquetil wrote:
OK guys
let me just briefly keep you updated.
There as been changes in the meta-model for Moose 4.3 that needs to be ported to VerveineJ
I have been working on it these last three weeks.
Because VerveineJ was kind of a one shot development + several extensions, the source code was not as nice as I would have like it. So I took the opportunity to restructure it seriously (unfortunately, my first try at it led to a dead end and loosing one week of work)
I have also been detained by a stupid JDT parser issue.
The summary is:
- I am slowly working on it.
- Some of the new things have already been implemented (parameterizable class)
- some other are on their way
- tests are slowly turning back to their original nice green color
As soon as I have something at least equivalent to what it was in moose 4.1, I will post it.
nicolas
----- Mail original -----
De: moose-technology@googlecode.com À: moose-dev@iam.unibe.ch Envoyé: Lundi 21 Mars 2011 14:08:17 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model Updates: Labels: Component-VerveineJ Milestone-4.4
Comment #4 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Thanks for looking into this, Andre.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
MetaModel needs to be corrected:
ImplicitVariable>>container returns a Type
whereas ImplicitVariable>>belngsTo specifies a ContainerEntity (that should be a method if I understood well)
nicolas
----- Mail original -----
De: moose-technology@googlecode.com À: moose-dev@iam.unibe.ch Envoyé: Lundi 21 Mars 2011 14:08:17 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model Updates: Labels: Component-VerveineJ Milestone-4.4
Comment #4 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Thanks for looking into this, Andre.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
You are right. This is because belongsTo is inherited from FAMIXNamedEntity.
This should be changed, but it should not affect VerveineJ because you are not supposed to populate that property (it is a derived one)
Cheers, Doru
On 23 Mar 2011, at 15:22, Nicolas Anquetil wrote:
MetaModel needs to be corrected:
ImplicitVariable>>container returns a Type
whereas ImplicitVariable>>belngsTo specifies a ContainerEntity (that should be a method if I understood well)
nicolas
----- Mail original -----
De: moose-technology@googlecode.com À: moose-dev@iam.unibe.ch Envoyé: Lundi 21 Mars 2011 14:08:17 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model Updates: Labels: Component-VerveineJ Milestone-4.4
Comment #4 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Thanks for looking into this, Andre.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
----- Mail original -----
De: "Tudor Girba" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch Cc: codesite-noreply@google.com Envoyé: Vendredi 25 Mars 2011 10:47:17 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model You are right. This is because belongsTo is inherited from FAMIXNamedEntity.
This should be changed, but it should not affect VerveineJ because you are not supposed to populate that property (it is a derived one)
right but I test it. And its return type was not the right one
nicolas
Cheers, Doru
On 23 Mar 2011, at 15:22, Nicolas Anquetil wrote:
MetaModel needs to be corrected:
ImplicitVariable>>container returns a Type
whereas ImplicitVariable>>belngsTo specifies a ContainerEntity (that should be a method if I understood well)
nicolas
----- Mail original -----
De: moose-technology@googlecode.com À: moose-dev@iam.unibe.ch Envoyé: Lundi 21 Mars 2011 14:08:17 Objet: [Moose-dev] Re: Issue 560 in moose-technology: parentType bug in Java model Updates: Labels: Component-VerveineJ Milestone-4.4
Comment #4 on issue 560 by tudor.gi...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
Thanks for looking into this, Andre.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Updates: Status: Fixed
Comment #5 on issue 560 by anquetil...@gmail.com: parentType bug in Java model http://code.google.com/p/moose-technology/issues/detail?id=560
(No comment was entered for this change.)