This is a good point. We could find a way to programmatically enable/disable the components just for the test run:
./ant -Denable-all=true clean-all load-demo run-tests but this is just an idea; we could figure out the best way to go. Jacopo On Nov 27, 2014, at 7:14 PM, Adrian Crum <adrian.c...@sandglass-software.com> wrote: > Be aware that disabling a component does two things: > > 1. Speeds up unit tests because the disabled component is excluded from them. > 2. Increases the chance of regressions because the disabled component is not > being tested. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >> >> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> >> wrote: >> >>> Yes, so we need to define which are those components. So 3 points, which >>> should be discussed separately it seems, not sure of the order yet but >>> probably this one >>> 1) Components to move to Attic. They will be freezed but still available in >>> this state in Attic (in other words slowly dying) >>> 2) Components to disable. They will be maintained, but OOTB will not >>> interfere with other components (applications or other specialpurpose) >>> 3) Components to keep enabled. They must be maintained and have no >>> interactions with other components >> >> Components enabled and disabled must be maintained in the same way: it is >> not that a group is more important than the other. >> Also, disabling a component doesn't mean that it will not go in a release: >> we could have disabled components in releases and enabled components >> excluded from a release or vice versa. >> >>> >>> For the point 2 we need to clarify if it could applies to trunk also. I'd >>> now tend to avoid differences between trunk and branch releases, at the >>> functionality or other levels. >> >> I agree that the same settings should be maintained in the trunk and in the >> release branches. >> >> Jacopo >>
