Hi Stef, On Feb 7, 2009, at 14:40 , Stéphane Ducasse wrote:
I would like to use the seaside convention so is it ok for you? Then I will proceed and rename eveyrthing.
What would be the resulting packages? I.e., how would you map the Top and Rest parts to the existing structure we have? I think that decision should be well considered as it has quite some impact (e.g., on the number of class categories and packages). I discussed with Lukas about the Seaside packaging scheme documented at http://code.google.com/p/seaside/wiki/PackageNaming The conclusion was that for Pharo the top level and the Platform level may not make much sense and could be left out. Then we would have a scheme like (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. 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 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project