Docker UCE-web container sometimes doesn't recognize defined CLI arguments

[TheBv]

Sometimes when building the web portal running it causes the following error:

2025-08-21 14:46:34 Exception in thread "main" org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -cf
2025-08-21 14:46:34     at org.apache.commons.cli.DefaultParser.handleUnknownToken(DefaultParser.java:561)
2025-08-21 14:46:34     at org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:469)
2025-08-21 14:46:34     at org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:542)
2025-08-21 14:46:34     at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:712)
2025-08-21 14:46:34     at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:679)
2025-08-21 14:46:34     at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:660)
2025-08-21 14:46:34     at org.texttechnologylab.App.main(App.java:55)

This occurs even though the -cf parameter is clearly defined.
Rebuilding the image sometimes fixes this.
One oddity that I've noticed is that I believe the stacktrace is incomplete.
Shouldn't we also have a line with the parseCommandLine method? E.g:

                                       at org.texttechnologylab.App.parseCommandLine(App.Java:215)

[TheItCrOw]

This is a very weird error that has occured for everyone who'se used UCE before. I've tried fixing this a lot, but I never understood what the problem was. The mentioned lines in the strackrace make no sense whatsoever to me - sometimes it even shows lines that don't exist.

It's even more weird considering that it works once you purge the docker cache (at least sometimes). No idea what this is. Incredibly annoying bug. Since it works after rebuilding it (sometimes multiple times), I always assumed it's a docker issue.

[TheBv]

I looked into this issue further and "decompiled" a broken jar and a working jar.

Turns out the issue is that we have two duplicate classes with the same name.
One of which is defined in this project the other in one of our dependencies. More specifically the dependency is the uce.corpus.importer

Now there's multiple ways we can handle this:

1. We could simply exclude the corpus-importer. Right now we don't need it in our main code but PRs like Automatically add a corpus if none exist #106 would break this immediately.

2. We could rename our packages to have unique package names e.g org.texttechnologylab.uce.common etc...

3. There exists a maven-shade plugin that allows one to repackage a dependency under a different name

Now I am very much against solution 1. since other repositories of ours might do similar things, and maybe at some point our auth code gets overridden by a random ttlab dependency.
Hence I'm also against 3. since at some point we might import a dependency again that breaks things.

I'd really like us to rename all of our packages then. I know it's a bit more work but with IDE tools it should be pretty painless - I can even do it if you want

NOTE: Technically how we're registering cli options is not really intended...
Normally a cli option like -cf would be interpreted as -c -f
This doesn't really break things unless we wanted to register the options -c and -f and someone wanted to specifically use -cf to enable both but it might be worth considering not registering short commands for at all.

[TheItCrOw]

Ah I see, cool! And this problem occurs only sometimes? That's so weird.

• Concerning the package names: what exactly would we need to rename?
• We can skip the short commands then.

[Myyyvothrr]

Thanks for looking into this! Yes we definitively should do (2)