Thanks for taking a look at this! Comments inline below:
On Wed, 30 Jul 2025 at 19:20, Hervé Boutemy<hbout...@apache.org> wrote:
thanks for sharing this step: useful to study simple code
forcing user to do "mvn install myplugin:mygoal" instead of "mvn deploy"
is
cheating :)
notice that it opens an idea: Sonatype plugin could be used that way, that
would be less tricky inside Maven, that could work with Maven 4
but I really hoped that we could do something in deploy:deploy that is
bound
to the deploy phase
I agree but as an initial attempt, I wanted to isolate it.
We can absolutely integrate it closer to make it happen when we do maven
deploy. Should the current deploy still work as is and we add an extra flag
to determine which "mode" we publish with or should we change the way
deploy works to only use the new publish process?
on uploading module (sub-project) per module, it's definitively a no go:
having
10s or even 100s of modules happens a lot, we need to do a single bundle
= what the existing deployAtEnd option prepares quite well for
Yes, I am working on a mega bundle using exactly that logic. There is a
size limit on the bundle of 1 GB so I think it would be useful to have the
"deploy each module separately" as an option.
reading the code, I finally understood one key aspect:
we need to create a bundle, that one I knew
but what I got is that the bundle is not PUT like deploy usually does with
http: it is POSTed
so in addition to adding an option to create a bundle instead of deploying
each file separately, we'll also need to add an option to not PUT file but
HTTP
POST, with url and all Maven Central-specific data being in POM
distributionManagement
Yes, it's not even the common "post with attachment" but post as
multipart...
We already have the url param in distribution management and the
username/token is retrieved from the settings based on the id so that is
all good. The question is if we want
a parameter in distributionmanagement or in the plugin config to give the
user an alternative to deploy as it works today or deploy using the new
central api?
Best regards,
Per
I'm sure it is feasible, I just did not have time to dive in deploy:deploy
code sufficiently yet...
Le lundi 28 juillet 2025, 21:52:55 CEST Per Nyfelt a écrit :
Hi,
I have a proof of concept working here:
https://github.com/perNyfelt/maven-deploy-plugin/tree/add_central_support
(the code can be much better integrated with the existing plugin, this
is just a PoC).
I used it to successfully uploaded and validate this project to central:
https://github.com/perNyfelt/maven-central-publishing-example
using ` mvn -DautoDeploy=false clean install deploy:publish`
(the autodeploy flag is set to false so it only does the upload and
waits at central for an action i.e. to be dropped or published manually)
There is also a bundle step that creates the zip and also does some
validation (so you don't have to actually try to upload the bundle to
central to get feedback) that can be invoked separately with ` mvn
-DautoDeploy=false clean verify deploy:bundle`
Anyway, the deploy:publish deploys 4 bundles to central:
1. The aggregator project containing the pom (+ asc, md5, sha-1 and
sha-256)
2. common containing jar, source, javadoc and pom (+ asc, md5, sha-1 and
sha-256)
3. subA (that depends on common) containing jar, source, javadoc and pom
(+ asc, md5, sha-1 and sha-256)
4. subB (that depends on common) containing jar, source, javadoc and pom
(+ asc, md5, sha-1 and sha-256)
I will see if i can add an support for the "deployAtEnd" flag to create
a mega-bundle instead and upload that.
One thing that i found a little tricky is that we don't deploy the
effective pom but rather the original pom (at least that's the one that
is signed so that's the only readily available choice) and the central
validation rules requires the license, developer, description and scm
sections to be present. In the effective pom these are inherited from
the parent but the validation logic in central does not care about that
and rejects the deploy unless they are explicitly present. Maybe the
validation will work differently in the mega-bundle. I'll will
investigate...
Best regards,
Per
On 7/22/25 19:16, Hervé Boutemy wrote:
one first step we could try could be adding a "deployToBundle"
parameter
to the deploy plugin, that would trigger an "at end" behaviour that
would
build a zip with all the deferred files, instead of copying each file
separately
then see how just sending the bundle to the target (file: or https: or
scp: or ...) would do the job
this could be a minimalistic approach, that would have the benefit of
showing "bundle vs individual deploy" approaches
njord is that approach on steroids = really manage a local staging area
(or name it as you want) and decide in a separate plugin where to put
the
staging area content and in which detailed format (PUT individual
files,
send everything as a unique archive, split the archive in smaller ones,
or any future strategy)>
On 2025/07/22 12:14:28 Per Nyfelt wrote:
It CAN be deployed as a single zip but it does not have to be. The
downside
of deploying each module separately is that if one deployment fails
then
you end up with a "partial" deploy (from the point of view of the
whole
project) but I think you only end up in this situation in the
beginning
when you have not configured everything properly. If we do internal
validation first (check that an asc, md5 and sha1 accompanies each
artifact) then this kind of error can be eliminated. What remains
would
then be network errors in which case you would just deploy the failed
module again.
Regards,
Per
On Tue, 22 Jul 2025 at 13:25, Guillaume Nodet<gno...@apache.org>
wrote:
And I think that's exactly the problem as the deployment needs to be
a
single zip file IIUC.
Guillaume
Le mar. 22 juil. 2025 à 12:28, Per Nyfelt<per.nyf...@nordnet.se> a
écrit
Hi Tamas,
I think it would work. Each part is zipped up and deployed e.g.
assuming
you have a multimodule project like this:
Aggregator
- common
- subA (depends on common)
- subB (depends on common)
Deploying all of this would mean 4 zip files are created and
published
1. The aggregator is just the pom (+ asc, md5 and sha1)
2. common is the pom, jar, javadoc and sources (all signed and with
md5
and
sha1 files)
3. subA is the pom, jar, javadoc and sources (all signed and with
md5
and
sha1 files)
4 subB is the pom, jar, javadoc and sources (all signed and with md5
and
sha1 files)
That should work fine i think or am i missing something?
Regards,
Per
On Tue, 22 Jul 2025 at 11:13, Tamás Cservenák<ta...@cservenak.net>
wrote:
Per,
You cannot publish to central using plugin bound to lifecycle as it
will be
invoked in every module/subproject... Portal needs "at end; all
artifacts"
kind of operation and Maveniverse Njord does that without
interference
to
your build.
Maven4 has improved lifecycle with "after:all" but Maven3 does
not, it
needs a bit more.
T
On Tue, Jul 22, 2025, 11:07 Per Nyfelt<per.nyf...@nordnet.se>
wrote:
Hi,
How about adding a deployToCentral (or similar) goal to the
maven-deploy-plugin that uses the new API so that this is
supported
"natively"?
I would be willing to implement it if you think it's a good idea.
Regards
Per
On Tue, 22 Jul 2025 at 10:39, Jon Harper<jon.harpe...@gmail.com>
wrote:
Hi Hervé,
thanks for looking into it. Did you try the sonatype
compatibility
service ?
https://central.sonatype.org/publish/publish-portal-ossrh-staging-api
Also, while the governance and roadmap of
central-publishing-maven-plugin is not open, the code itself is
OSS
(uses the apache license v2 as indicated in the pom
https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-m
aven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom>>>
)
Cheers,
Jon
On Sat, Jul 19, 2025 at 10:13 PM Hervé Boutemy <
hbout...@apache.org>
wrote:
deep dive done, with personal evaluation
https://github.com/apache/maven-studies/tree/deploy
happy to discuss and complete the review
Le jeudi 17 juillet 2025, 03:53:40 CEST Hervé Boutemy a écrit :
I finally stopped procrastinating and took time to test
https://github.com/apache/maven-studies/tree/deploy
This does not yet give me a strong answer about what I
personally
would
choose to promote, but at least better understanding of the
misc
options
Le mardi 8 juillet 2025, 08:45:25 CEST Hervé Boutemy a écrit :
it seems we're back to Maven history of:
1. publication to simple file systems (eventually shared)
2. multi-module (aka. multi-subproject) publication
3. multi-file publication in a single gav
On the positive side, this has been very flexible and
perfect for
downloads. But on the negative side, this leads to quite
undefined
publication protocol, and misunderstood, even when we tried
to
share
some
doc
https://maven.apache.org/repository/layout.html
In the past, the complaint was that there was no "standard"
REST
API
to
publish (ignoring that REST did not exist when Maven was
growing).
Now there is a REST API with proper documentation
https://central.sonatype.com/api-doc
We could expect everybody to be happy, but no.
We are discovering it is perfect for smaller publications.
But it opens questions for bigger publications.
And yes, we're still in a half undocumented mix of approaches
(Maven-native
per-file PUT vs REST API for publishing an archive vs how to
split
multi-
module?)
Reading Njörðr description
https://maveniverse.eu/docs/njord/what-is-it/,
it is a Maven Resolver Repository Connector, looks like a
good
integration
in the native Maven CLI: please call it something like
"Njörðr
publisher"
and I may remember what it does...
I definitively need to dive into it: very interesting.
And next spte will be to have a wider community understand
all
these
concepts, as beginning of all the issues is that we're
touching
many
in-depth aspects that are unknown to many.
One additional TODO on my ever growing TODO list...
Regards,
Hervé
Le lundi 7 juillet 2025, 16:48:39 CEST Tamás Cservenák a
écrit :
Howdy,
Cool that you brought up this topic, thanks!
Well, for start, to not repeat myself, a bit of history:
https://maveniverse.eu/blog/2025/07/02/pom-proliferation-part-1/
(note: this is in fact a response to completely unrelated
blog
entry,
but is good to "cover the grounds" for now)
In short: what today happens with Maven Central (MC) is
totally
out of
scope of ASF Maven Project, that created it.
What I also find ironical (or sad) is that project
"causing" MC
lost
native access to it (while with Nx2 ran OSS/S01 you could
use
m-deploy-p just fine, from now on, you cannot).
Hence, there is no "native" or "out of the box" support for
publishing
for Maven right now.
As you know, there are some solutions offered, that are all
problematic for me as well:
- they either "reinvent" (or force you to) reconfigure
whole
world
again
- or meddle with your build and have different
requirements you
need
to implement
Hence, the thing I'd recommend from maveniverse is Njord:
https://maveniverse.eu/docs/njord/
That basically (re) implements what Nx2 had, but locally
and
adds
publishing support as well.
This extension was done to fully container all the issues
above:
- is not "aggressive", literally steps aside
- does not require to reconfigure your whole build (you can
publish
even non integrated projects with it)
- uses Maven and is Maven "native", no parallel worlds
Of course, Njord does not help with cases like TrinoDB has
(that
is
Central Portal server side limitation),
and many other things, but is working for many other
projects.
Also, as you mentioned, I created this issue (as Njord
suffers
from it
as
well):https://github.com/maveniverse/njord/issues/150
HTH
Tamas
On Sun, Jul 6, 2025 at 2:37 PM Jon Harper <
jon.harpe...@gmail.com>
wrote:
Hi everyone,
I think it would be very beneficial for the community
that
the
maven
dev team communicates on the current events of the
sunset of
OSSRH.
Otherwise, I think there is a big risk of uncertainty and
division in
the community.
Quoting Romain (
https://lists.apache.org/thread/bf3762lvd8l64hwyny7rnp3m6r852b9h
)
from a year ago
"most of us using central outside the asf will be
impacted
sometime
next year probably"
And now this time has come (note: I shamefully
procrastinated
the
ossrh migration until I was forced to, but like many
people I
guess..). Unfortunately, it coincides with the last
stages of
the
maven 4 release, so I understand that everyone is very
busy
at
the
moment.
Maven is a tool that communicates with the outside
world, so
I
would
think it's legitimate for the maven devs to publicly
express
their
guidelines. Unfortunately it's not an easy task (as a
matter
of
fact,
the best resource I currently know for this is the
personal
blog
of
Karl Heinz Marbaise), but maybe an email discussion can
lay
enough
foundations by gathering many opinions so that a coherent
message can
be sent to the community ?
Aggravating factors in central-publishing-maven-plugin
that
lead
to
uncertainty according to me:
- Similarity with the standard maven-deploy-plugin.
Sonatype
even has
a compatibility service but its use is discouraged ("We
hope
that over
time plugins will adopt the Portal API rather than rely
on
this
service" in
https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/
).
- No public scm system available makes it hard to get
context
information (
https://repo1.maven.org/maven2/org/sonatype/central/central-publishing
-m
a
ven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom
lists
https://github.com/sonatype/central-publishing-maven-plugin
but
is
404).
(Note: The code is still available in the source jar
alongside the plugin
https://repo1.maven.org/maven2/org/sonatype/central/central-publishing
-m
av
en-plugin/0.8.0/central-publishing-maven-plugin-0.8.0-sources.jar )
- central-publishing-maven-plugin uses
<extension>true</extension> to
forcefully remove any invocation of the
maven-deploy-plugin
which I
found surprising (aggressive ?) behavior.
- impossible as of 0.8.0 to use
central-publishing-maven-plugin
behind
a corporate proxy which ( by virtue of the http client5
of
apache
httpcomponents without the extra code required to allow
proxies
...)
- looks like fighting instead of cooperating (even
though the
plugin
architecture of maven invites this kind of work, maybe
it's
better
when core functionality stays within the maven umbrella
like
the
maven-deploy-plugin?)
What are your thoughts ? Are the recent improvements to
the
maven-deploy-plugin strong enough the try and unite all
publishing
plugins as one ?
Cheers,
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@maven.apache.org
For additional commands, e-mail:dev-h...@maven.apache.org
