Checkout a specific version from GitHub

taking https://github.com/openmrs/openmrs-module-referenceapplication as an example , there have been various releases of this module.

If i want to work with say 2.2 (latest in the repo is 2.3-SNAPSHOT) how would i switch to this specific release branch

@judy you can checkout the tag.

Let’s say you configured openmrs reference application as the upstream. Then you can do follow.

git fetch upstream (it will checkout the tags) git checkout -b "referenceapplication-2.2" referenceapplication-2.2 (will checkout the 2,2 to local branch)

Thanks, Harsha

1 Like

When doing a checkout of a a non-SNAPSHOT version (for example, a release tag), make sure to take care of your maven local repository.

Avoid doing a ‘mvn install’ of this tag, or any modification of it. Doing a ‘mvn package’ is fine, but ‘mvn install’ will override the files in ~/.m2/repository - and maven will assume non-SNAPSHOTs versions are immutable and should never be downloaded again.

If you want to work on a code, you can either set the version to a snapshot (e.g. ‘mvn versions:set -DnewVersion=2.9.9-SNAPSHOT’) or remove ~/.m2/repository/org/openmrs after.

2 Likes

Wouldn’t mvn clean install be able to do the job?

No.

‘mvn clean’ will delete the /target directory of your modules, but it won’t clean the artifacts generated by previous ‘mvn install’ (the ones in ~/.m2/repository). ‘clean’ will remove artifacts generated up to ‘package’, maybe even ‘verify’ if you haven’t used weird configuration for your maven plugins.

If you ran ‘mvn install’ in a non-SNAPSHOT, you need to delete manually from ~/.m2/repository.

(To be really really fair, you could use something like ‘mvn build-helper:remove-project-artifact -Dbuildhelper.removeAll=false’, but it’s a little bit too complicated to my taste).

1 Like

I think you meant to set -Dbuildhelper.removeAll=true instead, right? @cintiadr