<addDependencies> does not add runtime scope #5
Comments
|
I have been using this plugin very long ago, can you prepare a small demo project that I can use and test the solution? |
|
Please find a sample of the problem here: there are instructions and details in the README |
|
Just tested your example and everything works as expected, see the screenshot |
|
That's right, the file is included, but not referenced by the EXE file! Try to open it with any binary-enabled editor and search for JAR file names. You'll find that This leads to the problem that the JAR is included as a file, but not in the effective classpath. |
|
The problem is with which means dependencies are evaluated based on current phase, but what is funny so I must find a way to include that map in classpath resolution ;-) |
|
Done, please check the latest 1.7-SNAPSHOT version, it should be available in 30 min in Maven Central |
|
Don't wait for Maven Central - use OSS Sonatype repo, details in README.md |
|
We're using version 1.7.1 and we have exactly the same problem. With runtime it is not on the classpath when EXE runs. Our setup of the plugin is like this: |
|
@virgo47 can you run this command and post result? |
|
Here it is, with minor anonymization, but groovy-all is pretty much self-contained, so it should not change the result. However, I checked the EXE file too, and there is the line that contains all the JARs (I didn't count them though :-)), but the groovy-all one. That one is missing and is NOT listed in the EXE file. |
|
So the problem is that the |
|
We have only this as runtime dep. When I switch it to default scope (or explicitly compile) it is mentioned in the EXE, in runtime scope it is not. I doubt it has anything to do with name of the JAR. Sorry for not being clear, the rest of my deps is not runtime and they cause no problem. |
|
No I'm lost :) Can you share detailed dependencies of your project? Or prepare a small demo app to reproduce this issue? |
|
Here it is: https://github.com/virgo47/litterbin/tree/master/issues/l4jissue |
|
Great! Now I see you have put |
|
Sorry, I implied this information from the title and first post of the original bug because it exactly matched my situation. My bad for not being clear enough. From here it looked like reopen, if it's not let me know if I should start a new bug. |
|
f575af6 should solve the problem, can you test 1.7.6-SNAPSHOT? If it passes, I will push a new version to the Central. |
|
How can I try the snapshot? Snapshot wasn't found in repo automatically and when I downloaded the zip of the project and tried I tried both repositories and pluginRepositories like this: |
|
Sorry, forget to push - try now |
|
Yup, 1.7.6-SNAPSHOT finds groovy dependency in runtime scope, and running exe will find groovy script engine without problems now. 👍 |
|
Gut! I will push a new version soon! Thanks for your support! |
|
New artifacts underway to the Central - please wait 24h for sync :) Enjoy! |
|
Updated and working as expected. Thank you very much
|
|
This is working partially. It does not pick up transitive runtime dependencies. Can this be reopened to address the problem? e.g. <dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<scope>runtime</scope>
</dependency>This gets correctly added to the exe, but this dependency has a runtime dependency on log4j-api which is not added to the exe. |
|
Also, the runtime dependencies are just added to the end of the classpath. They should be in pom/maven order as the rest of them are. |
|
@javaboy79 not sure if I understand, I thought it was already solved and this commit f575af6 just extended it, did I miss something? |
|
There are at least two issues here, the first is more critical:
|
|
Pull request #24 submitted. It fixes both issues. |
|
Just merged the PR #24 and pushed new SNAPSHOT version to Sonatype. Please check if everything works and I will prepare a new release afterwards |
|
@lukaszlenart Is there a special way to access snapshots? I do not see this in the repo. |
|
@lukaszlenart Nevermind my previous comment, I figured out where the snapshot repo was. Yes, everything seems to be working as expected with the snapshot release. |
|
Everything is in README |
|
Time to release :) |
…en-plugin * 'master' of https://github.com/lukaszlenart/launch4j-maven-plugin: (91 commits) Adds example wit opts Adds version notes [maven-release-plugin] prepare for next development iteration [maven-release-plugin] prepare release launch4j-maven-plugin-1.7.8 Migrates to new Tarvis infrastructure Use ProcessBuilder to launch 'chmod' Corrects small type Adds additional info about changes in 1.7.7 [maven-release-plugin] prepare for next development iteration [maven-release-plugin] prepare release launch4j-maven-plugin-1.7.7 Adds version notes for 1.7.7 Uses the latest stable version of Launch4j Closes orphan-oss#21 Adds support for bundledJreAsFallback property Closes orphan-oss#23 Upgrades to latest snapshot version of Launch4j fixes for runtime scoped jars issue#5 [maven-release-plugin] prepare for next development iteration [maven-release-plugin] prepare release launch4j-maven-plugin-1.7.6 Adds version notes of 1.7.6 Includes all direct dependencies closes orphan-oss#5 Adds 1.7.5 version notes ... # Conflicts: # .gitignore # .travis.yml # README # README.md # pom.xml # src/main/java/com/akathist/maven/plugins/launch4j/ClassPath.java # src/main/java/com/akathist/maven/plugins/launch4j/Jre.java # src/main/java/com/akathist/maven/plugins/launch4j/Launch4jMojo.java # src/main/resources/README # src/main/resources/README.adoc
With addDependencies=true dependencies set with a 'runtime' scope do not seem to be added to the classpath. The resulting .exe cannot find these dependencies. If you run with mvn -X you can see where the dependencies lists no runtime scopes.
The text was updated successfully, but these errors were encountered: