> I completely agree. But how can we release (some official version of) > the project as source without also releasing the (convenience) binaries > for everything?
I don't understand the question here. Wouldn't we just include all example code in the source distribution but only create binaries for the primary API? Is there some requirement related to what binaries are produced? -Matt J On Sun, Jul 18, 2021 at 5:14 PM Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > > [...] > > > > Building from the project root I get the same error you reported. > > > > > > > > This post of StackOverflow [1] indicates that this is a problem with > > > > running the shade plugin within a multi-phase command. It is related to > > > > dependency resolution when the shade plugin tried to incorporate all the > > > > classes in the final jar. If building all the classes it the same phase > > > > then it appears to break. If left to download them (as in my first > > > example) > > > > then it works. > > > > > > $ mvn verify > > > --> SUCCESS > > > > > > $ mvn verify site > > > --> SUCCESS > > > > > > $ mvn verify test site > > > --> FAILURE > > > > > > $ mvn test package verify site > > > --> SUCCESS > > > > > > > This is inconsistent to say the least. The bug MSHADE-215 [1] appears to > > indicate that running 'test package' will fail and running 'package' will > > succeed. Anyway it may be the same thing where adding the 'test' target > > somewhere in the set of targets causes the shade plugin to include classes > > using a directory but label them as a jar. > > > > > > [1] https://issues.apache.org/jira/browse/MSHADE-215 > > > > > > > > > > I notice that junit runs in the "verify" phase; so, is the "test" phase > > > always redundant (before a commit)? > > > > > > > If running a target that is after 'test' in the lifecycle then yes, 'test' > > is redundant. If you use 'verify' you do not need 'test'. Adding 'test' > > appears to trigger a bug in the shade plugin using some combinations of > > targets later than 'test' from the default lifecycle. > > > > > > > > > > > I suggest the shaded jar is added within a profile and not on the > > > > default > > > > build. Thus you need to explicitly build the shaded jar. > > > > > > > > Is it the intention to release this artifact? Otherwise build on-demand > > > via > > > > a profile should solve this. > > > > > > Do you propose that the "commons-math-examples" not be part of the > > > official release? > > > > > > > Are they of value as a dependency to be used by others? If we release the > > standard jars from the examples modules then they can be included as a > > dependency and that will bring everything upstream with it to a project. > > > > The question is whether the shaded jar has value as a released artifact. I > > always considered them proof-of-application demos rather than programs that > > had far reaching utility. > > I completely agree. But how can we release (some official version of) > the project as source without also releasing the (convenience) binaries > for everything? > > Regards, > Gilles > > > > > > > > > [1] > > > > https://stackoverflow.com/questions/37942689/maven-shade-plugin-reports-error-creating-shaded-jar-target-classes-is-a-d > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
