> When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose...
What I like is that you have package but you have a kind of modules = object-oriented I would like to have Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests Network-Kernel Network-Kernel-Tests ... So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe > > (Purpose-)Rest > > where > > Purpose = Tests, Examples, .. > Rest = Kernel, Collections, Network, ... > > Note that this is the *package* structure (what you see in MC), not > the class category structure. The latter could be more fine grained at > the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is > structured now). > > The consequence would be that we have packages like > > Kernel > Collections > Tools > ... > Tests-Kernel > Tests-Collections > Tests-Tools > > I'm not convinced that this is the right structure, though, as we end > up with lots of Test-xyz packages. > > As an alternative, I can imagine the package scheme > > Top-Rest > > where we have a very coarse grained Top level. For instance, we would > have the following Top items: > > Kernel > Graphics > Libraries > Tools > Tests > > This means, we would have packages like > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > I'm curious if there are other ideas around. One way or the other, we > need to clean this up. Right now it is a mess. E.g., there is a top > level package MethodFinder, while all other tools are in the Tools > package. INdEeD :) > > > Cheers, > Adrian > > >> >> >> stef >> >> On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote: >> >>> I like the seaside organization >>> >>> Top-(Purpose-)(Platform-)Rest >>> >>> * Seaside-Canvas contains he canvas implementation. >>> * Seaside-Squeak-Canvas contains the platform specific code of >>> the canvas implementation. >>> * Seaside-Examples-Canvas contains example code showing off the >>> canvas implementation. >>> * Seaside-Tests-Canvas contains the tests for the canvas >>> implementation. >>> * Seaside-Tests-Squeak-Canvas contains the platform specific >>> tests of the canvas implementation. >>> >>> On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote: >>> >>>> >>>> On Jan 30, 2009, at 15:33 , Michael Rueger wrote: >>>> >>>>> Stéphane Ducasse wrote: >>>>> >>>>>> so what are the organizations we can use? >>>>>> Ideally I would like to have the test associated with their >>>>>> packages. >>>>>> >>>>>> XXX >>>>>> XXXTests >>>>> >>>>> The problem with that naming scheme is that then the tests would >>>>> always >>>>> be loaded together with their tests because of the simple string >>>>> matching Monticello does. >>>>> Which isn't something you want when doing application/runtime >>>>> builds. >>>>> >>>>> That's why I proposed the Plugin-* and Tests-* naming schemes. >>>> >>>> +1 >>>> >>>> Adrian >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
