Issues with copyDependencies of artifact built within multi-module reactor build #1752
Comments
|
Thanks @ThomasHurek for reporting this issue. Would you be willing to collect more logging by running with the "Start ..." and adding the The Liberty Tools Eclipse IDE tooling provides only a thin wrapper around the underlying liberty-maven-plugin "dev mode", so I'd expect the same issue would exist either inside the IDE or outside (e.g. from a shell via mvn CLI). If you get the chance maybe you could try that. Does the problem go away or reappear based on doing a clean (or not doing a clean)? (There is no way to do this currently using the IDE tooling, you'd have to use a separate CLI shell or use the "m2e" Maven support in Eclipse). |
|
@scottkurz Thx for taking a look at the issue. Attaching the requested output: mvn -version Exception stack: [ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.7.1:dev (default-cli) on project engine-ear: Use a resource collection to copy directories. -> [Help 1] |
|
I tried with clean and without clean and the same issue happens: [ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.7.1:dev (default-cli) on project engine-ear: Use a resource collection to copy directories. -> [Help 1] |
|
Seems the logs are not pasted complete so pasting as file. |
|
@ThomasHurek thanks for the logs. It seems from the exception that one of the dependencies included via the copyDependencies config resolves to a directory location. This could be a dependency listed directly, or more likely, transitively (the name "aggregator-manager" suggests this might aggregate a number of dependencies). Do you happen to have any guess as to which dependency this might be? I wonder if it is one of the standard packaging types or something custom perhaps, or at least less common. The log seems like it got truncated, unfortunately, so I can't really draw any conclusions from that. Did you happen to have a chance to try recreating outside of Liberty Tools Eclipse? Thanks. |
|
I tried mvn liberty:dev (after triggering a build of all components with mvn install) and it starts fine: [INFO] CWWKM2015I: Match number: 1 is [11/1/23, 17:33:29:420 EDT] 00000026 com.ibm.ws.kernel.feature.internal.FeatureManager A CWWKF0011I: The engineServer server is ready to run a smarter planet. The engineServer server started in 30.721 seconds.. |
|
Yes the aggregator-manager is used for gathering transitive dependencies. It is pretty straightforward but it does use exclusions like: |
|
OK, I think I have an idea what type of problem we're dealing with. This is a bit long but let me leave some notes to consider. OBSERVATIONYou appear to be doing a multi-module build, and the dependency you're copying via I'm observing this looking at the build output: as this 'aggregator-manager' matches the artifactId in one of your MULTI-MODULE BEHAVIOR EXPLAINEDIn some contexts, the Maven APIs we're using in liberty-maven-plugin will associate a Maven artifact with the path of the locally-installed artifact. This is what would be used for a completely external dependency. In certain multi-module contexts, though,Maven will associate the artifact with its output directory, e.g. target/classes. This makes sense if you stop to think about how RECREATEAnyway, I can now easily recreate a problem like this by taking the multi-module guide app: https://github.com/OpenLiberty/guide-maven-multimodules and adding to its ear module the liberty-maven-plugin config: <copyDependencies>
<dependency>
<groupId>io.openliberty.guides</groupId>
<artifactId>guide-maven-multimodules-jar</artifactId>
</dependency>
</copyDependencies>and then doing a multi-module In fact, doing a And the scenario I constructed is in fact kind of unrealistic. The The copyDependencies function was originally developed with a use case more like "copy a provided-scoped JDBC driver dependency into place", since such a dependency would NOT get packaged within the building of the EAR/WAR. NEXT STEPSI have to stop here for the day without having gotten to what the next step should be, but let me just paste that analysis for now, regardless. |
scottkurz
changed the title
|
I don't think this change broke anything (I think the basic issue exists before and after this was merged), but this PR: #1570 overlapped some of the constructs here (the output dir in a multi-mod build)..so might be something to learn from. |
|
Yes you are totally right it is a multi-module setup. The ear module sits in parallel with various other modules. |
So how do the contents in aggregator-manager get used? Via some kind of global/shared library or resource (JDBC) library? If, OTOH, they are just application-level libraries then I wonder if you should by using copyDependencies vs. just packaging them into the app (EAR). |
|
They are used in multiple shared libraries. |
Since upgrading to the latest version of the Eclipse plugin 23.0.9 and trying to use the Liberty Dashboard start command the following error occurs:
[ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.9:dev (default-cli) on project engine-ear: Unable to execute mojo: Execution null of goal io.openliberty.tools:liberty-maven-plugin:3.9:create failed: Use a resource collection to copy directories. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :engine-ear
When removing the copyDependencies the plugin seems to succeed but missing the files that would be copied.
Section from pom.xml:
The text was updated successfully, but these errors were encountered: