Closed Riduidel closed 4 years ago
Since, as of today, this plugin doesn't support pom reloading, it could be a good thing to generate the uber-jar before to run the application. This way, we wouldn't have to fight against this limitation ...
So it seems the most classical "Java" workaround is to build a multi-module maven project,
I'm not that fond of this method, but I think it's the simplest possible one.
It appears the workaround didn't work. Indeed, maven-assembly-plugin can't handle service porperties files, and maven-shade-plugin, although configured to correctly load those files, has failures regarding weld CDI dependencies in my project. So it is time to take a look at alternatives to cmd.exe.
According to StackOverflow, it seems possible to run PowerShell and commands from java processes, I will try to patch the plugin to support that feature ...
Daaaaamn ...
JavaProcessExecutor
delegates the construction of the command-line shell to plexus-utils ... which knows nothing of PowerShell !
Easiest workaround, as of today, is to use subst to map the maven repository to a virtual driver (I used M:
). This gained me enough characters to have my application working.
We too experienced this issue with recent versions of the plugin on Windows. We did not experience issues with version 1.0.15, but we do with 1.0.17 and 1.0.18. When turning on Maven debugging, we too see our commands are slightly longer than 8192 characters and receive the same error message you mentioned. We have reviewed and reduced our dependencies (which are added to the classpath when running) as much as possible.
It's really annoying... I can't create a simple project with some default dependencies because it exceeds more than 10000 characters.
@Riduidel in the past I also had the issue on other projects. We moved the Maven repo to C:\mrepo
. The subst
workaround is more effective though.
Would you mind to send a PR for the documentation? If the workaround is documented, we can close this issue.
I temporarily fixed it with subst M: C:\{user_path}\.m2\repository
and then set the maven repository in IntelliJ to M:
.
But I think it should be fixed by the plugin and not with a workaround. IntelliJ is fixing this issue by creating a temporary file, writing the dependencies in it and passing the file to the classpath parameter.
@Dudeplayz do you mean creating a temporary jar file with classpath references? Would you mind to send a PR?
IntelliJ seems to support multiple ways to solve this: https://blog.jetbrains.com/idea/2017/10/intellij-idea-2017-3-eap-configurable-command-line-shortener-and-more/ I've never done a PR before and I am not sure if I have enough knowledge to do it the "right" way for an open-source project. I will think about it.
Would you mind to send a PR for the documentation? If the workaround is documented, we can close this issue.
Sorry for the incredibly late reply. @tsegismont where do you want that documentation to be added ?
No problem @Riduidel
The doc is here https://github.com/reactiverse/vertx-maven-plugin/tree/master/src/main/asciidoc
I'm using vertx-maven-plugin on Windows. I have an application with the following dependency set
When running
mvn vertx:run
, I have the following information message[INFO] La ligne de commande est trop longue.
In other words[INFO] Command line is too long
. Running the same build withX
reveals the command line to beAccording to notepad++, this command line is 10.794 characters long ... Yes, a little too much. Is there a workaround to avoid having the whole CLASSPATH sent as command line parameters ? Because, according to common wisdom, Windows cmd.exe has a command-line length limit of 8192 characters.