You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Hammant <pa...@hammant.org.INVALID> on 2021/01/09 17:03:45 UTC
Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
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
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
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
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-01-09 um 18:03 schrieb Paul Hammant:
> 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?
What is the purpose of your request? I know Wagon in and out and
Resolver quite well know.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
Thanks Tamás
After building that all, Is there a trick to instantiating mvnDebug using
those snapshots ?
- Paul
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Simplest is to clone (in gh) these reposes to your user
https://github.com/apache/maven
https://github.com/apache/maven-resolver
https://github.com/apache/maven-wagon
Then clone them from there to your machine (git clone). I usually add
"upstream" remote (git remote add upstream ...) that points back to
original apache reposes, is easier to track them later (fetch -p, rebase
upstream/master).
Finally, in idea just create empty new project, and import modules by
pointing idea at top level pom of each project.
Hth
T
Ps: am on phone, so bear with me if mistakes present
On Sun, Jan 10, 2021, 11:37 Paul Hammant <pa...@hammant.org.invalid> wrote:
> 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
>
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
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
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
Thanks for that. Me 15 years ago would have know the answer as bells are
ringing now :)
Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
well, it's not so simple, is buried under layer and layers of
abstraction... you did start on good place, but it is actually something
like
m-deploy-p -> m-artifact-transfer -> maven-resolver ->
maven-resolver-connector (usually wagon) -> HTTP wagon
So if you are literally after code "where the HTTP-PUT logic is", wagon is
the place....
HTH,
T
On Sat, Jan 9, 2021 at 6:04 PM Paul Hammant <pa...@hammant.org.invalid>
wrote:
> 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
>