Update dependencies and stop producing "distribution" file

[labkey-adam]

Rationale

Current dependencies have gotten out-of-date. For example, the latest OWASP plugin (10.0.4) fails to run due to its need for commons-io 2.16.0 or later.

The webapp now gets the distribution name from the distribution.properties file, so no need to produce or include the standalone distribution file.

Move the version and buildUrl properties into the distribution.properties file. VERSION file will go away once we're confident that no code path needs to read it.

Related Pull Requests

• Respect distribution-provided properties platform#5890
• Teach EmbeddedExtractor to use distribution.properties server#894

[labkey-adam]

@labkey-susanh the HttpClient/HttpCore update seemed easy enough. I tested a few of the MultiGit tasks locally and saw no problems. I have not tested PurgeArtifacts, PurgeNpmAlphaVersions, or RestoreFromTrash.

[labkey-susanh]

For the artifactory plugin, we need to make sure the artifactoryPublish tasks, which TeamCity uses, work.

Also, I tried running a purgeNpmArtifacts task and it produces a stack trace because of incompatible types. I can look at it a little later, or you can probably see it for yourself by running the command:
./gradlew purgeNAV -PalphaPrefix=fb-issue-48049 -s

(The command actually succeeds up to the point where it tries to process the response, so you'll need to find another one to purge to test the fix.)

[labkey-adam]

For the artifactory plugin, we need to make sure the artifactoryPublish tasks, which TeamCity uses, work.

Also, I tried running a purgeNpmArtifacts task and it produces a stack trace because of incompatible types. I can look at it a little later, or you can probably see it for yourself by running the command: ./gradlew purgeNAV -PalphaPrefix=fb-issue-48049 -s

(The command actually succeeds up to the point where it tries to process the response, so you'll need to find another one to purge to test the fix.)

So we test artifactoryPublish by kicking off a distributions build? Or??

I wasn't able to repro the purgeNpmArtifacts issue locally, but I think I saw and fixed the problems. When you get a chance, could you test again? And maybe send a stack trace if you see a problem?

[labkey-adam]

@labkey-susanh @labkey-tchad This run built and published all distributions using this version of the gradle plugin: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_InstallersCustom/3213578?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildChangesSection=true&logView=flowAware

I think that means the Artifactory Plugin version is good?

[labkey-susanh]

For the artifactory plugin, we need to make sure the artifactoryPublish tasks, which TeamCity uses, work.
Also, I tried running a purgeNpmArtifacts task and it produces a stack trace because of incompatible types. I can look at it a little later, or you can probably see it for yourself by running the command: ./gradlew purgeNAV -PalphaPrefix=fb-issue-48049 -s
(The command actually succeeds up to the point where it tries to process the response, so you'll need to find another one to purge to test the fix.)

So we test artifactoryPublish by kicking off a distributions build? Or??

I wasn't able to repro the purgeNpmArtifacts issue locally, but I think I saw and fixed the problems. When you get a chance, could you test again? And maybe send a stack trace if you see a problem?

I succeeded in purging NPM artifacts with this version.

For testing artifactoryPublish I usually just try to run it locally (and then go delete any version that was published. If publishing from a branch, the artifacts will contain the branch name, and we don't need to keep them around. You shouldn't have to publish everything, just one module's files should be fine.

[labkey-tchad]

Could we roll the VERSION file properties (buildUrl and labkeyVersion) into the distribution.properties file. It would simplify the upgrade check a bit (putting all of the relevant information in a single file). We could also simplify the VERSION file to just have the product version like it used to.

[labkey-adam]

Could we roll the VERSION file properties (buildUrl and labkeyVersion) into the distribution.properties file. It would simplify the upgrade check a bit (putting all of the relevant information in a single file). We could also simplify the VERSION file to just have the product version like it used to.

I like the idea. I'll make the changes to the plugin in this PR. Is EmbeddedExtractor the only place that uses the VERSION file?

[labkey-susanh]

@labkey-susanh @labkey-tchad This run built and published all distributions using this version of the gradle plugin: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_InstallersCustom/3213578?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildChangesSection=true&logView=flowAware

I think that means the Artifactory Plugin version is good?

This build doesn't publish to artifactory (since we don't want to publish artifacts from feature branches).

My recommendation is to try this locally. You can check out the develop branch and update the gradle.properties locally to use your new version of the plugins, then try a command such as ./gradlew :server:modules:platform:api:artifactoryPublish -PdoPublishing and see if you get a new version in Artifactory (or produce an error).

[labkey-tchad]

Is EmbeddedExtractor the only place that uses the VERSION file?

It isn't used by any tests or other product code but I don't know if any external integrations are using it for something.

[labkey-adam]

@labkey-susanh @labkey-tchad This run built and published all distributions using this version of the gradle plugin: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_InstallersCustom/3213578?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildChangesSection=true&logView=flowAware
I think that means the Artifactory Plugin version is good?

This build doesn't publish to artifactory (since we don't want to publish artifacts from feature branches).

My recommendation is to try this locally. You can check out the develop branch and update the gradle.properties locally to use your new version of the plugins, then try a command such as ./gradlew :server:modules:platform:api:artifactoryPublish -PdoPublishing and see if you get a new version in Artifactory (or produce an error).

Yes, I've been testing locally. When I run this command, I get:

A problem occurred configuring project ':server:modules:adjudication'.
> Modules produced with deployMode=dev are not portable and should never be published.

Is there another flag (as with distribution) that can force it to publish dev-mode artifacts?

[labkey-susanh]

@labkey-susanh @labkey-tchad This run built and published all distributions using this version of the gradle plugin: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_InstallersCustom/3213578?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildChangesSection=true&logView=flowAware
I think that means the Artifactory Plugin version is good?

This build doesn't publish to artifactory (since we don't want to publish artifacts from feature branches).
My recommendation is to try this locally. You can check out the develop branch and update the gradle.properties locally to use your new version of the plugins, then try a command such as ./gradlew :server:modules:platform:api:artifactoryPublish -PdoPublishing and see if you get a new version in Artifactory (or produce an error).

Yes, I've been testing locally. When I run this command, I get:

A problem occurred configuring project ':server:modules:adjudication'.
> Modules produced with deployMode=dev are not portable and should never be published.

Is there another flag (as with distribution) that can force it to publish dev-mode artifacts?

You can use -PdeployMode=prod to get an artifact that can be published.

[labkey-adam]

@labkey-susanh @labkey-tchad This run built and published all distributions using this version of the gradle plugin: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_InstallersCustom/3213578?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildChangesSection=true&logView=flowAware
I think that means the Artifactory Plugin version is good?

This build doesn't publish to artifactory (since we don't want to publish artifacts from feature branches).
My recommendation is to try this locally. You can check out the develop branch and update the gradle.properties locally to use your new version of the plugins, then try a command such as ./gradlew :server:modules:platform:api:artifactoryPublish -PdoPublishing and see if you get a new version in Artifactory (or produce an error).

