On Mon, May 14, 2018 at 11:16 AM, Dave Fisher <dave2w...@comcast.net> wrote:
> Hi - > > > On May 14, 2018, at 10:57 AM, Sijie Guo <guosi...@gmail.com> wrote: > > > > On Sun, May 13, 2018 at 7:49 PM, Matt Sicker <boa...@gmail.com> wrote: > > > >> On 13 May 2018 at 12:10, Matteo Merli <mme...@apache.org> wrote: > >> > >>> The code in question is testing a feature that takes Jars from a user > and > >>> execute the code contained. Indeed the Jar should not be in the > sources, > >>> though I believe the test is correct here: we need to validate the > >> specific > >>> feature by dynamically loading a Jar. > >>> > >> > >> By generating the binary jar from source files at test time, you'd avoid > >> bundling any binary output files. > >> > > > > I made the original change long time back in pulsar-functions for testing > > submitting user-defined function. When we first contribute > pulsar-functions > > to pulsar, we probably didn't clean that up. > > The intention behind that change is not including any source code or jar > in > > the test dependency tree. As including source code would make the testing > > function as part of the test dependency, it would volatile the purpose of > > testing submitting a user defined function. In this case, > > "multifunction.jar" is the a "user-defined" function as the test > resource. > > To be succinct The ASF produces open source software and including a > pre-compiled binary in the release means that the project fails the open > source definition. [1] > > It really doesn’t matter how or why. You will need to provide the source > (as simple as it might be) and the maven configuration to build that > trivial jar. > Okay. So if we provide the source file of that jar, is it allowed to include a pre-compiled binary as test resources? > > Regards, > Dave > > [1] https://opensource.org/osd > > > > > > > > > > > > >> > >> > >>>> (e.g., injecting a > >>> module-info.class file at build time rather than requiring Java 9+ to > >> build > >>> regardless). > >>> > >>> I don't see any place in the code where we are using > "module-info.class" > >>> and the project requires Java 8 and not 9. > >>> > >> > >> Sorry for the confusion, that was just an example from a problem I've > seen > >> before in another project. > >> > >> -- > >> Matt Sicker <boa...@gmail.com> > >> > >