Yeah, I sort of understand. But that really means there is no "good" use case for letting shade read classes from target/classes within the reactor....(?)
Kristian 2015-11-14 20:15 GMT+01:00 Igor Fedorenko <[email protected]>: > Run the build with -X and see what mojos are executed for mshade171-base > project: > > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ > mshade171-base --- > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) > @ mshade171-base --- > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ > mshade171-base --- > [INFO] --- maven-resources-plugin:2.6:testResources > (default-testResources) @ mshade171-base --- > [INFO] --- maven-compiler-plugin:3.1:testCompile > (default-testCompile) @ mshade171-base --- > [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ > mshade171-base --- > [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mshade171-base > --- > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) > @ mshade171-base --- > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ > mshade171-base --- > [INFO] --- maven-resources-plugin:2.6:testResources > (default-testResources) @ mshade171-base --- > [INFO] --- maven-compiler-plugin:3.1:testCompile > (default-testCompile) @ mshade171-base --- > [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ > mshade171-base --- > > > Although jar:jar sets project artifact file to packaged jar, the second > compiler:compile compile invocation sets it back to target/classes > folder. > > -- > Regards, > Igor > > On Sat, Nov 14, 2015, at 09:55 AM, Kristian Rosenvold wrote: >> I've been using the test project attached to >> https://issues.apache.org/jira/browse/MSHADE-171, single threaded. >> Shade is bound to package. >> >> I really dont understand this :) >> >> K >> >> >> 2015-11-14 13:57 GMT+01:00 Igor Fedorenko <[email protected]>: >> > I believe "mvn clean package" runs the default lifecycle twice, first to >> > "package" phase, when reactor dependencies are resolved to packaged >> > jars, then to "test" phase, when reactor dependencies are resolved to >> > target/classes folders. I am surprised shade plugin is called during >> > "test" run at all. What phase is the plugin bound to in your project? >> > >> > -- >> > Regards, >> > Igor >> > >> > On Sat, Nov 14, 2015, at 06:45 AM, Robert Scholte wrote: >> >> Op Sat, 14 Nov 2015 11:53:41 +0100 schreef Kristian Rosenvold >> >> <[email protected]>: >> >> >> >> > While working on MSHADE-171, I figured I'd take a stab at making shade >> >> > work from the "target" folder instead of just the assembled finished >> >> > jar. >> >> > >> >> > I implemented this, and it works kinda-ok, but then I realized that >> >> > I'm not producing the same output as I would from "package", since >> >> > there is no META-INF in the "target" folder of a reactor dependency. >> >> > >> >> > The user here is issuing a command like "mvn clean package test". >> >> > Given this command the reactor references resolve to the "target" >> >> > folder, can someone explain this to me ? If I just do "mvn clean >> >> > package" it resolves to the jar file. >> >> >> >> And only one thread? >> >> >> >> Robert >> >> >> >> > >> >> > I'm probably the last guy to realize this, but this patch is a dead >> >> > end, right ? So we should probably just make shade a little more >> >> > verbose about what's going on; that we actually require a jar file ? >> >> > >> >> > Kristian >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
