18 Aug
2007
18 Aug
'07
12:29 a.m.
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."
19 Aug
19 Aug
10:45 a.m.
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
11:13 a.m.
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."
4:07 p.m.
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 :)
4:08 p.m.
On 19 août 07, at 11:13, sellossa(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:19 p.m.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
20 Aug
20 Aug
12:42 a.m.
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(a)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.
21 Aug
21 Aug
10:21 a.m.
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(a)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.
1:10 p.m.
Yep. That is the best solution.
Cheers,
Doru
On Aug 21, 2007, at 10:21 AM, sellossa(a)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
--
www.iam.unibe.ch/~girba
www.iam.unibe.ch/~girba/blog/
"One cannot do more than one can do."
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(a)ensieta.fr wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev So, imagine that an
user only needs MooseDeveloppement and not Meta, he will have a
bug in
loading the bundle because of MooseElementCodeGenerator.
6086
days inactive
6090
days old
8 comments
4 participants
participants (4)
-
Adrian Kuhn -
sellossa＠ensieta.fr -
Stéphane Ducasse -
Tudor Girba