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? 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
