Waltz Packaging - packaging fails to include Main class (Error: Could not find or load main class org.finos.waltz.web.Main)

TL41 commented 7 months ago

Description

Note: this has been resolved for me, but logging here in case anyone sees this

I switched over to a new laptop and have been unable to package Waltz on that new device. It has worked fine on my old laptop for a while

The 'waltz-web-jar-with-dependencies.jar' gets packaged as approx 90MB, nearly twice the expected size of around 50MB
The 'waltz-web.war' has a "normal" size of around 45MB
Maven logs from the console show that the 'org/finos/waltz/web/Main.class' gets added to the war file but not the jar with dependencies

Setup

Windows 10
Intellij 2023.3.4
Maven 3.9.5 (bundled with Intellij) or Maven 3.9.6
PostgreSQL

Waltz Version

1.57

Steps to Reproduce

run 'clean', 'compile' and 'package'

Expected Result

IntelliJ / Maven should package up a jar file to run Waltz

Actual Result

when running: java -cp .\waltz-web\target\waltz-web-jar-with-dependencies.jar org.finos.waltz.web.Main

get this error: Error: Could not find or load main class org.finos.waltz.web.Main

TL41 commented 7 months ago

I tried many things, mostly trying to confirm settings in Intellij and versions of all of the components to package the jar.

In the end, I rolled back IntelliJ to 2023.2.1 (from 2023.3.4), which also rolled back Maven to 3.9.2

I wiped out my local Waltz repo and my local maven repo (~/.m2/repository), and then did a fresh 'clean', 'compile' and 'package' - then it works again. I'm using npm 10.2.3

c:\dev\workspaces\lp-waltz>npm --version
10.2.3

Note: when I did this, my waltz-ng/package-lock.json gets updated (LOTS of differences); I now see a lot of diffs and "lockfileVersion": 3. I can't say for sure but I think I was having my build/packaging issues when the waltz-ng/package-lock.json was set at lockfileVersion": 1 and wasn't updating; maybe something I did force this to update and allowed me to package the jar again

I noticed that when @davidwatkins73 and @JWoodland-Scott commit to waltz-ng/package-lock.json it bounces between "lockfileVersion": 3 and "lockfileVersion": 1, among all of the other diffs

10/26/23: https://github.com/finos/waltz/commit/08ceb889af9562136d3da97099f7ec2cd292f182

12/6/23: https://github.com/finos/waltz/commit/6c5fac86861fc36416444bce4e01875ce3fe9459

1/22/24: https://github.com/finos/waltz/commit/d91a49b2f86a51aa6ff72e0cca7e1245691606e4

taken from lockfileVersion

An integer version, starting at 1 with the version number of this document whose semantics were used when generating this package-lock.json.

Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in node_modules or the npm registry. Lockfiles generated by npm v7 will contain lockfileVersion: 2.

No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5.
1: The lockfile version used by npm v5 and v6.
2: The lockfile version used by npm v7 and v8. Backwards compatible to v1 lockfiles.
3: The lockfile version used by npm v9. Backwards compatible to npm v7.

davidwatkins73 commented 7 months ago

We should look to enforce minimum versions on our node/npm builds, see : https://stackoverflow.com/questions/29349684/how-can-i-specify-the-required-node-js-version-in-package-json

We should also review the minimum maven version (currently enforced in the root pom.xml file)

finos / waltz