$GS_HOME/alt_bin/products.st :: Provide information on the downloaded GemStone versions

[dalehenrich]

• create basic script class
• translate pharo help text (use devKitCommandLine <command-name> --help to see help text) into gsdevkit_launcher format
• add symbolic link from alt_bin to tonel script class file
• implement command functionality
• (N/A) implement Smalltalk API (some commands will be used internally by other scripts and a Smalltalk API is essential to making this possible)
• add test
• identify the bash scripts that use the command (grep -r devKitCommandLine)
• edit bash scripts to call the new script

[dalehenrich]

The implementation of GsDevKitProductsCommandLineHandler>>installedProducts is pretty straightforward:

however, the #productsHome method is implemented in GsDevKitAbstractCommandLineHandler and depends upon a few other methods that are implemented in GsDevKitAbstractCommandLineHandler. I would think that all of the methods needed by the GsDevKitProductsCommandLineHandler implementation should be implemented in
AbstractGsDevKitProgram ... I'm inclined to implement these supporting methods on demand, since not all of the methods may be used ...

[brunobuzzi]

• Which methods are needed for the API in this script ? (maybe API is not applicable for this script)
• Is there any naming convention for API methods ?
• Which tests are needed ?

[dalehenrich]

* Which methods are needed for the API in this script ? (maybe API is not applicable for this script)

I don't think that API methods are applicable in this particular case ... If you noticed the tODE script copyTonelScriptsToFiletree is simply calling a class side method of GdkL_CopyScriptClasses ... and this is an example where having a Smalltalk API is useful ...

I don't think that #installedProducts is really needed by other scripts ... I've checked senders of that method and it isn't used anywhere else ... and if it were it would be a candidate for inclusion in the class AbstractGsDevKitProgram since the gsdevkitlauncher scripts are not going to be based on a hierarchy of script classes ...

* Is there any naming convention for API methods ?

No ... the naming of the API methods should follow normal Smalltalk conventions ... I have the basic notion that these scripts might contain functionality that would be useful for developers and if so, there should be an easy to use Smalltalk API that does not involve arranging to set options and calling the script invoking machinery to access ... a class-side Smalltalk API is intended to fulfull this need ..

* Which tests are needed ?

At a minimum we need to exercise the range of options for the script class, similar to what is done in the travis-ci tests for the GsDevKit_home bash scripts ... here and here, but I have yet to set up the test framework for the solo extent scripts ... so for now, I would say we can leave the check box for tests unchecked until I've created the framework and at that point I will go through the outstanding scripts and add tests for them myself ... I just need to find the time to add the tests and I've got a couple of other things that are ahead of that work in my queue:)