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(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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(a)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(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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(a)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(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

As for accesses I still did not figure out what the problem actually it. I will take a look on Monday at it.

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(a)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(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)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(a)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(a)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(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)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(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)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(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev