2 May
2016
2 May
'16
10:58 a.m.
Hi,
As we talked in another thread I tried to look at the configuration of
Moose to be able to load Famix without every Moose tool (Glamour, Roassal…).
As Stephan said, since Famix is an inactive project for now groups are
enough to manage Famix. So I made some groups to be able to get only
Famix and the moose packages needed by famix.
There is 3 groups:
- Famix (Which is only the two following groups together)
- Famix-Without-Test
- Famix-Tests
So if you have a Tool that use Famix but not Moose tools you can had
this dependency:
spec project: 'Famix' with: [
spec
className: #ConfigurationOfMoose;
versionString: #development;
loads: #( #'Famix' );
repository: 'http://smalltalkhub.com/mc/Moose/Moose/main' ].
The only problem during the loading is about MalGraphBuilderStrategy
that is missing, but this was already the case in Moose.
I hope this will help you.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
2 May
2 May
2:05 p.m.
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the ConfigurationOfMoose.
I know some people have a different, but groups are difficult to manage, and in our case,
we certainly need explicit artifacts that should be modeled with configurations.
Cheers,
Doru
On May 2, 2016, at 10:58 AM, Cyril Ferlicot Delbecque
<cyril.ferlicot(a)gmail.com> wrote:
Hi,
As we talked in another thread I tried to look at the configuration of
Moose to be able to load Famix without every Moose tool (Glamour, Roassal…).
As Stephan said, since Famix is an inactive project for now groups are
enough to manage Famix. So I made some groups to be able to get only
Famix and the moose packages needed by famix.
There is 3 groups:
- Famix (Which is only the two following groups together)
- Famix-Without-Test
- Famix-Tests
So if you have a Tool that use Famix but not Moose tools you can had
this dependency:
spec project: 'Famix' with: [
spec
className: #ConfigurationOfMoose;
versionString: #development;
loads: #( #'Famix' );
repository: 'http://smalltalkhub.com/mc/Moose/Moose/main' ].
The only problem during the loading is about MalGraphBuilderStrategy
that is missing, but this was already the case in Moose.
I hope this will help you.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"It's not how it is, it is how we see it."
3 Jul
3 Jul
9:09 a.m.
+ 1
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the
ConfigurationOfMoose. I know some people have a different, but groups are difficult to
manage, and in our case, we certainly need explicit artifacts that should be modeled with
configurations.
Cheers,
Doru
On May 2, 2016, at 10:58 AM, Cyril Ferlicot
Delbecque <cyril.ferlicot(a)gmail.com> wrote:
Hi,
As we talked in another thread I tried to look at the configuration of
Moose to be able to load Famix without every Moose tool (Glamour, Roassal…).
As Stephan said, since Famix is an inactive project for now groups are
enough to manage Famix. So I made some groups to be able to get only
Famix and the moose packages needed by famix.
There is 3 groups:
- Famix (Which is only the two following groups together)
- Famix-Without-Test
- Famix-Tests
So if you have a Tool that use Famix but not Moose tools you can had
this dependency:
spec project: 'Famix' with: [
spec
className: #ConfigurationOfMoose;
versionString: #development;
loads: #( #'Famix' );
repository: 'http://smalltalkhub.com/mc/Moose/Moose/main' ].
The only problem during the loading is about MalGraphBuilderStrategy
that is missing, but this was already the case in Moose.
I hope this will help you.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"It's not how it is, it is how we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
11:44 a.m.
+1
On Jul 3, 2016, at 9:09 AM, stepharo
<stepharo(a)free.fr> wrote:
+ 1
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the
ConfigurationOfMoose. I know some people have a different, but groups are difficult to
manage, and in our case, we certainly need explicit artifacts that should be modeled with
configurations.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On May 2, 2016, at 10:58 AM, Cyril Ferlicot
Delbecque <cyril.ferlicot(a)gmail.com> wrote:
Hi,
As we talked in another thread I tried to look at the configuration of
Moose to be able to load Famix without every Moose tool (Glamour, Roassal…).
As Stephan said, since Famix is an inactive project for now groups are
enough to manage Famix. So I made some groups to be able to get only
Famix and the moose packages needed by famix.
There is 3 groups:
- Famix (Which is only the two following groups together)
- Famix-Without-Test
- Famix-Tests
So if you have a Tool that use Famix but not Moose tools you can had
this dependency:
spec project: 'Famix' with: [
spec
className: #ConfigurationOfMoose;
versionString: #development;
loads: #( #'Famix' );
repository: 'http://smalltalkhub.com/mc/Moose/Moose/main' ].
The only problem during the loading is about MalGraphBuilderStrategy
that is missing, but this was already the case in Moose.
I hope this will help you.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"It's not how it is, it is how we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
12:20 p.m.
Le 02/05/2016 à 14:05, Tudor Girba a écrit :
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the
ConfigurationOfMoose. I know some people have a different, but groups are difficult to
manage, and in our case, we certainly need explicit artifacts that should be modeled with
configurations.
Cheers,
Doru
Hi,
If I choose groups it's because there is no maintainer of Famix. If we
create a configurationOfFamix nobody will maintain it through the next
versions of Pharo/Moose. I can take the time to make Famix loadable
without Moose now, but I will not have the time to maintain it in the
future.
I think it should be promoted as Configuration if someone work on Famix
and maintain it.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
12:25 p.m.
Hi,
I am the maintainer of FAMIX.
Doru
On Jul 3, 2016, at 12:20 PM, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> wrote:
Le 02/05/2016 à 14:05, Tudor Girba a écrit :
--
www.tudorgirba.com
www.feenk.com
"When people care, great things can happen."
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the
ConfigurationOfMoose. I know some people have a different, but groups are difficult to
manage, and in our case, we certainly need explicit artifacts that should be modeled with
configurations.
Cheers,
Doru
Hi,
If I choose groups it's because there is no maintainer of Famix. If we
create a configurationOfFamix nobody will maintain it through the next
versions of Pharo/Moose. I can take the time to make Famix loadable
without Moose now, but I will not have the time to maintain it in the
future.
I think it should be promoted as Configuration if someone work on Famix
and maintain it.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
12:47 p.m.
On 02-05-16 14:05, Tudor Girba wrote:
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the
ConfigurationOfMoose. I know some people have a different, but groups are difficult to
manage, and in our case, we certainly need explicit artifacts that should be modeled with
configurations.
The problem is that nothing we have now provides an alternative for groups
and the situation with many configurations and no groups has shown to be
a lot worse. We need first-class groups
Stephan
12:56 p.m.
Hi,
On Jul 3, 2016, at 12:47 PM, Stephan Eggermont
<stephan(a)stack.nl> wrote:
On 02-05-16 14:05, Tudor Girba wrote:
I still do not see where this was proven so. We manage the GT configuration like this
since quite some time and it worked until now better than with groups.
Could you be more specific?
Cheers,
Doru
Hi,
Thanks.
However, please let’s redo this. I do not want to have groups in the
ConfigurationOfMoose. I know some people have a different, but groups are difficult to
manage, and in our case, we certainly need explicit artifacts that should be modeled with
configurations.
The problem is that nothing we have now provides an alternative for groups
and the situation with many configurations and no groups has shown to be
a lot worse. We need first-class groups Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Every thing should have the right to be different."
4:41 p.m.
Verstuurd vanaf mijn iPad
Op 3 jul. 2016 om 12:56 heeft Tudor Girba
<tudor(a)tudorgirba.com> het volgende geschreven:
Pharo developers no longer dare changing GT configurations sounds like
a major issue to me. The ripple effect is also very visible, and for users
of the configurations it is not clear where they should depend on
Stephan
I still do not see where this was proven so. We
manage the GT configuration like this since quite some time and it worked until now better
than with groups.
Could you be more specific?
2859
days inactive
2921
days old
8 comments
6 participants
participants (6)
-
Alexandre Bergel -
Cyril Ferlicot D. -
Cyril Ferlicot Delbecque
-
Stephan Eggermont -
stepharo -
Tudor Girba