On 25/02/2019 14:15, Roman Shaposhnik wrote: > On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas <ma...@apache.org> wrote: >> >> On 23/02/2019 06:18, Willem Jiang wrote: >>> Hi, >>> >>> I just have a question about the Binary jars in the source release. >>> According the Apache release policy, I cannot find any rule about the >>> binary jars cannot be in the source release[1]. If we just have jars >>> for testing purposes and those jar won't be a part of convenience >>> binary release, I think it doesn't break the rule below: >>> >>> "In all such cases, the binary/bytecode package must have the same >>> version number as the source release and may only add binary/bytecode >>> files that are the result of compiling that version of the source code >>> release.". >>> >>> Is it OK to ship those test binary jars in the source release kit? >> >> It depends ;) >> >> Generally, source releases should contain exactly that - source code. So >> the aim should always be to not include compiled code - like JARs - in a >> source release. >> >> That said, I have always been a little more relaxed about test code. >> Sometimes you need to use class files and/or JARs in your testing. The >> minimum - in my view - is that: >> - it MUST be possible to produce a fully working binary from the source >> distribution > > Big +1 to the above. > >> - the source for any compiled files included in the source MUST be >> provided alongside the compiled files > > Is this really a MUST in all situations? Sometimes a JAR file truly is a test > artifact (like for negative testcases for example) and it may not even be > possible to "compile it" -- its purpose in fact, may be to test something like > a classloader for tripping up on "incorrect" JARs, etc. > > Or did I misunderstand your MUST?
The view I was trying (and failing) to convey is that we don't want any binary "magic" files in the release. The "source" may be the source as in the input to a compiler. It might be a more complex recipe. Either way it needs to carry sufficient information to enable other community members to understand how the binary file was created and what they would need to do if they wanted/needed to re-create the binary file at some point in the future. HTH, Mark > > Thanks, > Roman. > >> Ideally, class files, JAR files etc. would be constructed as required >> when the tests are run. However, there are cases when it makes sense to >> include the binary - e.g. the file needs to be compiled with a very >> specific version of the compiler because it is testing something that >> depends on a specific behaviour of that compiler version. It is arguably >> better for users to provide the compiled file rather than requiring them >> to obtain the specific compiler version required. >> >> For the record, Apache Tomcat has a small number of JAR and class files >> in its source distribution. All related to testing and the source is >> there for all of them. We could probably generate some of those at build >> time. But, given the very small number of files concerned and the >> complexity it adds to the build process, it isn't an itch any of the >> community has felt the need to scratch. Yet. >> >> I also recall an instance - I think in Apache Commons BCEL - where we >> needed to test with a faulty class file. From memory, we shipped the >> class file in the source along with instructions on how to recreate it. >> I don't recall exactly why but creating it at build time was problematic. >> >> In summary, I think you are fine as long as you meet the MUSTs I listed >> above. Whether the project should look to generate those files at >> build/testing time depends on circumstances. In most cases I would >> expect them to be generated during building/testing but there can be >> valid reasons for not doing so. >> >> Mark >> >> >> >> >>> >>> [1]http://www.apache.org/legal/release-policy.html#what >>> >>> Willem Jiang >>> >>> Twitter: willemjiang >>> Weibo: 姜宁willem >>> >>> --------------------------------------------------------------------- >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
