Feature #5746


Bypass jar signing during build in case of HE

Added by E L 2 months ago. Updated 2 months ago.

Build and release
Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


The console output emerging when building HE includes the following:

Expecting Saxon license file to be in <homedir>/java
Build is not configured to sign jar files
Build is not configured to sign executable files

It would appear that these messages are innocuous, as the HE will be intentionally built unsigned.

However, the message may alarm someone without sufficient background to disregard it. Fortunately, it would be easy to avert, by adding an auxiliary properties file to the various repositories such that the signing behavior may be selectively disabled in the case of HE. Alternatively, other means may be considered for detecting whether the build case is HE. Such recommendation is based on the understanding, from documentation, that the build scripts themselves are maintained the same in the case of HE as in others.

Meanwhile, it might be considered more generally that the overall projects be structured with HE given as a build dependency for advanced versions, to simplify the administrative overhead, by avoiding synchronization of build scripts and other parts of the code base across various repositories.

Actions #1

Updated by Michael Kay 2 months ago

We do tend to work on the assumption that only the most expert of users are going to attempt to build the product from source, Making it easier is not the highest thing on our list of priorities. In fact my usual reaction to questions like this is to ask why people felt the need to build from source, and should we be adding some configuration property or customisation option so they don't need to?

Actions #2

Updated by E L 2 months ago

The discussion appears to represent a variety of differences in orientation, which may exceed the scope of the discussion, but the most glaring difference is calling into question the reason for building from source. Most would not object to sharing individual reasons for doing so in any particular case, and nuanced debate may be helpful over whether one or another individual improvement is worth the investment, but the objective in principle seems plain to my mind of supporting the possibility of building with minimal unwarranted encumbrance, if the project is meaningfully conceived as open source.

Actions #3

Updated by Michael Kay 2 months ago

I'm not "calling into question" your reason for wanting to build from source, I'm asking why you want to do it because we want to make users' lives easier and if users have to build from source rather than just putting the JAR files on the classpath then to my mind we've failed to make the product customisable enough.

You're right that we don't buy into the "religion" of open source in the FSF sense. We have a very successful business model, based on having an excellent open source product and an even better commercial product, which has enabled us to continue developing Saxon for over twenty years while nearly all other products in the same space have stagnated, and we believe that hybrid model has served the user community well. 99% of the users of Saxon-HE never download or compile the source code, which explains why we've never put a large investment into making life easy for the 1% who do. Open source has served us well as a way of reaching (and getting feedback from) a far larger user community than we could reach otherwise, but for us it's part of a business model, not an end in itself.

Actions #4

Updated by E L 2 months ago

Perhaps my thought was that if the build process were more accessible, then it would contribute to enthusiasm about the project, and lower the incidence of support requests. For many businesses, as you know, the relationship is much more cozy between an open-source model and a business model, in comparison to what I have understood from your comments. I submitted the report because I have previously experienced that many project maintainers have been encouraged by ones like it.

Of course I would not seek, and have not sought, to critique your ideology, or any lack of it, however you may like to put it, compared to another, but "open source" as a term generally emphasizes a scenario in which a consumer, anyone among the public with suitable interest, equipment, and expertise, may interact with a project, through its source code, in a way comparable to the interaction as by an original or subsequent creator. Such a model often will flourish even in the business context enclosing both community and commercial editions.

If the emphasis is on distribution of compiled binaries, as for use by linking in applications, without any intention to facilitate testing, integration, modification, and similar activities with the full gamut of possibilities allowed by distribution under an open license, then perhaps it would be most helpful to adopt a different characterization of the project, rather than "open source". Again, I am not critiquing, as much as sharing my views of how various terms are received among the broader community.

A greater portion of the public obviously will consume binaries compared to source, but consumption of source often carries an intention of creating further binaries for distribution. The relative rate of consumption of source versus binaries is not a good measure of aggregate value for all potential, ultimate beneficiaries of a project, in case such a metric was implied.

Perhaps I am sounding pedantic, or interpreting your comments poorly.

Actions #5

Updated by E L 2 months ago

The reason for preferring building from source is not due to any known functional inadequacy of the binaries, but rather the nature of the target system, as one generated from scratch.

Please register to edit this issue

Also available in: Atom PDF