Provided packages from Metacello project configuration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Provided packages from Metacello project configuration

Panu Suominen-3
This is probably wrong mailing list for this question...
Is there a way to define what categories/packages/classes are provided
by the given configuration? For example

ConfigurationOfXXX project latestVersion providedPackages

This would not include the packages that are required by the
project and are actually provided by other configurations/projects.

If there is a way to produce this kind of package list
it would help implementing CI-testing. Testing script would
not have to explicitly list what packages to test but could refer
to the project definition. Currently one has to alter
the testing script every time the packages are changed.
With this kind of information one could implement project
CI-builds with something like this:
whatToBuild := ConfigurationOfXXX project lastVersion.
whatToBuild load.
HDTestReport runPackages: whatToBuild providedPackages.
HDLintReport runPackages: whatToBuild providedPackages.

And then it would be easy to build custom Job plugin to Jenkins that
would simply ask about the name and the location of ConfigurationOfXXX.

--
Panu

Reply | Threaded
Open this post in threaded view
|

Re: Provided packages from Metacello project configuration

Mariano Martinez Peck


On Fri, Feb 25, 2011 at 8:48 AM, Panu Suominen <[hidden email]> wrote:
This is probably wrong mailing list for this question...

I cc'ed metacello and dale :)
 
Is there a way to define what categories/packages/classes are provided
by the given configuration? For example

ConfigurationOfXXX project latestVersion providedPackages

This would not include the packages that are required by the
project and are actually provided by other configurations/projects.

If there is a way to produce this kind of package list
it would help implementing CI-testing. Testing script would
not have to explicitly list what packages to test but could refer
to the project definition. Currently one has to alter
the testing script every time the packages are changed.
With this kind of information one could implement project
CI-builds with something like this:
whatToBuild := ConfigurationOfXXX project lastVersion.
whatToBuild load.
HDTestReport runPackages: whatToBuild providedPackages.
HDLintReport runPackages: whatToBuild providedPackages.

And then it would be easy to build custom Job plugin to Jenkins that
would simply ask about the name and the location of ConfigurationOfXXX.

--
Panu