Stéphane Ducasse wrote:
> I lukas I see that you group together all the tests and I would prefer
> to have test associate with the package they test.
>
> stef
Traditional PackageInfo users are expected to use the standard
implementation or roll their own, for each package that needs a custom
definition.
MC1.5+ Comes with a version of PackageInfo that has the notion of
package types. Predefined package types that you can make use of through
a simple dot suffix package name.
So Package developers can pick from a list of predetermined package
types which should cover most existing use cases. For example, you could
have different packaging of a package for different platforms, i.e.
Seaside.squeak vs Seaside.vw Seaside.gs vs Seaside.dolphin
Thus rolling your own package definition, is no longer intended for
defining just one package, but rather a class of packages.
Example:
Monticello.impl (implementation)
Monticello.test (tests)
Are two such package names, which are automatically managed by
subclasses of PackageInfo
The PackageInfoImpl class excludes test categories, while the
PackageInfoTests class includes them.
======
testCategoryMatches
^ #('*-Tests-*' '*-Tests')
======
This is so that your tests can live alongside your implementation,
without cluttering up the images with Test categories at the top level.
So if you want to manage the Tests together with the Implementation, add
a package named 'Monticello', this will include all of the classes. If
you want to publish the implementation only, then add a package named
'Monticello.impl' etc etc...
Keith
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
