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. :)
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 - Cleans the tests packages of FAMIX that are still in the Moose configuration since they depend on Moose - Remove all the problem we see in Jenkins logs: https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console - I also think that Famix should not have the importers directly and we should have a ConfigurationOfFamixImporters.
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