Yes, I've been testing locally. When I run this command, I get:

A problem occurred configuring project ':server:modules:adjudication'.
> Modules produced with deployMode=dev are not portable and should never be published.

Is there another flag (as with distribution) that can force it to publish dev-mode artifacts?

You can use -PdeployMode=prod to get an artifact that can be published.

Okay, artifactoryPublish worked like a charm. I don't see a way to delete my snapshot artifacts... I can view, download, and copy, but no delete. Perhaps a permissions issue?

[labkey-susanh]

@labkey-susanh @labkey-tchad This run built and published all distributions using this version of the gradle plugin: https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Premium_InstallersCustom/3213578?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildChangesSection=true&logView=flowAware
I think that means the Artifactory Plugin version is good?

This build doesn't publish to artifactory (since we don't want to publish artifacts from feature branches).
My recommendation is to try this locally. You can check out the develop branch and update the gradle.properties locally to use your new version of the plugins, then try a command such as ./gradlew :server:modules:platform:api:artifactoryPublish -PdoPublishing and see if you get a new version in Artifactory (or produce an error).

Yes, I've been testing locally. When I run this command, I get:

A problem occurred configuring project ':server:modules:adjudication'.
> Modules produced with deployMode=dev are not portable and should never be published.

Is there another flag (as with distribution) that can force it to publish dev-mode artifacts?

You can use -PdeployMode=prod to get an artifact that can be published.

Okay, artifactoryPublish worked like a charm. I don't see a way to delete my snapshot artifacts... I can view, download, and copy, but no delete. Perhaps a permissions issue?

You'll need to be in libs-snapshot-local in order to see the delete options for artifacts.

[labkey-adam]

Okay, artifactoryPublish worked like a charm. I don't see a way to delete my snapshot artifacts... I can view, download, and copy, but no delete. Perhaps a permissions issue?

You'll need to be in libs-snapshot-local in order to see the delete options for artifacts.

I believe that's where I am. For example: https://labkey.jfrog.io/ui/repos/tree/General/libs-snapshot-local/org/labkey/api/api/24.11-SNAPSHOT/api-24.11-20241003.135700-5.jar