Hi, Indeed. But, the issue is deeper: it is because we do not have an explicit architecture that people bundle together code at multiple levels. So, we need to fix our definition of the architecture first (see the mail entitled "major repackaging planned"). Now, let's take SmallDude. It actually has two components: a) the duplication computation mechanism b) the integration in FAMIX a) is an algorithm engine that should be reusable without FAMIX. b) is a meta-model extension. If they would be packaged separately, only b) should need dependencies to the core of Moose. Furthermore, if we split the overall Moose into multiple components along the idea of engines, we will actually have b) only depend on the ConfigurationOfFamix. and ConfigurationOfMoose will simply put all these together. The only problem is that if we do that, we can get in an even bigger mess due to the amount of Configurations. So, that is why I want to see what can be done about this part. In any case, at the very least we will split the current configuration into ConfigurationOfMooseCore (on which others like SmallDude can depend) and ConfigurationOfMoose. Cheers, Doru On 20 Oct 2011, at 00:19, Alexandre Bergel wrote: -- www.tudorgirba.com "Quality cannot be an afterthought."