27 Jun
2014
27 Jun
'14
10:58 p.m.
Hi
Usman found that mooseDSM depends on Moose and that Moose depends on DSM.
This shows a problem with the configurations in the Moose ecosystem.
After thinking about it, there are two kinds of configurations:
- first kind of a configuration should express the dependencies to
systems that are mandatory.
- the second kind represents "Full project" configurations that
express a complete "applications"
with all the subapplications. They do not express that the tool
must all the dependencies to be resolved to work.
For example, MooseAlgos are in Moose even if we do not use MooseAlgos.
Such full project should not be referred too.
=> So we should distinguish such different configurations.
For example Glamour as a UI builder should not depend on Roassal
But Glamour as a full project can depend on Roassal.
Then at the Moose or project level we can decide what to load.
Stef
28 Jun
28 Jun
11:48 a.m.
So smallDude exhibits the same syndrom
I will probably introduce a configuration of FullMoose is for loading
the top level products
and remove from Moose the dependencies to DSM and SmallDude because
these cycles do not make sense
But it may break the default Moose so I will wait for your point of view.
Stf
On 27/6/14 22:58, stepharo wrote:
Hi
Usman found that mooseDSM depends on Moose and that Moose depends on DSM.
This shows a problem with the configurations in the Moose ecosystem.
After thinking about it, there are two kinds of configurations:
- first kind of a configuration should express the dependencies to
systems that are mandatory.
- the second kind represents "Full project" configurations that
express a complete "applications"
with all the subapplications. They do not express that the tool
must all the dependencies to be resolved to work.
For example, MooseAlgos are in Moose even if we do not use
MooseAlgos.
Such full project should not be referred too.
=> So we should distinguish such different configurations.
For example Glamour as a UI builder should not depend on Roassal
But Glamour as a full project can depend on Roassal.
Then at the Moose or project level we can decide what to load.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:09 p.m.
Hi,
These problems exist since a long time and we came previously to the
conclusion of introducing ConfigurationOfMooseEngines, ConfigurationOfFAMIX
and ConfigurationOfMooseUI. Nobody had time or inclination to do it, and we
are in the same situation now.
Ideally, the Moose/Moose repository should contain only the
ConfigurationOfMoose package. Everything else should be moved in a separate
repository with its own configuration.
But, we should keep ConfigurationOfMoose as the top level one because it is
known and there are external users of it. Is that Ok?
I am over my head in the following 1-2 weeks, but I can give a hand at
least with reviewing.
Cheers,
Doru
On Sat, Jun 28, 2014 at 11:48 AM, stepharo <stepharo(a)free.fr> wrote:
So smallDude exhibits the same syndrom
I will probably introduce a configuration of FullMoose is for loading the
top level products
and remove from Moose the dependencies to DSM and SmallDude because these
cycles do not make sense
But it may break the default Moose so I will wait for your point of view.
Stf
On 27/6/14 22:58, stepharo wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hi
Usman found that mooseDSM depends on Moose and that Moose depends on DSM.
This shows a problem with the configurations in the Moose ecosystem.
After thinking about it, there are two kinds of configurations:
- first kind of a configuration should express the dependencies to
systems that are mandatory.
- the second kind represents "Full project" configurations that
express a complete "applications"
with all the subapplications. They do not express that the tool must
all the dependencies to be resolved to work.
For example, MooseAlgos are in Moose even if we do not use MooseAlgos.
Such full project should not be referred too.
=> So we should distinguish such different configurations.
For example Glamour as a UI builder should not depend on Roassal
But Glamour as a full project can depend on Roassal.
Then at the Moose or project level we can decide what to load.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:20 p.m.
On 28/6/14 12:09, Tudor Girba wrote:
Hi,
These problems exist since a long time and we came previously to the
conclusion of introducing ConfigurationOfMooseEngines,
ConfigurationOfFAMIX and ConfigurationOfMooseUI. Nobody had time or
inclination to do it, and we are in the same situation now.
I will do it.
Ideally, the Moose/Moose repository should contain
only the
ConfigurationOfMoose package. Everything else should be moved in a
separate repository with its own configuration.
But, we should keep ConfigurationOfMoose as the top level one because
it is known and there are external users of it. Is that Ok?
Yes
I am over my head in the following 1-2 weeks, but I
can give a hand at
least with reviewing.
Ok
I should work on something more important but more boring but I will a
pass one by one.
Cheers,
Doru
On Sat, Jun 28, 2014 at 11:48 AM, stepharo <stepharo(a)free.fr
<mailto:stepharo@free.fr>> wrote:
So smallDude exhibits the same syndrom
I will probably introduce a configuration of FullMoose is for
loading the top level products
and remove from Moose the dependencies to DSM and SmallDude
because these cycles do not make sense
But it may break the default Moose so I will wait for your point
of view.
Stf
On 27/6/14 22:58, stepharo wrote:
Hi
Usman found that mooseDSM depends on Moose and that Moose
depends on DSM.
This shows a problem with the configurations in the Moose
ecosystem.
After thinking about it, there are two kinds of configurations:
- first kind of a configuration should express the
dependencies to systems that are mandatory.
- the second kind represents "Full project" configurations
that express a complete "applications"
with all the subapplications. They do not express that the
tool must all the dependencies to be resolved to work.
For example, MooseAlgos are in Moose even if we do not use
MooseAlgos.
Such full project should not be referred too.
=> So we should distinguish such different configurations.
For example Glamour as a UI builder should not depend on Roassal
But Glamour as a full project can depend on Roassal.
Then at the Moose or project level we can decide what to load.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3830
days inactive
3831
days old
3 comments
2 participants
participants (2)
-
stepharo -
Tudor Girba