Thanks all the help from IPMC. I'm sorry I didn't make it clear enough earlier.
Actually, this question is related to recently release check of Apache Camel[1]. I just found there are some tests jar in the source kit by applying what I learned from IPMC. I already submit a quick fix to eliminate those jars. [1]https://issues.apache.org/jira/browse/CAMEL-13240 Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Feb 26, 2019 at 12:19 AM Craig Russell <apache....@gmail.com> wrote: > > Hi Willem, > > It will help focus this discussion if you tell us what the binary artifacts > are and why your normal build process doesn't already build them. > > Mark and Christopher described a couple of possible binary files and how to > handle them. > > But it would be really useful for you to tell us what these files are. > > Regards, > > Craig > > > On Feb 23, 2019, at 11:06 PM, Willem Jiang <willem.ji...@gmail.com> wrote: > > > > Hi Ted, > > > > You made a good point, I think my solution could be building the jars > > from source and then using it for testing. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning <ted.dunn...@gmail.com> wrote: > >> > >> Willem, > >> > >> This issue of embedded binaries for testing purposes has come up before. > >> Examples include network intercepts for testing malware detection or class > >> files for a byte code manipulator. The network files can't easily be > >> recreated since they were observed in the wild and the class files might > >> have been produced by a specific (possibly broken) compiler version that > >> isn't widely available. > >> > >> The key question is whether these binaries are derived from some source > >> that could be compiled instead of distributing the binary objects. Failing > >> that, can the provenance and justification for the binary object be > >> described? > >> > >> > >> > >> > >> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <willem.ji...@gmail.com> > >> wrote: > >> > >>> Hi > >>> > >>> Thanks Justin for the clarification. I guess the policy imply the > >>> source materials cannot have any binary. > >>> But what if the binary is only for testing, which cannot be part of > >>> the released software. > >>> From my point of view, we don't need to modify the source materials > >>> testing binary to do the software release as it is not a part of the > >>> binary release of the software. > >>> > >>> Any thoughts? > >>> > >>> Regards, > >>> > >>> Willem Jiang > >>> > >>> Twitter: willemjiang > >>> Weibo: 姜宁willem > >>> > >>> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <jus...@classsoftware.com> > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>>> [1]http://www.apache.org/legal/release-policy.html#what > >>>> > >>>> It’s explained in that link there i.e. "The Apache Software Foundation > >>> produces open source software. All releases are in the form of the source > >>> materials needed to make changes to the software being released”. > >>>> > >>>> Thanks, > >>>> Justin > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>>> For additional commands, e-mail: general-h...@incubator.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>> For additional commands, e-mail: general-h...@incubator.apache.org > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > Craig L Russell > Secretary, Apache Software Foundation > c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo > <http://db.apache.org/jdo> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
