Hi Sara,
I saw you added the Ecore code into Meta. I did not have the time to take a closer look, but I did noticed you have a lot of tests for your code, and they are all green. That is nice :).
As you probably saw in the previous mail, adding EcoreImportExport to Meta generated some loading problems when loading 'Moose Config', because you have two classes that are in SCG.Moose namespace. However, Meta does not depend on Moose, but Moose depends on Meta. So, no class in the Meta bundle should be in the Moose namespace.
I see several solutions to fix the problem: - move the classes to the Meta namespace for now, although they do not belong there - move the classes to the MooseDevelopment bundle - move the classes in a separate bundle that has MooseDevelopment bundle as prerequisite
Also, please add comments to the versions you are adding, because it helps us track what is happening.
In any case, I am looking forward to taking a closer look at the code :).
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."
Hello Doru!
As you probably saw in the previous mail, adding EcoreImportExport to Meta generated some loading problems when loading 'Moose Config', because you have two classes that are in SCG.Moose namespace. However, Meta does not depend on Moose, but Moose depends on Meta. So, no class in the Meta bundle should be in the Moose namespace.
ok! I didn't know :( I put this classes in SCG.Moose because they generate MooseElements from a EMF model...
I see several solutions to fix the problem:
- move the classes to the Meta namespace for now, although they do
not belong there
- move the classes to the MooseDevelopment bundle
- move the classes in a separate bundle that has MooseDevelopment
bundle as prerequisite
Personnally, I think that I would choose the first solution. I can publish a new version of Meta where my two classes will be nested in Meta namespace. So, there will be no pb any more when loading Moose.config
However, I need some advices from stef. I need his opinion because I am not sure that I choose the best solution :)
Also, please add comments to the versions you are adding, because it helps us track what is happening.
sure, I will do this :)
sara
As you probably saw in the previous mail, adding EcoreImportExport to Meta generated some loading problems when loading 'Moose Config', because you have two classes that are in SCG.Moose namespace. However, Meta does not depend on Moose, but Moose depends on Meta. So, no class in the Meta bundle should be in the Moose namespace.
ok! I didn't know :( I put this classes in SCG.Moose because they generate MooseElements from a EMF model...
In eCoreImporter you should not have dependency on Moose or we should move that to Moose.
I see several solutions to fix the problem:
- move the classes to the Meta namespace for now, although they do
not belong there
- move the classes to the MooseDevelopment bundle
- move the classes in a separate bundle that has MooseDevelopment
bundle as prerequisite
Personnally, I think that I would choose the first solution. I can publish a new version of Meta where my two classes will be nested in Meta namespace. So, there will be no pb any more when loading Moose.config
However, I need some advices from stef. I need his opinion because I am not sure that I choose the best solution :)
We should be able to load Meta without moose. Think in terms of layers, you do not want that a foundation layer depends on the layers on top of it.
the stuff is done! I hope that it will fix the pb :)
sara
Hi Sara,
I saw you added the Ecore code into Meta. I did not have the time to take a closer look, but I did noticed you have a lot of tests for your code, and they are all green. That is nice :).
As you probably saw in the previous mail, adding EcoreImportExport to Meta generated some loading problems when loading 'Moose Config', because you have two classes that are in SCG.Moose namespace. However, Meta does not depend on Moose, but Moose depends on Meta. So, no class in the Meta bundle should be in the Moose namespace.
I see several solutions to fix the problem:
- move the classes to the Meta namespace for now, although they do
not belong there
- move the classes to the MooseDevelopment bundle
- move the classes in a separate bundle that has MooseDevelopment
bundle as prerequisite
Also, please add comments to the versions you are adding, because it helps us track what is happening.
In any case, I am looking forward to taking a closer look at the code :).
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."
On 19 août 07, at 11:13, sellossa@ensieta.fr wrote:
the stuff is done!
Which solution did you take?
I hope that it will fix the pb :)
sara
Hi Sara,
I saw you added the Ecore code into Meta. I did not have the time to take a closer look, but I did noticed you have a lot of tests for your code, and they are all green. That is nice :).
As you probably saw in the previous mail, adding EcoreImportExport to Meta generated some loading problems when loading 'Moose Config', because you have two classes that are in SCG.Moose namespace. However, Meta does not depend on Moose, but Moose depends on Meta. So, no class in the Meta bundle should be in the Moose namespace.
I see several solutions to fix the problem:
- move the classes to the Meta namespace for now, although they do
not belong there
- move the classes to the MooseDevelopment bundle
- move the classes in a separate bundle that has MooseDevelopment
bundle as prerequisite
Also, please add comments to the versions you are adding, because it helps us track what is happening.
In any case, I am looking forward to taking a closer look at the code :).
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi stef!
I've just seen your mails :)
Temporary, in waiting for your advices, I have put the two disturbing classes (MooseElementCodeGenerator and MooseElementCodeGEneratorTest) into Meta.
As you know, MooseElementCodeGEnerator generates, from an EMF model, classes that inherit from MooseElement.Therefore, MooseElementCodeGenerator is associated to Moose.
- If I move MooseElementCodeGenerator into the MooseDevelopment bundle, it will lead into a problem: indeed, MooseElementCodeGEnerator inherits from an other class, DomainCodeGenerator. This class is completely associated to Meta because It uses EMOF-MetaModel package. Nevertheless, DomainCodeGenerator has absolutly no link with Moose. So, imagine that an user only needs MooseDeveloppement and not Meta, he will have a bug in loading the bundle because of MooseElementCodeGenerator.
- If I move these two classes to Meta, as I did previously, it will be a bit illogical since MooseCodeGenerator is linked to Moose (because It generates MooseElement class and generates MooseModel class). Consequently, this solution is not the best
- Finally, the best solution is to create a complete separate bundle. This bundle should have Meta bundle and MooseDevelopment bundle as prerequiste.
So, tell me what do you think about that.
sara
On 19 août 07, at 11:13, sellossa@ensieta.fr wrote:
the stuff is done!
Which solution did you take?
I hope that it will fix the pb :)
sara
Hi Sara,
I saw you added the Ecore code into Meta. I did not have the time to take a closer look, but I did noticed you have a lot of tests for your code, and they are all green. That is nice :).
As you probably saw in the previous mail, adding EcoreImportExport to Meta generated some loading problems when loading 'Moose Config', because you have two classes that are in SCG.Moose namespace. However, Meta does not depend on Moose, but Moose depends on Meta. So, no class in the Meta bundle should be in the Moose namespace.
I see several solutions to fix the problem:
- move the classes to the Meta namespace for now, although they do
not belong there
- move the classes to the MooseDevelopment bundle
- move the classes in a separate bundle that has MooseDevelopment
bundle as prerequisite
Also, please add comments to the versions you are adding, because it helps us track what is happening.
In any case, I am looking forward to taking a closer look at the code :).
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hey Sara, Moose depends on Meta, hence that situation may not arise. To me it seems logical to put MECG into Moose.
cheers, AA
On 19 Aug 2007, at 23:19 , sellossa@ensieta.fr wrote:
So, imagine that an user only needs MooseDeveloppement and not Meta, he will have a bug in loading the bundle because of MooseElementCodeGenerator.
Hi!
ok, so I will put my two classes MooseElementCodeGenerator and MooseElementCodeGeneratorTest into MooseDeveloppement bundle.
The other classes of EMFImportExport will stay in MetaDevelopment
Do you agree with that?
sara
Hey Sara, Moose depends on Meta, hence that situation may not arise. To me it seems logical to put MECG into Moose.
cheers, AA
On 19 Aug 2007, at 23:19 , sellossa@ensieta.fr wrote:
So, imagine that an user only needs MooseDeveloppement and not Meta, he will have a bug in loading the bundle because of MooseElementCodeGenerator.
Yep. That is the best solution.
Cheers, Doru
On Aug 21, 2007, at 10:21 AM, sellossa@ensieta.fr wrote:
Hi!
ok, so I will put my two classes MooseElementCodeGenerator and MooseElementCodeGeneratorTest into MooseDeveloppement bundle.
The other classes of EMFImportExport will stay in MetaDevelopment
Do you agree with that?
sara
Hey Sara, Moose depends on Meta, hence that situation may not arise. To me it seems logical to put MECG into Moose.
cheers, AA
On 19 Aug 2007, at 23:19 , sellossa@ensieta.fr wrote:
So, imagine that an user only needs MooseDeveloppement and not Meta, he will have a bug in loading the bundle because of MooseElementCodeGenerator.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"One cannot do more than one can do."
-
Adrian Kuhn -
sellossa＠ensieta.fr -
Stéphane Ducasse -
Tudor Girba