Get project version from git

[inodb]

Normally for each new release we have to create a PR just to update the version in the pom. Then afterwards we get conflicts when we try n merge master branch back into feature branches. Imagine updating master branch, now you will get conflicts in release-x branch and rc branch.

Maven should not keep track of the versioning at all, this is already managed by git. This maven-external-version plugin determines the version using a bash script, version.sh. This tries to get the version from git. If git is not available at compile time, one can also supply the version by setting an env variable PROJECT_VERSION instead.

I slightly modified maven-external-version plugin, so we can download that dependency from jitpack.

Unfortunately ${project.version} doesn't work in plugins, so we can't show the
version name in the actual war file name anymore (this is a known issue:
bdemers/maven-external-version#7). Seems like an ok
trade-off though

Another issue I ran into was that integration-test didn't work anymore without running install first. Not sure if this is a reason for concern, but just wanted to notify @ersinciftci . There might be a way to update the plugin to avoid having to do this, but maybe it's not that big of a deal.

[sheridancbio]

looks good, although I recommend a (manual) test where connected changes in two modules in two different changesets still are able to find each other:

1. create new branch
2. modify some service layer function to take one additional argument .. commit
3. modify related web layer handlers to call the modified service layer function with additional arg .. commit
4. try to compile and see if tests pass

[sheridancbio]

If git describe always goes back to a tag, does it mean that portal dependencies can only be brought in from a tagged commit that is pushed to the cbioportal github repo? If a single PR makes changes in both the service and web layer (like changing the service interface), will the "new" web layer be able to bring in the "new" service layer even if a tag has not been created (in a pr to rc, for instance)? Maybe the extra info after the tag is enough to provide the additional path since the tag (the "dirty" part I guess?)

% git describe --tags --always --dirty

v1.18.0-120-g05c7ad6-dirty

[inodb]

@sheridancbio Portal dependencies can be brought in locally or remotely. It doesn't need to be tagged/committed in the github repo. Maven continues to function in the same way, so if u compile something locally the artifacts will end up in your ~/.m2 folder and you can include them in another project as a dependency.

[sheridancbio]

sounds good. I was mainly thinking about dependencies between the modules within cbioportal, but packaging the cbioportal code into other codebases is also needed.

[inodb]

I found another issue when including cbioportal through jitpack as a dependency as we do with e.g. genome-nexus-annotation-pipeline. The scripts pom would not get the updated parent project's version. Not generating a new pom by the shaded maven plugin solved that issue

[fedde-s]

@inodb: what do you mean? Are you no longer generating the scripts JAR? It's required for all data loading.

[fedde-s]

So if that's the case, we have to revert the merge right away.