Issue 560 in moose-technology: parentType bug in Java model

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 560 by [hidden email]: 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


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #1 on issue 560 by [hidden email]: 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?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #2 on issue 560 by [hidden email]: 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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #3 on issue 560 by [hidden email]: 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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Labels: Component-VerveineJ Milestone-4.4

Comment #4 on issue 560 by [hidden email]: 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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 -----
_______________________________________________
Moose-dev mailing list
[hidden email]
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:

--
Johan Fabry  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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 -----
_______________________________________________
Moose-dev mailing list
[hidden email]
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:


_______________________________________________
Moose-dev mailing list
[hidden email]
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 -----
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Fixed

Comment #5 on issue 560 by [hidden email]: parentType bug in Java  
model
http://code.google.com/p/moose-technology/issues/detail?id=560

(No comment was entered for this change.)

_______________________________________________
Moose-dev mailing list
[hidden email]
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:

--
www.tudorgirba.com

"Relationships are of two kinds: those we choose and those that happen. They both matter."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

----- Mail original -----
right
but I test it.
And its return type was not the right one

nicolas

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev