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
