Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

Paul Hammant-3
I can't find where the HTTP-PUT logic is for deployment of Maven artifacts
to remote repos.

I was looking in 'maven-deploy-plugin' and 'maven-artifact-transfer' but
could not see the logic that pushes artifacts up to maven-central (or any
other properties-specified repo).

I'm wanting to play with the code and make an enhancement. No guarantees
it'd get accepted back of course. My goal of writing the code and tests
feels quite simple, but I'm stymied by not knowing where this logic is.
Pseudocode:

calc jar sha1 & md5
calc pom sha1 & md5
push up jar & pom and their md5 & sha1
if sources exist {
    calc sources sha1 & md5
    push up sources jar and its md5 & sha1
}
if javadoc exist {
    calc javadoc sha1 & md5
    push up javadoc jar and its md5 & sha1
}


Well, I forget the sig file too, but you get what I'm after. Does anyone
know which repo/plugin this is in?

- Paul
Reply | Threaded
Open this post in threaded view
|

Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

Paul Hammant-3
I'm still clicking around trying to find the piece of code I'm interested
in. I've found

MessageDigest(string).getInstance(“SHA-1”).update(various), but not
succinctly how it links to the upload/publish process.


I've already made the change I want for GraknLab's
"bazel-distribution" (Python) bazel rule for publishing to maven central (
commit
<https://github.com/TrunkBasedDevelopment/bazel-distribution/commit/3088b69bb95f0c222d1fd50ac3efc8e464d99c30>)
and also for the official bazel rule "rules_jvm_external" for the same (
commit
<https://github.com/TrunkBasedDevelopment/rules_jvm_external/commit/829879d87bfeabb99acc6f31ef9a8f6f8f6113fe>
-
Java). Those were 80 and 100 LoC changes.  The Python one (of course) is
closest to the pseudocode I wrote above.


Maybe my alternate approach to making the same change (my own forks) is
adding a breakpoint the actual upload method and working backwards to note
all the moving parts and work out how many method signatures would need to
change in multiple abstractions/impls and module's to achieve this.


What's the 2021 best-practice for cloning all core maven modules in one go,
and loading that all into Intellij meaningfully.  It is not svn co
http://svn.apache.org/repos/asf/maven/trunk/ anymore is in?


- Paul
Reply | Threaded
Open this post in threaded view
|

Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

Paul Hammant-3
In reply to this post by Paul Hammant-3
Relates to Trunk-Based Development (I maintain
https://trunkbaseddevelopment.com) . Some of my clients do "branch for
release". Every cherry pick from trunk to the release branch (bug fix)
would wake up Jenkins. By default that'd do a full build and then artifacts
get pushed into artifactory/nexus and from there a deployment into UAT -
bouncing whichever services have been changed.

The build pass/fail gate will fail though, *if* the versions (in the POMs)
have been published already - Nexus/Artifactory will  correctly object.
What I want to do is effect a system that *only the changed modules *will
be blocked on a second publication attempt. Unchanged ones will be skipped
for publication. Say there were 100 modules (services, applications, their
deps) that the build would compile/test. If there were a bug fix to just
one module, I would want Jenkins to note the failing publication attempt
for that one only.  If builds are reproducible (hard for Maven I realize *)
then the SHA-1 of the binary can guide whether it needs to go to the
remote repo or be skipped. The pseudocode covers that. The release engineer
would then change *one* POM version (say 4.3.0 to 4.3.1) in the release
branch, commit, Jenkins is triggered, full build - but only one changed
item gets pushed up to the remote binary repo - to a new GAV - and all
others are skipped.

"Branch for release" within trunk-based development is just one way of
working and suits a range of release cadences for teams.

* https://maven.apache.org/guides/mini/guide-reproducible-builds.html

- Paul