WiP io.opentelemetry.semconv:opentelemetry-semconv:1.29.0-alpha

[ppalaga]

This is a Gradle project rebuild.sh seems to have hard time to rebuild it and I am not quite sure what is wrong. Any hints would be appreciated.

[github-actions]

• wip/opentelemetry-semconv-1.29.0-alpha.buildspec io.opentelemetry.semconv:opentelemetry-semconv

groupId=io.opentelemetry.semconv
artifactId=opentelemetry-semconv
display=${groupId}:${artifactId}
version=1.29.0-alpha

gitRepo=https://github.com/open-telemetry/semantic-conventions-java.git
gitTag=v1.29.0

tool=gradle
jdk=17
newline=lf
#umask=022

builtBy=runner
builtJDK=17.0.13

command="./gradlew publishToMavenLocal -x test -x javadoc"
buildinfo=${artifactId}-${version}.buildinfo

#diffoscope=${artifactId}-${version}.diffoscope
issue=

[hboutemy]

rebuild.sh script requires publishToMavenLocal, not publish, as this is in Maven local directory that it will look for output files in Maven repository format

[hboutemy]

building with

tool=gradle
jdk=17
newline=lf
#umask=022

command="./gradlew publishToMavenLocal -x test -x javadoc"
buildinfo=${artifactId}-${version}.buildinfo

works

[hboutemy]

you will probably need the builtJDK trick like
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/opentelemetry/java/opentelemetry-sdk-1.58.0.buildspec

[ppalaga]

rebuild.sh script requires publishToMavenLocal, not publish, as this is in Maven local directory that it will look for output files in Maven repository format

Thanks, good to know. Is it the same with Maven projects? rebuild.sh expects installing to local Maven repo? How do you know which artifacts come from the build? I wonder whether running mvn deploy with -DaltDeploymentRepository=... is not easier/safer for this kind of use case?

[ppalaga]

Thanks, @hboutemy, I have followed your advices and now it builds resulting in

stabilize_ok=4
stabilize_ko=0

Would that mean, it is now worth to move it to content?

you will probably need the builtJDK trick like
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/opentelemetry/java/opentelemetry-sdk-1.58.0.buildspec

I was hoping that

builtBy=runner
builtJDK=17.0.13

would fix the diffs in MANIFEST.MF but it does not seem to change anything. Am I doing something wrong?

[hboutemy]

Is it the same with Maven projects? rebuild.sh expects installing to local Maven repo?

no, for Maven, I wrote artifact:compare that does more advanced work as a Maven plugin goal for ease of use, independently from rebuild.sh
For Gradle, I'm not able to do the same

[hboutemy]

would fix the diffs in MANIFEST.MF but it does not seem to change anything. Am I doing something wrong?

I suppose the Gradle build config has to be written in a way that it can use external value: as anything in Gradle, the project has to code its use cases (rebuilding from a third party does not seem to be a practice that the build tool tries to help)

I have limited knowledge in Gradle, and no time nor fun trying to improve it

[ppalaga]

no, for Maven, I wrote artifact:compare that does more advanced work as a Maven plugin goal for ease of use, independently from rebuild.sh

I wonder whether this approach does not cause reproducibility issues in some cases? Projects' release process usually includes the Maven deploy phase and there might be projects having mojos impacting the output bound to some of the phases after package. But maybe this is just a theory and this kind of problem did not occur on reproducible central yet?

[ppalaga]

would fix the diffs in MANIFEST.MF but it does not seem to change anything. Am I doing something wrong?

I suppose the Gradle build config has to be written in a way that it can use external value: as anything in Gradle, the project has to code its use cases (rebuilding from a third party does not seem to be a practice that the build tool tries to help)

I have limited knowledge in Gradle, and no time nor fun trying to improve it

Yeah, that's my experience too - it is very hard to work with Gradle "from outside". Injecting one's own code into third-party gradle scripts is not easy either due to lack of reliable standards and changes in Gradle API.