incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: Binary jars in the source release which are only for testing
Date Mon, 25 Feb 2019 14:15:30 GMT
On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas <> 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?


> 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]
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message