On Mon, Feb 25, 2019 at 3:28 PM Mark Thomas <ma...@apache.org> wrote: > > 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.
By and large -- yes. IOW, for every magic binary there has to be a good reason. Sometimes that reason actually exists (like my handcrafted JAR example or an image file that was created in Gimp but its not like there's a "source" for it). > The "source" may be the source as > in the input to a compiler. Which is covered by your point #1 -- you disable tests -- you should be able to build the release purely from source. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
