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.
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@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
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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."
+ 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@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
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
+1
On Jul 3, 2016, at 9:09 AM, stepharo stepharo@free.fr wrote:
- 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@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
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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.
Hi,
I am the maintainer of FAMIX.
Doru
On Jul 3, 2016, at 12:20 PM, Cyril Ferlicot D. cyril.ferlicot@gmail.com wrote:
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
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"When people care, great things can happen."
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
Hi,
On Jul 3, 2016, at 12:47 PM, Stephan Eggermont stephan@stack.nl wrote:
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
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
Stephan
Moose-dev mailing list Moose-dev@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."
Verstuurd vanaf mijn iPad
Op 3 jul. 2016 om 12:56 heeft Tudor Girba tudor@tudorgirba.com het volgende geschreven:
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?
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
-
Alexandre Bergel -
Cyril Ferlicot D. -
Cyril Ferlicot Delbecque
-
Stephan Eggermont -
stepharo -
Tudor Girba