Problems with installing repositories

[krkeene]

Hello,

I have a problem using the ADL workbench (2.0.5). If I want to install the openEHR-reference repository, the install link doesn't work. The only way is to click on the install link and then click 'VCS refresh'. That worked one time, and now it won't again.

Furthermore, I can't manage to open almost all ADL 1.4 archetypes on my computer. It gives an error that looks the same as in issue-1 (#1). I don't know if this is related to the malfunction of the repository installer.

I'm using windows 8(.1)

Kevin

[wolandscat]

Hi, can you provide a) the build version (Help>About) and b) what kind of Git installation you have on that machine.
thanks,

• thomas

[fraynie]

Hi,
I have a similar problem. I have just installed ADL Workbench (v2.0.5.2717) and am unable to obtain archetypes via the Install link in the 'Repositories and contained libraries' window - it simply does not work and does not display any sort of error message.

No success via the VCS Refresh button either.

My Git client is GitHub Desktop (v3.1.1.4).

Thanks, Mark

[wolandscat]

Please download one of the 'latest builds' from the tool home page. The 64-bit Windows build (2.0.6.2847) is the latest.

[fraynie]

Thanks - I've installed 2.0.5.2847 unfortunately the Install link is still not working.
Successfully able to configure AOM Profiles and RM Schemas
Mark

[wolandscat]

I assume you have a recent version of Windows, and an install of GitHub Desktop but no other git tools. I just installed GHD on a test machine, and the problem is that 'where git' returns nothing.

I've done some looking around and it appears that GitHub Desktop is installed into /Users//appdata/local/..., with git.exe in a .../cmd sub-directory, and no changes to the %PATH%. Very unfriendly...

ADL WB should display a dialog saying 'no git.exe found on system' or similar. I'll have to determine why it is not doing that.

However, to fix the main problem, I'm not sure of the best approach. I can add some logic to do a 'where /R /Users//appdata/local/ git.exe', which does work, but turns up 3 different git.exes in that location after a new install of GH desktop. I suspect that even adding one of those to the PATH may not work because most of the binaries appear to be in /bin not /cmd, where git.exe is.

The current approach on Windows so far was to look for a) git under cygwin and b) git installed in a normal location that is on the path, e.g. GitExtensions.

In the short term, you could make things work by adding the .../cmd directory mentioned above to the path (you could even do that just within a .bat script that you launch AWB with), but of course that's not a general solution.

But it would be interesting to know the result if you could do this anyway as a test (I would do it, but all my Windows machines have cygwin and/or GitExtensions on them). This would help me work out the permanent fix (or you may have other suggestions as well).

[wolandscat]

It appears that a lot of other people are very unhappy about this as well - see comments here. It appears they have no intention of fixing it, and in any case, the real problem is the Squirrel project ideology on installation directory.

[fraynie]

Hi Thomas,

I managed to get it working against GitHub Desktop simply by adding the git.exe location to the Path system variable...

The GitHub for Windows installation placed the git.exe here: c:\Users\AppData\Local\GitHub\PortableGit_d76a6a98c9315933ec4927243517bc09e9b731a0\cmd. Once I added this location to PATH it all worked.

A much easier fix was to simply install Git for Windows - the installation process placed git.exe in a much more obvious directory (C:\Program Files\Git\cmd) and helpfully added the location into the PATH system variable.

Interestingly, I did see the 'External tool git not found on local system...' dialog - but I only saw this when I had one or more archetype repositories configured. Once I removed my configured repository from the list via the 'forget' option and deleted all references to git.exe form PATH (i.e. once I was back to square one with all three default repositories to install) the message did not appear.

Thanks for your help,

Mark

[wolandscat]

I have moved this dialog to earlier in the startup sequence, and also included a recommendation to download Git from git-scm.com, which i think is the easiest thing to do, if git is not found. Doing so doesn't preclude the user also downloading GitExtensions or Github Desktop client or whatever else on a Mac. I think that is the best practical approach for now, to avoid getting embroiled in arguments with the Github desktop people...

[pcdewolff]

Just this simple line of text would be great to add: a working git install is needed to run this #&$^#& tool. But that seems to be hard as 5 years later you can install the tool and only on a forum you find out you need additional tools..