incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Binary jars in the source release which are only for testing
Date Mon, 25 Feb 2019 10:35:15 GMT
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
- the source for any compiled files included in the source MUST be
  provided alongside the compiled files

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.


> [1]
> Willem Jiang
> Twitter: willemjiang
> Weibo: 姜宁willem
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message