-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for runtime and provided dependencies at same time #60
Comments
Based on the answer on SO it does not make sense. Or you you could provide a patch (as PR) ? |
Try using the below POM along with a main class called "Main". If you run
indicating that the "provided" dependency is not available. If you run
indicating that the "runtime" dependency is not available. I can attempt to make a PR to help fix this, but I could use some input on what the configuration should look like. Should we add a new value for "classpathScope" called "provided" which includes both runtime and provided?
|
I know that the provided scope is not available on the classpath cause it's defined provided which means it is provided by the runtime environment. That was the reason that i said you could provide a patch which solves this problem ? |
Oh, it sounded like you thought it made no sense. I can attempt a patch, but as I asked above, do you care what the configuration setting should be? Is "provided" ok as a new value for classpathScope? |
- New "provided" value for classpathScope includes both runtime and provided dependencies - Closes mojohaus#60
- New "provided" value for classpathScope includes both runtime and provided dependencies - Closes mojohaus#60
@khmarbaise #61 created to resolve this. |
@khmarbaise wrote:
For exec:java there isn't usually anywhere else that the provided dependencies could come from unless they actually part of the standard java libraries. ie. built-in classes. The request in #61 is to make the provided depdendencies available in the runtime. While the "provided" dependencies might be expected to be available in normal/exepcted execution circumstances it seems reasonable for exec:java to act as "provider" of these dependencies if it is acting as the execution container. Since exec:java is the execution container and the "provided" and "optional" dependencies won't otherwise be available it might even be argued that including them should be the default behaviour of exec:java. |
@bondolo Exactly! For local development purposes it's often useful to be able to run an app and use Maven to supply the "provided" dependencies rather than using the full deployment environment. |
@rehevkor5 What is the status of your merge request? Has it been cancelled or ignored? This feature would be very welcome. My software references org.slf4j:slf4j-api:provided, and some :runtime dependencies down the road... Currently, I cannot run the application, as either scope "compile" or scope "runtime" will miss one or the other dependency... |
- New "provided" value for classpathScope includes both runtime and provided dependencies - Closes mojohaus#60
I pinged @rfscholte and @khmarbaise on twitter. It appears this issue is at an impasse unless @olamy is able to approve. This project seems to need new/additional maintainers. |
I guess there are use cases where you could consider |
Hi @rehevkor5, @olamy, @khmarbaise , @rfscholte, Any chance this can get deployed? I'm also having the same issues. As a workaround, I tried using the additionalClasspathElements parameter with the required classpath, along with using the parameter classpathScope="runtime", but the additionalClasspathElements parameter does not seem to be used. From looking at the code, the value of this parameter seems to be ignored, even though it is documented as a valid optional parameter of the exec:java goal of the exec-maven-plugin on this page: https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#additionalClasspathElements . Is this a known bug ? |
I don't know, it seems like this repo is abandoned, since it's been 8 years since I made the PR. I guess I/we/someone could publish a fork of this plugin, as a way to make it available. |
@rehevkor5 thanks for your efforts, as you see a project is not abandoned, I did a release two weeks ago ... But you are right there are many open issues and PR, simply there are not many maintainers, so sorry for missed this one. Nevermind if you rebase your PR again I can try to merge. |
- New "provided" value for classpathScope includes both runtime and provided dependencies - Closes mojohaus#60
@slawekjaranowski Oh great, thanks! I rebased it & reran tests. The only problem was unrelated: the method |
- New "provided" value for classpathScope includes both runtime and provided dependencies - Closes mojohaus#60
- New "provided" value for classpathScope includes both runtime and provided dependencies - Closes #60
Oh wow, thanks SO much @rehevkor5 and @slawekjaranowski for all your help on this! It's amazing you could still work on this, even 8 years later! :-) Will this be part of a planned release? Wondering how we can download it via maven. Also, I ran into another issue for this plugin, 51, which was fixed, but then was reverted, which I ran into when I was attempting to use the additionalClasspathElements parameter as a workaround. Any chance on getting this fixed? I will post in the related issue, but just thought I would post this here too, as I mentioned it in my previous comment above, also. |
@inzucchi I did a release a 3 waks ago ... 😄 I can do next release I see there are a many open issues, some are very old and should be checked with the latest version. |
As discussed here http://stackoverflow.com/questions/6418414/maven-exec-plugin-cant-depend-on-provided-dependancy#comment48129503_16042080 there is no way to use the plugin while getting both provided and runtime dependencies onto the classpath.
The text was updated successfully, but these errors were encountered: