Using maven plugin prevents building from tarball

[dvzrv]

Hi! When packaging 2.0.0 for Arch Linux I realized that the tool can not be built from a tarball of a release as long as there is the git hooks maven plugin in use:

openapi-diff/pom.xml

Lines 290 to 294 in ed6345e

	<plugin>
	<groupId>io.github.phillipuniverse</groupId>
	<artifactId>githook-maven-plugin</artifactId>
	<version>1.0.5</version>
	</plugin>

openapi-diff/pom.xml

Lines 349 to 366 in ed6345e

	<plugin>
	<groupId>io.github.phillipuniverse</groupId>
	<artifactId>githook-maven-plugin</artifactId>
	<executions>
	<execution>
	<goals>
	<goal>install</goal>
	</goals>
	<configuration>
	<hooks>
	<pre-commit>
	mvn com.coveo:fmt-maven-plugin:format
	</pre-commit>
	</hooks>
	</configuration>
	</execution>
	</executions>
	</plugin>

As this seems to be only for code formatting, is it possible to circumvent its use (aside from removal), when using mvn clean install?

[joschi]

You can disable the githook-maven-plugin by setting the system property githook.plugin.skip to false.

https://github.com/phillipuniverse/githook-maven-plugin#additional-configuration-options

[joschi]

@dvzrv Why would you build the project from scratch when you could download the official JAR from Maven Central? It's not like your byte code would be any different.

• https://search.maven.org/artifact/org.openapitools.openapidiff/openapi-diff-cli/2.0.0/jar
• https://repo1.maven.org/maven2/org/openapitools/openapidiff/openapi-diff-cli/2.0.0/

[dvzrv]

You can disable the githook-maven-plugin by setting the system property githook.plugin.skip to false.

Thanks, I will look into that! :)

Why would you build the project from scratch when you could download the official JAR from Maven Central?

We generally build everything (that we can) from source. This allows for reproducibility and not being affected by supply chain attacks on a binary repository such as maven central or a compromised build infrastructure in which the official jar is being built.
Furthermore Arch Linux invests into having reproducible builds for all of its packages.

It's not like your byte code would be any different.

In fact, it would be, because maven builds are usually not bit-by-bit reproducible, unless configured so (for this purpose strip-nondeterminism is currently used to strip the resulting jar from nondeterministic strings such as timestamps).

[joschi]

In fact, it would be, because maven builds are usually not bit-by-bit reproducible

Yeah, I've heard that one before. 😉
dropwizard/dropwizard@c9158ff

[joschi]

@dvzrv This issue should've been resolved via #300 and #301.