Changes required to update HTSJDK Version

[bbimber]

Like we discussed on the LK issue board, I'd like to increment the HTSJDK version. These changes are associated with this. Note: this will probably fail the built, since it also requires gradle.properties to have the HTSJDK version incremented, and that file lives in SVN. I dont know how to coordinate this shift with github. I can check in that SVN change to trunk at the same time this PR is merged.

[bbimber]

@labkey-jeckels one thing i realized: while we probably dont need code changes in the o'connor modules, they might need jars.txt updated to reflect this. do you have thoughts on how to execute that? also, has LK considered trying to make jars.txt more automatic? especially with versions managed in the core gradle files, manually updating jars.txt files seems like it should not be necessary.

finally: to be clear, i am deliberately committing dependencies.txt in this PR. i find it useful to have these versioned, so it's a warning is gradle has updated JAR versions, since it tells me I need to manually edit jars.txt.

[labkey-tchad]

I pushed this to our fork to verify. I manually queued a build and tests with -PhtsjdkVersion=2.21.3. Just a single new test failure.
Also, it appears that picard is pulling in a different version of apache commons: https://teamcity.labkey.org/viewLog.html?tab=buildLog&logTab=tree&expand=all&buildId=992803&filter=all&_focus=28892

[bbimber]

@labkey-tchad thanks, that's very helpful. regarding the commons-collections4 discrepancy, would something like this be a way to solve this:

external("com.github.broadinstitute:picard:2.22.4") {
exclude group: "javax.servlet", module: "servlet-api"
exclude group: "org.apache.commons", module: "commons-collections4"
}

or is there a force version syntax I could try to use?

[bbimber]

@labkey-tchad OK, I think both are addressed. will tests automatically restart because of my commits?

[bbimber]

@labkey-tchad @labkey-jeckels Tests seem to be passing now:

https://teamcity.labkey.org/buildConfiguration/bt310/993597

[labkey-tchad]

Dependency check looks good too: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_VerifyDependencies/993466?buildTab=overview

[labkey-jeckels]

I opened the PR to bump the O'Connor lab module's reference.

[bbimber]

@labkey-tchad one question. the only option i have is squash and merge. i dont want to do this, right?

[bbimber]

actually I'm not thinking. this is probably fine. i was in the mindset of merges from the discvr branch into develop...

[labkey-jeckels]

@bbimber in terms of your comment on auto-updating jars.txt, while I see the value in that, is there a reason that you're wanting to manually update dependencies.txt but not jars.txt? If your intent is to manually keep tabs on the versions, why not do it via the file that's not already auto-generated? I'm probably missing something in terms of when mismatches get flagged or something along those lines.

[bbimber]

hi josh - i'm not sure i follow. I find value in having dependencies.txt checked into git, because it sorta serves like package-lock files do. it is auto-updated. therefore if someone bumps some JAR in the core gradle config, the gradle build updates dependnecies.txt in my module and this is a flag that I need to manually change jars.txt. I would be very happy not to have to maintain jars.txt myself, as it seems like this should be automatic (though there are limited fields in it gradle does not know about, so i can see why it isnt right now).