Le mer. 21 juil. 2021 à 00:32, Matt Juntunen <matt.a.juntu...@gmail.com> a écrit : > > > 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?
In practice, all sources are handled in the same way and the question has to be raised so that an answer can be given... > > -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
