Refactoring InstallFromWorkspace.cobra

[fraya]

Making a package for Cobra, I have read InstallFromWorkspace.cobra. This file makes build and installation in one phase and it superuser mode. It could be easier for people to create more packages in Unix, if this phases can be divided in (maybe configure), build and install. Because the creation of the package in faked in a build directory, superuser privileges are not needed. Some changes could be:

• Enable or disabled the check of superuser privileges
• Destination directory can be changed writing a file named 'install-directory.text' but we can pass an argument instead.
• An optional parameter to where install dll's
• A parameter for destination directory of documentation

Note that everything can be done patching code and with shell commands, so the benefits are in making easier the creation of packages.

I think that InstallFromWorkspace.cobra need some refactoring https://en.wikipedia.org/wiki/Code_refactoring, before making any change. This are some issues:

• The code mix installation in Windows and Unix, saying 'if .isRunningOnUnix do this if .isRunningOnWindows do that' in different places. Is better to "tell, don't ask", separating in two classes UnixInstaller and WindowsInstaller the process and moving common methods to a base class Installer, that acts as a template for the installation.
• The installation use msbuild or xbuild and gacutil. Part of the code is similar, locating the path of the tools in the filesystem and running a command when is found. This can be abstracted in a CommandLineTool class (well, I see some of its methods in Process or ProcessOutput).
• A lot of information about the platform is shown in the installation, this can be reusable in a Platform class, which is a facade for different classes Environment, Assembly, CobraCore.

This are my ideas to refactor the code, before make any changes. The cons are: new bugs?, understand the new code. The benefits are: easier modification in the future, reusable (maybe) abstractions.

I attach an UML diagram and the refactored code (only tested in Linux). What do you think?

[Charles]

Looks good to me.

I think the cons of "new bugs" is minor. It's a fairly small project and we can definitely test the bugs out of it.

The only thing I would add is that we also need to formalize the list of test cases. So far we've just been hacking things up and relying on reports from the field to shake things out.

[fraya]

Ok, tell me

[Charles]

Well at a minimum we could create a list of setups and since no one here is going to maintain a test lab, we could provide one or more "owners" of the test case who agrees to run it when required (which would be changes to the installer or the creation of candidate releases). Here is the start:

Mono 4.0.0, OS X 10.9, 64-bit, Charles Esterbrook

And then looking at our list, we could see where it's lacking and ask for volunteers to help out. I suppose the list could be on the wiki.

Make sense?

[nerdzero]

Code: Select all

Cobra svn:3117 (post 0.9.6) / 2015-04-28 on Mono 4.0.1 CLR v4.0.30319 on Ubuntu 14.04.2 LTS

nerdzero, reporting for duty.

[fraya]

I am using OpenSuse stable version 13.2. Mono version is 3.8.0 and in OpenSuse rolling distro, mono version is 3.12.1. Version 4.0.0 can be installed by Yast 1-click install from mono-project, but some dependencies are broken. It is important to use 4.0.0?

[Charles]

No, I just picked 4.0.0 because I noticed it was available for download for Mac. I haven't even installed it yet.

And from a testing perspective, it's useful to have some different Mono versions including 3.X.