incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Binary jars in the source release which are only for testing
Date Mon, 25 Feb 2019 14:33:17 GMT
On Mon, Feb 25, 2019 at 3:28 PM Mark Thomas <markt@apache.org> wrote:
>
> On 25/02/2019 14:15, Roman Shaposhnik wrote:
> > On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas <markt@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-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message