What I'll share below is a sample of what I think will be used by most of the
projects out there. Metacello still supports (optional) groups, conditional
specifications and required projects, but they only need to be specified when
needed.
The following two methods illustrate what it takes to define version 0.1 and 0.2 of Metacello itself (version 0.2 has been fabricated):
version01
<version: '0.1' attribute: #'common' >
^self versionSpec
description: 'Version 0.1 - sample MetacellProject for Metacello';
packages:
(self packagesSpec
add: 'Metacello-Core-dkh.172';
add: 'Metacello-MC-dkh.20' requires: 'Metacello-Core';
add: 'Metacello-Samples-dkh.17' requires: 'Metacello-MC';
add: 'Metacello-Tests-dkh.179' requires: 'Metacello-Samples'
yourself);
repositories:
(self repositoriesSpec
add: 'http://seaside.gemstone.com/ss/metacello' type: 'http';
yourself);
yourself
version02
<version: '0.2' attribute: #'common' >
^self version01
description: 'Version 0.2 - fake sample of new version';
packages:
(self packagesSpec
add: 'Metacello-Core-dkh.173';
add: 'Metacello-MC-dkh.21' requires: 'Metacello-Core';
add: 'Metacello-Samples-dkh.35' requires: 'Metacello-MC';
add: 'Metacello-Tests-dkh.185' requires: 'Metacello-Samples'
yourself);
yourself
For a version in a basic project, all that needs to be specified is
- a description of the version
- a list of the packages needed by the project (including the names of the
packages required by a package)
- a list of repositories from which the packages are to be loaded
When defining a second version in a project, it is only necessary to specify the
things that have changed. In the above example that means listing the new package
versions and a new description (note that #version02 is based on #version01). All
of the other aspects of version01 are retained and don't need to be specified again.
It is even possible to specify only the changed or deleted packages using #merge:
and #remove:.
I think that simple projects can be simply defined, but when you have a more complex
project, I think that you can still express the complexities with Metacello without
things getting too complex.
If you want to look at a range of samples, then load the following packages from
http://seaside.gemstone.com/ss/metacello:
Metacello-Core-dkh.172
Metacello-MC-dkh.20
Metacello-Samples-dkh.17
Included in the samples are:
MetacelloExampleProject - a series of 4 versions including a required project
MondrianSampleMetacelloProject - the Mondrian example defined using conditional
version specs
OBSampleMetacelloProject - an OmniBrowser sample project that is used by Mondrian
WA28SampleMetacelloProject - a sample project for the 4 versions of Seaside2.8
WA29SampleMetacelloProject - a sample project for Seaside2.9. Version 2.9.0-alpha4
is intended to illustrate a version that is being used for development - it
includes conditional specs for the GemStone packages
WASampleMetacelloProject - is an example of unifying Seaside2.8 and Seasid2.9.
I do not have load/unload/update implemented (that's where I'm headed next), so for now you can just read the code.
The samples have been pared down to what I think of as the bare minimum, so they
don't illustrate all of the things that can be done with Metacello. If you want to
look at some samples that do #merge: and #remove: in addition to #add: then you'll
want to load Metacello-Tests-dkh.179 and look at the subclasses of MetacelloProject
or peruse the tests themselves to see the full range of options (there are 3
failing tests at the moment:)
Let me know what you think.
Dale