Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
I will look at your code later today. Thanks Doru.
Cheers, Alexandre
On 25 Nov 2007, at 12:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 25 nov. 07, at 16:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Doru can you tell us where that I have a look too?
I only see
FAMIXAbstractBehavioralEntity>>allAccesses <navigation: 'Accesses'>
^Group withAll: self accesses asSet withDescription: 'Accesses'
Stef
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
The ugly code is actually in FAMIXAbstractStructuralEntity>>incomingAccess. But the error is due to not setting the mooseModel properly which is strange because MooseModel>>addEntity: should set it.
Doru
On Nov 26, 2007, at 2:07 PM, Stéphane Ducasse wrote:
On 25 nov. 07, at 16:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Doru can you tell us where that I have a look too?
I only see
FAMIXAbstractBehavioralEntity>>allAccesses <navigation: 'Accesses'>
^Group withAll: self accesses asSet withDescription: 'Accesses'
Stef
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
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 www.tudorgirba.com/blog
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Thanks Doru. I do not really get what was wrong in my implementation, but it loads well now. Hum... But I am still stuck. Do you think I can solve this allAccesses issue on my own? Will give a try...
Alexandre
On 25 Nov 2007, at 12:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
The problem was that you added your entities in MooseModel root instead of adding them in a new model inside MooseModel root :).
As for accesses I still did not figure out what the problem actually it. I will take a look on Monday at it.
Doru
On Nov 30, 2007, at 12:42 PM, Bergel, Alexandre wrote:
Thanks Doru. I do not really get what was wrong in my implementation, but it loads well now. Hum... But I am still stuck. Do you think I can solve this allAccesses issue on my own? Will give a try...
Alexandre
On 25 Nov 2007, at 12:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
As for accesses I still did not figure out what the problem actually it. I will take a look on Monday at it.
Thanks Doru, Alexandre
On Nov 30, 2007, at 12:42 PM, Bergel, Alexandre wrote:
Thanks Doru. I do not really get what was wrong in my implementation, but it loads well now. Hum... But I am still stuck. Do you think I can solve this allAccesses issue on my own? Will give a try...
Alexandre
On 25 Nov 2007, at 12:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
I took a look and I spotted the problem: you only add the classes in the model, but you should add all objects in there (including the attributes).
Your implementation is similar to the one in SmalltalkImporter but it is not quite the same. One difference is that in the SmalltalkImporter the entities are not added in the model at all, but they are stored in the instance variables. This happens because the SmalltalkImporter is used only internally within the NameSpaceImporter and PundleImporter.
Take a look at AbstractNewImporter>>basicRun. In there the elements will be the SmalltalkImporter which implements do: as a traversal over the parsed elements, and the these elements are passed to the InstallElementsOperator which actually adds them to the model.
Cheers, Doru
On Nov 30, 2007, at 3:38 PM, Bergel, Alexandre wrote:
As for accesses I still did not figure out what the problem actually it. I will take a look on Monday at it.
Thanks Doru, Alexandre
On Nov 30, 2007, at 12:42 PM, Bergel, Alexandre wrote:
Thanks Doru. I do not really get what was wrong in my implementation, but it loads well now. Hum... But I am still stuck. Do you think I can solve this allAccesses issue on my own? Will give a try...
Alexandre
On 25 Nov 2007, at 12:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
"It's not how it is, it is how we see it."
Thanks Doru, will have a look at it asap.
Cheers, Alexandre
On 3 Dec 2007, at 17:56, Tudor Girba wrote:
Hi Alex,
I took a look and I spotted the problem: you only add the classes in the model, but you should add all objects in there (including the attributes).
Your implementation is similar to the one in SmalltalkImporter but it is not quite the same. One difference is that in the SmalltalkImporter the entities are not added in the model at all, but they are stored in the instance variables. This happens because the SmalltalkImporter is used only internally within the NameSpaceImporter and PundleImporter.
Take a look at AbstractNewImporter>>basicRun. In there the elements will be the SmalltalkImporter which implements do: as a traversal over the parsed elements, and the these elements are passed to the InstallElementsOperator which actually adds them to the model.
Cheers, Doru
On Nov 30, 2007, at 3:38 PM, Bergel, Alexandre wrote:
As for accesses I still did not figure out what the problem actually it. I will take a look on Monday at it.
Thanks Doru, Alexandre
On Nov 30, 2007, at 12:42 PM, Bergel, Alexandre wrote:
Thanks Doru. I do not really get what was wrong in my implementation, but it loads well now. Hum... But I am still stuck. Do you think I can solve this allAccesses issue on my own? Will give a try...
Alexandre
On 25 Nov 2007, at 12:55, Tudor Girba wrote:
Hi Alex,
We have a back pointer to the model because we want to easily navigate anywhere else. This is set in the background when you addEntity: to the model.
I took a quick look, and I also noticed that you created the model in a wrong way. I fixed it in a new branch. Please take a look and if you like it, republish it without the branching suffix.
However, somehow the backpointer to the model is not set. I could not see it at first glance.
Anyway, the code in allAccesses you just discovered an ugly piece of code that instead of having the incomingAccesses set locally, it depends on the global things in the model. This must be changed.
Cheers, Doru
On Nov 25, 2007, at 2:52 AM, Alexandre Bergel wrote:
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part of. But I do not know how to set it.
the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the SCGStore.
I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
<Test.java>_______________________________________________ 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
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
"It's not how it is, it is how we see it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Bergel, Alexandre -
Stéphane Ducasse -
Tudor Girba