Hi Torsten,
Nice to see that we also improve at this front again!
The goals make sense. When I recategorized all the tests that were mixed with
the code to the global "Tests" package, I followed your first goal ("separate
tests and code"). The main objective was to be able to make tests unloadable
for the #cleanUpForProduction stripping of an image. So I think that splitting
up the monolithic Tests package is a good next step because we gain modularity
as single packages can be moved out/in of core including their tests (which is
currently not possible since the tests can only be loaded/unloaded at once).
I've seen your Regex refactoring [3254], which splits the code into three
separate Monticello packages:
Regex-Core
Regex-Tests
Regex-Examples
That is, there is no package "Regex" anymore. Looks good (also the removing of
the 'VB-' prefix was long overdue).
I don't think its a big drawback, but just because it was not mentioned before:
the consequence is that we'll end up with more than twice as many Monticello
packages in the system.
Cheers,
Adrian
On Nov 12, 2010, at 15:17 , Torsten Bergmann wrote:
> Hi,
>
> after an IRC discussion with Alexandre and Stef yesterday we agreed
> that it would be good to start working on cleaning up/organizing
> the packages and get better structure into the system.
>
> Goals:
> - seperate tests, examples, help, ... from code in distinguishable packages
> - but also have tests, examples, help packages closer to the code
> - be able to have cleaned up and reproducable package dependencies
> in the future
> - provide quality checks to see if packages conform to cleanup rules
>
> The abusing of class categories for packaging will not be
> replaced with a real packaging system in the near future but
> that shouldnt be a problem so far.
>
> I dont know where we will end up, how much time we can devote and
> what problems we may find but if we wont try we will never find
> out ...
>
> Proposal:
> =========
> 1. we should have an informal repackaging task force and I would
> like to invite the following people since they already worked
> on repackaging/loading/unloading before:
>
> Adrian, Pavel, Stef and any other who wants to help
>
> 2. since we have to use a naming convention we would like to start
> with the one from Seaside:
> http://code.google.com/p/seaside/wiki/PackageNaming
>
> since it is already used and may help us here. Lets see how
> this turns out.
>
> 3. we should start with simple packages and clean them up
>
> 4. well formed packages also means we can run quality checks
> per package. Maybe the hudson infrastructure can help us
> here to tell if already cleaned up packages continue to be
> clean.
>
> To wet your appetite a little bit I worked in the announcement
> framework packages.
>
> See http://code.google.com/p/pharo/issues/detail?id=3252
>
> As a goodie we have a new help book documenting the framework a little bit.
>
> Feel free to try the changesets in a recent 1.2 image and comment.
> I hope this doesnt start a flamewar on the correct package naming
> (which we can always change) but help to improve the quality of
> each package one by one ...
>
> Thx
> T.
>
> --
> GRATIS! Movie-FLAT mit über 300 Videos.
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
>
