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 <renggli@gmail.com> wrote:
Refactoring-Spelling depends on Refactoring-Critics.
Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics.

Lukas

2010/9/25 Mariano Martinez Peck <marianopeck@gmail.com>:
>
>
> 2010/9/5 Lukas Renggli <renggli@gmail.com>
>>
>> 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 <stephane.ducasse@inria.fr>
>> 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
>> >> Pharo-project@lists.gforge.inria.fr
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > Pharo-project@lists.gforge.inria.fr
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project