I think people want all packages by default. This package separation is more to make it possible to replace some parts of PharoCore with the more modern and powerful mechanisms from the refactoring engline, e.g. SystemNavigation -> BrowserEnvironment, (e.g. SystemNavigation -> BrowserEnvironemnt and ChangeRecord -> RefactoryChange).
Lukas 2010/9/25 Mariano Martinez Peck <[email protected]>: > Thanks. And do you have an idea of better groups that the basic ones I have > defined? (look at the end). > I mean, imagine groups of packages that it is likely a user will load only > them, and all together > > > > > spec for: #pharo do: [ > spec repository: 'http://www.squeaksource.com/rb'. > spec > package: 'AST-Core'; > package: 'AST-Tests-Core' with: [ spec requires: 'AST-Core' ]; > > package: 'AST-Semantic' with: [ spec requires: 'AST-Core' ]; > package: 'AST-Tests-Semantic' with: [ spec requires: > 'AST-Semantic' ]; > > package: 'Refactoring-Environment' with: [ spec requires: > 'AST-Core' ]; > package: 'Refactoring-Tests-Environment' with: [ spec requires: > 'Refactoring-Environment' ]; > > package: 'Refactoring-Changes' with: [ spec requires: > 'Refactoring-Environment' ]; > package: 'Refactoring-Tests-Changes' with: [ spec requires: > 'Refactoring-Changes' ]; > > package: 'Refactoring-Core' with: [ spec requires: > 'Refactoring-Changes' ]; > package: 'Refactoring-Tests-Core' with: [ spec requires: > 'Refactoring-Core' ]; > > package: 'Refactoring-Critics' with: [ spec requires: > 'Refactoring-Changes' ]; > package: 'Refactoring-Tests-Critics' with: [ spec requires: > 'Refactoring-Critics' ]; > > package: 'Refactoring-Spelling' with: [ > spec requires: 'Refactoring-Critics'. > spec postLoadDoIt: #postLoadRBSpelling ]; > package: 'Refactoring-Tests-Spelling' with: [ spec requires: > 'Refactoring-Tests-Critics'. ]. > > spec > group: 'default' with: #('Core' ); > group: 'Core' with: #( 'AST-Core' 'AST-Semantic' > 'Refactoring-Environment' 'Refactoring-Changes' 'Refactoring-Core' > 'Refactoring-Critics' 'Refactoring-Spelling' ); > group: 'Tests' with: #( 'AST-Tests-Core' 'AST-Tests-Semantic' > 'Refactoring-Tests-Environment' 'Refactoring-Tests-Changes' > 'Refactoring-Tests-Core' 'Refactoring-Tests-Critics' > 'Refactoring-Tests-Spelling' ); > group: 'Core Tests' with: #('Core' 'Tests' ); > > > > cheers > > mariano > > > On Sat, Sep 25, 2010 at 10:18 PM, Lukas Renggli <[email protected]> wrote: >> >> Refactoring-Spelling depends on Refactoring-Critics. >> Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. >> >> Lukas >> >> 2010/9/25 Mariano Martinez Peck <[email protected]>: >> > >> > >> > 2010/9/5 Lukas Renggli <[email protected]> >> >> >> >> I've split the refactoring model into various packages as outlined in >> >> the previous mail. >> >> >> >> The dependencies between the tests are slightly problematic, but will >> >> eventually be fixed as depicted in red in the attached dependency >> >> graph. It shouldn't matter for loading, so there is no hurry. >> >> >> > >> > Lukas, and what happens with 'Refactoring-Spelling' ?? >> > >> > is this still valid? >> > >> > package: 'Refactoring-Spelling' with: [ >> > spec requires: 'Refactoring-Core'. >> > spec postLoadDoIt: #postLoadRBSpelling ]; >> > package: 'Refactoring-Tests-Spelling' with: [ spec requires: >> > 'Refactoring-Spelling'. ]. >> > >> > >> > thanks >> > >> > mariano >> > >> > >> >> >> >> Thank you for updating the configuration Mariano. Note that >> >> OB-Refactory depends on all the non-test packages. >> >> >> >> Lukas >> >> >> >> On 4 September 2010 14:01, Stéphane Ducasse <[email protected]> >> >> wrote: >> >> > >> >> > On Sep 4, 2010, at 1:08 PM, Lukas Renggli wrote: >> >> > >> >> >>>> I agree that SystemNavigation is ugly, but *a lot* of existing >> >> >>>> code >> >> >>>> depends on it. >> >> >>> >> >> >>> Well if I start forking all the classes that we should fix because >> >> >>> there are used it will be endless. >> >> >>> I was thinking to start also to look at senders and use deprecate. >> >> >>> >> >> >>> do you have a lot of external tools that use it? >> >> >> >> >> >> Yes, all tools use it: >> >> >> >> >> >> Monticello, Paragraph Editor (new and old), OmniBrowser, >> >> >> eCompletion, Refactoring Engine. >> >> >> >> >> >> Now I removed its use from the BrowserEnvironment in the refactoring >> >> >> engine itself. There are still a couple of references though, where >> >> >> people used the wrong abstraction layer when implementing stuff >> >> >> (platform code instead of the abstraction of the refactoring >> >> >> engine). >> >> >> >> >> >>> So what do you suggest? >> >> >>> Separating BrowserEnvironment and its superclass from RB and >> >> >>> starting >> >> >>> to >> >> >>> - check its api >> >> >>> - improve it >> >> >>> - migrate caller of systemNavigation -> BrowserEnvironment >> >> >>> (rename browserEnvironment) >> >> >> >> >> >> Yeah, maybe one step would be to split the refactoring engine into >> >> >> smaller and independent packages: >> >> >> >> >> >> AST-Core (that already is separate) >> >> >> Refactoring-Environment (this is currently part of >> >> > >> >> > yes this would be good so that we can start do the idea with the >> >> > integration related to systemDictionary been a potential leave of the >> >> > composition >> >> > tree we talked last time you visit us. >> >> > >> >> >> Refactoring-Core, but would work independently) >> >> >> Refactoring-Changes (this is currently part of Refactoring-Core, >> >> >> but would work independently) >> >> > >> >> > yes I'm curious to see if/how we could use changes to represent >> >> > changeset. >> >> > >> >> > >> >> >> Refactoring-Refactorings (this is currently part of >> >> >> Refactoring-Core and depends on all of the above) >> >> >> Refactoring-Lint (this is currently part of Refactoring-Core and >> >> >> depends on all of the above) >> >> >> >> >> >> Like this Pharo could integrate Refactoring-Environment and >> >> >> Refactoring-Changes independently. >> >> > >> >> > :) >> >> > >> >> >> I'll see if I can repackage the refactoring browser a bit, might >> >> >> take >> >> >> a while though because the tests are not that nicely separated. >> >> > >> >> > I imagine. >> >> > Now incremental changes is the only way for us :) >> >> >> >> >> >> Lukas >> >> >> >> >> >> -- >> >> >> Lukas Renggli >> >> >> www.lukas-renggli.ch >> >> >> >> >> >> _______________________________________________ >> >> >> Pharo-project mailing list >> >> >> [email protected] >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > [email protected] >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [email protected] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [email protected] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
