Hi Cyril,
On Jul 20, 2016, at 3:11 PM, Cyril Ferlicot D. cyril.ferlicot@gmail.com wrote:
Le 20/07/2016 à 07:12, Tudor Girba a écrit :
Hi Cyril,
Thanks a lot for the detailed email.
Please do not apologize because there is really nothing to apologize for. Moose is an open project that welcomes any amount of effort and nobody should feel bad because the effort did not meet whatever standard.
It’s better to look at the issue from a more positive perspective and describe the problem as you face it (like you did here). Emails like these are the prerequisite for being able to address your points at all.
If I understand correctly, an important problem is to be able to reuse parts independently. We can address that one, so let’s work on this and finalize ConfigurationOfFamix. What do you say?
Hi,
I think this is important to be able to reuse parts independently if you want people building tools in top of Moose and if you want Moose to be used in business.
Moose is big and I think most companies that want to work with Moose will start to use all Moose to start, but later they will not need everything. I think it's good to let users takes the part they needs. If you make your own browsers, you don't need Glamour/Roassal/Merlin. If you don't care about duplication then you don't have to be forced to get Dude.
Another use case is: Imagine you don't want to slow you tool during the generation of a MSE. You can have an image 1 with Moose that will call an image 2 with the parser. Then the image 2 don't need Moose but only the parser and FAMIX.
As I said, at Synectique we don't bring all moose anymore but only the parts we need. And on our Jenkins we can see a lot of "Undeclared" because everything depend on everything.
It's hard to clean it but if we do it slowly it will not impact Moose and it will make thing easier for people wanted to work with it. I think that Moose should be a sort of "Meta configuration" and all the part could be load independently. We could have a CI job for each build to check that they do not use undeclared classes/variables anymore. (For example now, if you want only smalldude, you need Moose-Tests-Core and Moose tests core depend on half the packages of Moose, at least).
For a platform that promote good modular and good code, this is bad publicity. :)
Everyone agrees that we need to create better configurations, and there were multiple calls for help in the past but until now nobody answered :).
But, I am happy that you want to invest time in this.
I agree that the first step is to get a good ConfigurationOfFame and ConfigurationOfFamix.
For the ConfigurationOfFamix I think the steps are:
- Clean cyclic dependencies
Yes.
- Cleans the tests packages of FAMIX that are still in the Moose
configuration since they depend on Moose
I do not understand this part. We should rename the importer and test packages to not have Moose in the name, but Famix.
- Remove all the problem we see in Jenkins logs:
https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console
Ok.
- I also think that Famix should not have the importers directly and we
should have a ConfigurationOfFamixImporters.
Agreed.
Doru
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- 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
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."