[DISCUSS] Release maven-shade-plugin 3.3.1?
Hi, The latest release of m-shade-p happened in March 2022 and now about half a year passed. We have some dependencies bump and one bug fix MSHADE-425[1]. As the author of the patch to MSHADED-425, I made it to resolve one or several downstream troubles as described in the ticket. Now I'm looking forward to a new release and I'll upgrade the downstream dependencies for this fix. As suggested by the reviewers, I come here to see if there's a volunteer release manager. I'm happy to verify the release candidate :) Best, tison.
Re: [DISCUSS] Release maven-shade-plugin 3.3.1?
Thank you! Best, tison. Karl Heinz Marbaise 于2022年9月6日周二 17:44写道： > Hi, > > I will try to do a release on the weekend... > > Kind regards > Karl Heinz Marbaise > On 06.09.22 10:55, tison wrote: > > Hi, > > > > The latest release of m-shade-p happened in March 2022 and now about > half a > > year passed. We have some dependencies bump and one bug fix > MSHADE-425[1]. > > > > As the author of the patch to MSHADED-425, I made it to resolve one or > > several downstream troubles as described in the ticket. Now I'm looking > > forward to a new release and I'll upgrade the downstream dependencies for > > this fix. > > > > As suggested by the reviewers, I come here to see if there's a volunteer > > release manager. I'm happy to verify the release candidate :) > > > > Best, > > tison. > > > >
Re: [DISCUSS] Release maven-shade-plugin 3.3.1?
Hi, Bump this thread as a kind reminder ;) Best, tison. Romain Manni-Bucau 于2022年9月6日周二 21:51写道： > Le mar. 6 sept. 2022 à 15:45, Delany a écrit > : > > > Just to add, IntelliJ's tooltip links to > > https://maven.apache.org/ref/2.2.1/maven-model/maven.html > > Where is it getting v2.2.1 from? > > > > > > https://github.com/JetBrains/intellij-community/blob/522209df34f7266923df5133f9b50b226054412a/plugins/maven/src/main/java/org/jetbrains/idea/maven/dom/MavenModelDocumentationProvider.java#L41 > > > > The plugin depends on v3.1.1 ( > > > > > https://github.com/apache/maven-shade-plugin/blob/maven-shade-plugin-3.3.0/pom.xml > > ) > > Delany > > > > On Tue, 6 Sept 2022 at 15:35, Romain Manni-Bucau > > wrote: > > > > > Hi, > > > > > > It is a generic maven issue, on intellij side it is mainly a matter of > > > checking the expceted model and enhance the completion > 2 levels (not > > > supported as of today - actually 1 level or 2 for containers like > lists). > > > On maven side I guess supporting xsd for the plugin configuration can > > help > > > there (could be generated by the maven-plugin-plugin tooling). > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > Le mar. 6 sept. 2022 à 15:31, Delany a > > écrit > > > : > > > > > > > While we're talking about shade, I noticed if I spell a tag wrong > > neither > > > > `mvn validate` nor IntelliJ take issue with my tag > > > > > > > > maven-shade-plugin > > > > > > > > > > > > default > > > > pre-integration-test > > > > > > > > > > > > > > > > software.amazon.awssdk:ecr > > > > > > > > And it builds! > > > > How can this situation be improved? > > > > > > > > Kind regards, > > > > Delany > > > > > > > > On Tue, 6 Sept 2022 at 13:25, tison wrote: > > > > > > > > > Thank you! > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > > > > > > Karl Heinz Marbaise 于2022年9月6日周二 17:44写道： > > > > > > > > > > > Hi, > > > > > > > > > > > > I will try to do a release on the weekend... > > > > > > > > > > > > Kind regards > > > > > > Karl Heinz Marbaise > > > > > > On 06.09.22 10:55, tison wrote: > > > > > > > Hi, > > > > > > > > > > > > > > The latest release of m-shade-p happened in March 2022 and now > > > about > > > > > > half a > > > > > > > year passed. We have some dependencies bump and one bug fix > > > > > > MSHADE-425[1]. > > > > > > > > > > > > > > As the author of the patch to MSHADED-425, I made it to resolve > > one > > > > or > > > > > > > several downstream troubles as described in the ticket. Now I'm > > > > looking > > > > > > > forward to a new release and I'll upgrade the downstream > > > dependencies > > > > > for > > > > > > > this fix. > > > > > > > > > > > > > > As suggested by the reviewers, I come here to see if there's a > > > > > volunteer > > > > > > > release manager. I'm happy to verify the release candidate :) > > > > > > > > > > > > > > Best, > > > > > > > tison. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Release maven-shade-plugin 3.3.1?
I notice the release process happened on the repository. Thank you! If you need a volunteer to verify the release candidate or any help, please let me know :) Best, tison. tison 于2022年9月10日周六 17:16写道： > Hi, > > Bump this thread as a kind reminder ;) > > Best, > tison. > > > Romain Manni-Bucau 于2022年9月6日周二 21:51写道： > >> Le mar. 6 sept. 2022 à 15:45, Delany a >> écrit : >> >> > Just to add, IntelliJ's tooltip links to >> > https://maven.apache.org/ref/2.2.1/maven-model/maven.html >> > Where is it getting v2.2.1 from? >> > >> >> >> >> https://github.com/JetBrains/intellij-community/blob/522209df34f7266923df5133f9b50b226054412a/plugins/maven/src/main/java/org/jetbrains/idea/maven/dom/MavenModelDocumentationProvider.java#L41 >> >> >> > The plugin depends on v3.1.1 ( >> > >> > >> https://github.com/apache/maven-shade-plugin/blob/maven-shade-plugin-3.3.0/pom.xml >> > ) >> > Delany >> > >> > On Tue, 6 Sept 2022 at 15:35, Romain Manni-Bucau > > >> > wrote: >> > >> > > Hi, >> > > >> > > It is a generic maven issue, on intellij side it is mainly a matter of >> > > checking the expceted model and enhance the completion > 2 levels (not >> > > supported as of today - actually 1 level or 2 for containers like >> lists). >> > > On maven side I guess supporting xsd for the plugin configuration can >> > help >> > > there (could be generated by the maven-plugin-plugin tooling). >> > > >> > > Romain Manni-Bucau >> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > > <https://rmannibucau.metawerx.net/> | Old Blog >> > > <http://rmannibucau.wordpress.com> | Github < >> > > https://github.com/rmannibucau> | >> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> > > < >> > > >> > >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > > > >> > > >> > > >> > > Le mar. 6 sept. 2022 à 15:31, Delany a >> > écrit >> > > : >> > > >> > > > While we're talking about shade, I noticed if I spell a tag wrong >> > neither >> > > > `mvn validate` nor IntelliJ take issue with my tag >> > > > >> > > > maven-shade-plugin >> > > > >> > > > >> > > > default >> > > > pre-integration-test >> > > > >> > > > >> > > > >> > > > software.amazon.awssdk:ecr >> > > > >> > > > And it builds! >> > > > How can this situation be improved? >> > > > >> > > > Kind regards, >> > > > Delany >> > > > >> > > > On Tue, 6 Sept 2022 at 13:25, tison wrote: >> > > > >> > > > > Thank you! >> > > > > >> > > > > Best, >> > > > > tison. >> > > > > >> > > > > >> > > > > Karl Heinz Marbaise 于2022年9月6日周二 17:44写道： >> > > > > >> > > > > > Hi, >> > > > > > >> > > > > > I will try to do a release on the weekend... >> > > > > > >> > > > > > Kind regards >> > > > > > Karl Heinz Marbaise >> > > > > > On 06.09.22 10:55, tison wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > The latest release of m-shade-p happened in March 2022 and now >> > > about >> > > > > > half a >> > > > > > > year passed. We have some dependencies bump and one bug fix >> > > > > > MSHADE-425[1]. >> > > > > > > >> > > > > > > As the author of the patch to MSHADED-425, I made it to >> resolve >> > one >> > > > or >> > > > > > > several downstream troubles as described in the ticket. Now >> I'm >> > > > looking >> > > > > > > forward to a new release and I'll upgrade the downstream >> > > dependencies >> > > > > for >> > > > > > > this fix. >> > > > > > > >> > > > > > > As suggested by the reviewers, I come here to see if there's a >> > > > > volunteer >> > > > > > > release manager. I'm happy to verify the release candidate :) >> > > > > > > >> > > > > > > Best, >> > > > > > > tison. >> > > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
Re: [VOTE] Release Apache Maven Shade Plugin version 3.4.0
+1 (non-binding) I tested: * LICENSE and NOTICE present. * MSHADE-425 is included in the release candidate and works well. Best, tison. Karl Heinz Marbaise 于2022年9月11日周日 18:38写道： > Hi, > > We solved 6 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921&version=12351491 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1806/org/apache/maven/plugins/maven-shade-plugin/3.4.0/maven-shade-plugin-3.4.0-source-release.zip > > Source release checksum(s): > maven-shade-plugin-3.4.0-source-release.zip sha512: > > 3470a1316f65b1efff7309a9890f1c4d70ce549919004e682565a62cb204b3925ba325b62818f6fc3390e5aae55fb15b631392965bfc97fc3bf2fafe6e0bc797 > > Staging site: > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [RESULT] [VOTE] Release Apache Maven Shade Plugin version 3.4.0
Thanks for driving this release! Best, tison. Karl Heinz Marbaise 于2022年9月14日周三 23:19写道： > Hi, > > The vote has passed with the following result: > > +1 : tison, Sylwester Lachiewicz, Hervé Boutemy, Slawomir Jaranowski, > Enrico Olivelli, Romain Manni-Bucau, Tamás Cservenák > > > PMC quorum: reached. > > > I will promote the source release zip file to Apache distribution area > and the artifacts to the central repo. > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Request for review: Redirect maven-project-utils notifications away from dev mailing list
Hi, Here is a pull request to address notifications overwhelming the dev@ mailing list: https://github.com/apache/maven-project-utils/pull/6. I received multiple emails from this source these days, so I throw this request on the list for priority. Best, tison.
Re: GitHub release notes ...
Hi, > I agree the source of truth is our jira release notes. I'm new to maven projects here. If the quoted statement is true, what about just set a link to the JIRA release notes for all GitHub release notes. Then the task is eased and we don't maintain multiple pages with full content. ... or the issue is that the absence of release note ifself that our process can easily miss this step? Best, tison. Slawomir Jaranowski 于2023年2月12日周日 23:15写道： > Hi, > > I know the subject is returning again ... > > When we once create GitHub release notes we should maintain it for each new > release ... > I agree the source of truth is our jira release notes. > > In other cases we have missing information about releases and users can be > confused. > > Dependabot uses GitHub releases notes for next PR and we can lose some of > the versions ... like in [1] > > For Maven 3.9.0 we also have no current release notes [2] > probably for other components ... > > [1] https://github.com/mojohaus/mojo-parent/pull/342 > [2] https://github.com/apache/maven/releases > > -- > Sławomir Jaranowski >
Re: Protect master branch
Hi Elliotte, Which repository would you like to add such protection to? With ASF INFRA settings you can check in a .asf.yaml file to control the rule. See https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Branchprotection Best, tison. Christoph Läubrich 于2023年3月5日周日 12:46写道： > If you don't want to rely on branch protection you can do the following: > > > git remote add fork > git remote set-url --push origin no_push > > > > > Am 05.03.23 um 00:55 schrieb Elliotte Rusty Harold: > > Could a repo owner please protect the master branch on github, at > > least for the core project? I accidentally pushed a change to master > > without review or test because I thought I was working on a branch and > > I wasn't. Cleaned up now, I think, but it shouldn't have been possible > > for me to do this. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[QUESTION] Cannot deploy snapshot - do I miss some config?
Hi, https://github.com/apache/incubator-opendal/pull/2301 Here is the branch I'm testing for deploying a snapshot Maven artifact with apache parent pom for an incubating project. When I run it locally by `mvn -X -P apache-release clean deploy`, it fails in the uploading step with log[1]. It seems the 500 error and DEBUG LOG "Downloading from apache.snapshots.https: https://repository.apache.org/content/repositories/snapshots/org/apache/opendal/opendal-java/0.1.0-SNAPSHOT/maven-metadata.xml [DEBUG] Could not find metadata org.apache.opendal:opendal-java:0.1.0-SNAPSHOT/maven-metadata.xml in apache.snapshots.https ( https://repository.apache.org/content/repositories/snapshots)" can be relevant. I don't find some instructions on deploying a snapshot, though. N.B. I first ask in the MPOM project and link the logs there, I don't inline those lines here. I browse all the mailing list and found that users@ has only announcements and other mailing list seems unrelated to this question also. Best, tison. [1] https://issues.apache.org/jira/browse/MPOM-418
Re: [QUESTION] Cannot deploy snapshot - do I miss some config?
Thank you! Then it may not be my config issue. I'll ask the INFRA team and retry later. Since the URL can be opened from the browser, I was wondering if there is something wrong from my side :P Best, tison. Tamás Cservenák 于2023年5月24日周三 14:04写道： > Howdy, > > The Maven deploy failure happened as the remote end (ASF Nexus) responded > with HTTP 500 "Server error". > Please ask infra what happened (was there some known issue to service) or > alike. > > Maven cannot do anything in these cases, this is out of it's reach, and as > the server said "I have a bad day", all it can do is back out from it (and > fail the deploy). > > Thanks > Tamas > > On Wed, May 24, 2023 at 7:48 AM tison wrote: > > > Hi, > > > > https://github.com/apache/incubator-opendal/pull/2301 Here is the branch > > I'm testing for deploying a snapshot Maven artifact with apache parent > pom > > for an incubating project. > > > > When I run it locally by `mvn -X -P apache-release clean deploy`, it > fails > > in the uploading step with log[1]. > > > > It seems the 500 error and DEBUG LOG "Downloading from > > apache.snapshots.https: > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/opendal/opendal-java/0.1.0-SNAPSHOT/maven-metadata.xml > > [DEBUG] Could not find metadata > > org.apache.opendal:opendal-java:0.1.0-SNAPSHOT/maven-metadata.xml in > > apache.snapshots.https ( > > https://repository.apache.org/content/repositories/snapshots)" can be > > relevant. > > > > I don't find some instructions on deploying a snapshot, though. > > > > N.B. I first ask in the MPOM project and link the logs there, I don't > > inline those lines here. I browse all the mailing list and found that > > users@ > > has only announcements and other mailing list seems unrelated to this > > question also. > > > > Best, > > tison. > > > > [1] https://issues.apache.org/jira/browse/MPOM-418 > > >
Re: [QUESTION] Cannot deploy snapshot - do I miss some config?
> is not yet set up (onboarded) Yeah. That can be the case. I don't perform this step. Let me file an INFRA ticket now - maybe they just show me a self-service link, I don't know, lol. Best, tison. Tamás Cservenák 于2023年5月24日周三 14:12写道： > Also, > > As I see, the incubator opendal project is not yet set up (onboarded) on > repository.apache.org (may be wrong, though). > So best bet is to ask #infra on Slack or create infra issue > https://issues.apache.org/jira/projects/INFRA/issues > > Thanks > T > > On Wed, May 24, 2023 at 8:03 AM Tamás Cservenák > wrote: > > > Howdy, > > > > The Maven deploy failure happened as the remote end (ASF Nexus) responded > > with HTTP 500 "Server error". > > Please ask infra what happened (was there some known issue to service) or > > alike. > > > > Maven cannot do anything in these cases, this is out of it's reach, and > as > > the server said "I have a bad day", all it can do is back out from it > (and > > fail the deploy). > > > > Thanks > > Tamas > > > > On Wed, May 24, 2023 at 7:48 AM tison wrote: > > > >> Hi, > >> > >> https://github.com/apache/incubator-opendal/pull/2301 Here is the > branch > >> I'm testing for deploying a snapshot Maven artifact with apache parent > pom > >> for an incubating project. > >> > >> When I run it locally by `mvn -X -P apache-release clean deploy`, it > fails > >> in the uploading step with log[1]. > >> > >> It seems the 500 error and DEBUG LOG "Downloading from > >> apache.snapshots.https: > >> > >> > https://repository.apache.org/content/repositories/snapshots/org/apache/opendal/opendal-java/0.1.0-SNAPSHOT/maven-metadata.xml > >> [DEBUG] Could not find metadata > >> org.apache.opendal:opendal-java:0.1.0-SNAPSHOT/maven-metadata.xml in > >> apache.snapshots.https ( > >> https://repository.apache.org/content/repositories/snapshots)" can be > >> relevant. > >> > >> I don't find some instructions on deploying a snapshot, though. > >> > >> N.B. I first ask in the MPOM project and link the logs there, I don't > >> inline those lines here. I browse all the mailing list and found that > >> users@ > >> has only announcements and other mailing list seems unrelated to this > >> question also. > >> > >> Best, > >> tison. > >> > >> [1] https://issues.apache.org/jira/browse/MPOM-418 > >> > > >
Re: [QUESTION] Cannot deploy snapshot - do I miss some config?
Resolved after INFRA members took action to set up the project. Thank you Tamás for pointing this out! Best, tison. tison 于2023年5月24日周三 14:13写道： > > is not yet set up (onboarded) > > Yeah. That can be the case. I don't perform this step. Let me file an > INFRA ticket now - maybe they just show me a self-service link, I don't > know, lol. > > Best, > tison. > > > Tamás Cservenák 于2023年5月24日周三 14:12写道： > >> Also, >> >> As I see, the incubator opendal project is not yet set up (onboarded) on >> repository.apache.org (may be wrong, though). >> So best bet is to ask #infra on Slack or create infra issue >> https://issues.apache.org/jira/projects/INFRA/issues >> >> Thanks >> T >> >> On Wed, May 24, 2023 at 8:03 AM Tamás Cservenák >> wrote: >> >> > Howdy, >> > >> > The Maven deploy failure happened as the remote end (ASF Nexus) >> responded >> > with HTTP 500 "Server error". >> > Please ask infra what happened (was there some known issue to service) >> or >> > alike. >> > >> > Maven cannot do anything in these cases, this is out of it's reach, and >> as >> > the server said "I have a bad day", all it can do is back out from it >> (and >> > fail the deploy). >> > >> > Thanks >> > Tamas >> > >> > On Wed, May 24, 2023 at 7:48 AM tison wrote: >> > >> >> Hi, >> >> >> >> https://github.com/apache/incubator-opendal/pull/2301 Here is the >> branch >> >> I'm testing for deploying a snapshot Maven artifact with apache parent >> pom >> >> for an incubating project. >> >> >> >> When I run it locally by `mvn -X -P apache-release clean deploy`, it >> fails >> >> in the uploading step with log[1]. >> >> >> >> It seems the 500 error and DEBUG LOG "Downloading from >> >> apache.snapshots.https: >> >> >> >> >> https://repository.apache.org/content/repositories/snapshots/org/apache/opendal/opendal-java/0.1.0-SNAPSHOT/maven-metadata.xml >> >> [DEBUG] Could not find metadata >> >> org.apache.opendal:opendal-java:0.1.0-SNAPSHOT/maven-metadata.xml in >> >> apache.snapshots.https ( >> >> https://repository.apache.org/content/repositories/snapshots)" can be >> >> relevant. >> >> >> >> I don't find some instructions on deploying a snapshot, though. >> >> >> >> N.B. I first ask in the MPOM project and link the logs there, I don't >> >> inline those lines here. I browse all the mailing list and found that >> >> users@ >> >> has only announcements and other mailing list seems unrelated to this >> >> question also. >> >> >> >> Best, >> >> tison. >> >> >> >> [1] https://issues.apache.org/jira/browse/MPOM-418 >> >> >> > >> >
Deploy with multiple platform artifacts build separately
Hi devs, I'm trying to deploy Apache OpenDAL with multiple platform artifacts on its Java binding[1]. Using the ASF Parent POM, I freely get a `mvn -P apache-relase deply` target to make the release - that is great! Although, every time when I execute this command, I can only release for one platform (the one the command runs on). I'd like to release for multiple platforms (said at least for (osx, linux) x (x86_64, aarch_64)), but struggling that I can even build them on different machines. I don't know if I can - 1. Deploy multiple times for the same version; 2. Manually merge artifacts and finally upload those artifacts at once. Existing examples like Netty[2] work against the Sonatype repository, while Apache OpenDAL, IIUC, should work against the ASF repository. Looking forward to your help! Best, tison. [1] https://github.com/apache/incubator-opendal/issues/2313 [2] https://netty.io/wiki/releasing-new-version.html
Re: Deploy with multiple platform artifacts build separately
Thank you Tamas! Then I follow Netty's practice and successfully run the automatically deploy[1][2]. While there are still two issues, they may not be quite related in Maven domain: 1. Distribute Maven and GPG secrets - does Maven support token like password? I'm a bit concerned to convey my text password to even our INFRA member to configure a platform secret. Maybe I can just release locally, but right now I already use GitHub Actions to do multiple platform building and full automation seems reasonable to try. 2. Cross compile for different arch due to the lack of arm64 machine on GitHub Actions. Yes, this is totally unrelated to Maven then :D Maybe how to package two classifier with different config at once is, but there should be multiple workaround. Best, tison. [1] https://github.com/tisonkun/opendal/actions/runs/5082466604/jobs/9132438693 [2] https://github.com/tisonkun/opendal/actions/runs/5082466604/workflow Tamás Cservenák 于2023年5月25日周四 20:23写道： > Howdy, > > Sonatype OSS and ASF Reposes are both Nx2 so the same applies: > > When you deploy for the first time, Nx2 staging creates a staging > repository that is "open". > The created repository will have its own ID and hence, own deployment URL > as well. > > The trick is that this endpoint: > ttps://repository.apache.org/service/local/staging/deploy/maven2 > At the first request this endpoint creates a staging repo (on the fly) and > from that point on, it just routes the incoming request to it, as if those > requests would come in directly to the newly created repository. > > In Nx2 UI, when you click on Staging Repository -> your staging repo (as > you need permission as well to write there), the lower part of the screen > will tell you the URL of the staging repository. > > You can use authenticated HTTP requests (even using curl -X PUT and even -X > DELETE) to MODIFY the content of your staging repository as you wish. > > Once the staging repository is closed, it is "untouchable", no content > changes are possible against it. > > So to answer your questions: > - maven will NOT allow you to perform multiple deploys (see similar problem > https://issues.apache.org/jira/browse/MDEPLOY-118) > - but nothing stops you to use curl or even mvn deploy-file against your > (open) staging repository. > > At the end, there are "rule checks" that contents of staging repository > must pass (like presence of sources, javadoc, hashes and signatures). But > Nx2 will tell you if something is missing. > > HTH > Tamas > > > > On Thu, May 25, 2023 at 2:10 PM tison wrote: > > > Hi devs, > > > > I'm trying to deploy Apache OpenDAL with multiple platform artifacts on > its > > Java binding[1]. > > > > Using the ASF Parent POM, I freely get a `mvn -P apache-relase deply` > > target to make the release - that is great! > > > > Although, every time when I execute this command, I can only release for > > one platform (the one the command runs on). I'd like to release for > > multiple platforms (said at least for (osx, linux) x (x86_64, aarch_64)), > > but struggling that I can even build them on different machines. > > > > I don't know if I can - > > 1. Deploy multiple times for the same version; > > 2. Manually merge artifacts and finally upload those artifacts at once. > > > > Existing examples like Netty[2] work against the Sonatype repository, > while > > Apache OpenDAL, IIUC, should work against the ASF repository. > > > > Looking forward to your help! > > > > Best, > > tison. > > > > [1] https://github.com/apache/incubator-opendal/issues/2313 > > [2] https://netty.io/wiki/releasing-new-version.html > > >
ASF Maven credential in a project-wise token?
Hi, I'm configuring tokens for automatically deploying artifacts to the ASF snapshot repository[1]. It requires configuring a user token to auth to the repository. Although I'm wondering if I must use my personal token or if there is some project-wise token to use. Even asking for an INFRA member to help configure, passing over a personal token to another one increases the risk. Best, tison. [1] https://github.com/tisonkun/opendal/actions/runs/5090173050/workflow#L129
Re: GH issues and GH discussions
As a Maven user experiencing finding issue tracker recently[1][2], here are my two coins: 1. GitHub Issues help to get issues reported at the exact code repo. I found a usage question for ASF parent pom and find the code repo at[3], no GitHub Issues and I jump to the linked JIRA project MPOM, while the maintainer tells me it's not the correct place. I'm familiar with the mailing list way so it's not quite a trouble to ask here. But as time goes on, more and more developers and users get used to the GitHub platform. No matter if it's a good thing, it's a fact[4]. So, for lowering the bar for user participation, I agree we can give GH issues and GH discussions a try. 2. GitHub is a proprietary service that is unreliable in an organization's view. I agree. Part of them can be resolved by we sync all traffic back to an ASF mailing list, like most of the ASF projects I participated in[5]. We can thus archive most of the context but since they are for archiving only, the readability can be bad. To sum up, as new generation developers and users grow and they are more familiar with the GitHub platform, before we find a competitor to compare with, and since we can more or less sync the conversation back to ASF INFRA, I'm +1 for giving GH issue and GH discussion a chance. But, in the other hand, if we can link the JIRA project and the code repo properly, given that our mailing list's and JIRA's responsiveness is high, it's good enough for me that we use GH PR for the patching process only, keep issues on JIRA and make most significant discussion on the mailing list only. While, GH discussions is a net win as a user forum just like a stack overflow tag - we can ensure no development decision is made there and everything is back to the mailing list. Best, tison. [1] https://issues.apache.org/jira/browse/MPOM-418 [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln [3] https://github.com/apache/maven-apache-parent [4] https://www.goodreads.com/en/book/show/54140556 [5] https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88 Tamás Cservenák 于2023年5月27日周六 18:10写道： > Howdy, > > I do agree with Lukasz here...but > > In general, my intention with bringing up this on Slack was motivated by > following reasons: > - we do have ML (signup needed), > - we do have JIRA (ask + approval + signup needed), > > But all this is a high barrier for "one off" users, many of our users want > to ASK us about something, so going through hoops and loops above (and > coming back 2 yr after with "please unsub me...") only to post a question > is just a very bad experience. > > Moreover, we are very fragmented repository-wide, and I bet that a novice > user will simply be lost: > - WHERE (as in which Maven-* GH repo) to ask > - WHERE (as in which Maven-* GH repo) to report issue > - etc > > This is why I recommended "single entry point", a kind of dispatcher > (discussion) repo/GH project, where one off users can hop on, ASK things > and disappear if they like, receive answers where to go, and so on. And if > they feel like it, they could join ML or register to JIRA, something TODAY > EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers" > would not go so far even. > > For me, most reasonable would be a new "discussion only" project, for > example "apache/maven-project" on GH, that would contain no source, no > issues, only discussions enabled and would serve as a "low barrier lobby" > for newcomers. > > Opening discussions in _existing repository_ is unwise IMHO, as "general" > discussions/questions do not belong to apache/maven, nor > apache/maven-clean-plugin, nor any other existing repo. > > Thanks > T > > On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki > wrote: > > > I have no strong feelings, however relying too much on single service > > vendor is never a good idea. In this case if one day, by some > > terms&condition changes, github repos are not an option any more, we are > > fine with ASF infrastructure. But we can't do same thing for issues > > which are embedded in GH database. If you ever found a google code > > project migrated into github/gitlab issues you know what I mean. > > > > While policies imposed on JIRA account creation, are without doubt a > > bearer to contribute first bug report, JIRA itself helps us keeping all > > ASF information together. Just to be clear - I keep being lost with new > > JIRA user interface, I'm just reflecting my personal thoughts. > > > > Best, > > Łukasz > > > > On 27.05.2023 09:30, Hervé Boutemy wrote: > > > Le vendredi 2
Re: GH issues and GH discussions
I agree with Tamas' suggestion about the single point of entrance. Here are several examples I experienced: 1. Apache SkyWalking[1] uses a single GH Issue to track all its issues and Discussions for user questions and some rough ideas. 2. Apache Pulsar[2] (I'm one of its committers) uses multiple GH Issues for different repos, while for the tightly coupled site repo[3], I merge the Issue tracker to the main repo. Single Discussions instance for all "Pulsar" related questions. 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project for all its repos issue trackers, and only user@ and user-zh@ mailing lists for user questions. Given their high responsiveness, it works well for most of its users. Although other unofficial channels (with PMC members there) (like DingTalk group or Slack workspace) exist to answer questions, most users can be guided to the mailing list since it's still the most active channel. Maven has a more complex repo cluster[4], and decisions can differ. Best, tison. [1] https://github.com/apache/skywalking [2] http://github.com/apache/pulsar [3] http://github.com/apache/pulsar-site [4] https://maven.apache.org/scm.html tison 于2023年5月27日周六 18:28写道： > As a Maven user experiencing finding issue tracker recently[1][2], here > are my two coins: > > 1. GitHub Issues help to get issues reported at the exact code repo. > > I found a usage question for ASF parent pom and find the code repo at[3], > no GitHub Issues and I jump to the linked JIRA project MPOM, while the > maintainer tells me it's not the correct place. > > I'm familiar with the mailing list way so it's not quite a trouble to ask > here. But as time goes on, more and more developers and users get used to > the GitHub platform. No matter if it's a good thing, it's a fact[4]. > > So, for lowering the bar for user participation, I agree we can give GH > issues and GH discussions a try. > > 2. GitHub is a proprietary service that is unreliable in an organization's > view. > > I agree. > > Part of them can be resolved by we sync all traffic back to an ASF mailing > list, like most of the ASF projects I participated in[5]. We can thus > archive most of the context but since they are for archiving only, the > readability can be bad. > > To sum up, as new generation developers and users grow and they are more > familiar with the GitHub platform, before we find a competitor to compare > with, and since we can more or less sync the conversation back to ASF > INFRA, I'm +1 for giving GH issue and GH discussion a chance. > > But, in the other hand, if we can link the JIRA project and the code repo > properly, given that our mailing list's and JIRA's responsiveness is high, > it's good enough for me that we use GH PR for the patching process only, > keep issues on JIRA and make most significant discussion on the mailing > list only. While, GH discussions is a net win as a user forum just like a > stack overflow tag - we can ensure no development decision is made there > and everything is back to the mailing list. > > Best, > tison. > > [1] https://issues.apache.org/jira/browse/MPOM-418 > [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln > [3] https://github.com/apache/maven-apache-parent > > [4] https://www.goodreads.com/en/book/show/54140556 > > [5] > https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88 > > > Tamás Cservenák 于2023年5月27日周六 18:10写道： > >> Howdy, >> >> I do agree with Lukasz here...but >> >> In general, my intention with bringing up this on Slack was motivated by >> following reasons: >> - we do have ML (signup needed), >> - we do have JIRA (ask + approval + signup needed), >> >> But all this is a high barrier for "one off" users, many of our users want >> to ASK us about something, so going through hoops and loops above (and >> coming back 2 yr after with "please unsub me...") only to post a question >> is just a very bad experience. >> >> Moreover, we are very fragmented repository-wide, and I bet that a novice >> user will simply be lost: >> - WHERE (as in which Maven-* GH repo) to ask >> - WHERE (as in which Maven-* GH repo) to report issue >> - etc >> >> This is why I recommended "single entry point", a kind of dispatcher >> (discussion) repo/GH project, where one off users can hop on, ASK things >> and disappear if they like, receive answers where to go, and so on. And if >> they feel like it, they could join ML or register to JIRA, something TODAY >> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one o
Re: GH issues and GH discussions
> single point of entrance One last comment - it's a maintainer strategy to reduce the burden of monitoring multiple channels, and users generally gather to where their questions can be answered. But it's not a user strategy; they ask on the platform they are used to or closest to where the issue happens. So we may not say "a specific channel is _not_ supported, you should not ask there", but "most of the critical mass answering questions on platform X". Users make their choice reflected to where the critical mass work instead of being forced there. Best, tison. tison 于2023年5月27日周六 18:36写道： > I agree with Tamas' suggestion about the single point of entrance. Here > are several examples I experienced: > > 1. Apache SkyWalking[1] uses a single GH Issue to track all its issues and > Discussions for user questions and some rough ideas. > 2. Apache Pulsar[2] (I'm one of its committers) uses multiple GH Issues > for different repos, while for the tightly coupled site repo[3], I merge > the Issue tracker to the main repo. Single Discussions instance for all > "Pulsar" related questions. > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project > for all its repos issue trackers, and only user@ and user-zh@ mailing > lists for user questions. Given their high responsiveness, it works well > for most of its users. Although other unofficial channels (with PMC members > there) (like DingTalk group or Slack workspace) exist to answer questions, > most users can be guided to the mailing list since it's still the most > active channel. > > Maven has a more complex repo cluster[4], and decisions can differ. > > Best, > tison. > > [1] https://github.com/apache/skywalking > [2] http://github.com/apache/pulsar > [3] http://github.com/apache/pulsar-site > [4] https://maven.apache.org/scm.html > > > tison 于2023年5月27日周六 18:28写道： > >> As a Maven user experiencing finding issue tracker recently[1][2], here >> are my two coins: >> >> 1. GitHub Issues help to get issues reported at the exact code repo. >> >> I found a usage question for ASF parent pom and find the code repo at[3], >> no GitHub Issues and I jump to the linked JIRA project MPOM, while the >> maintainer tells me it's not the correct place. >> >> I'm familiar with the mailing list way so it's not quite a trouble to ask >> here. But as time goes on, more and more developers and users get used to >> the GitHub platform. No matter if it's a good thing, it's a fact[4]. >> >> So, for lowering the bar for user participation, I agree we can give GH >> issues and GH discussions a try. >> >> 2. GitHub is a proprietary service that is unreliable in an >> organization's view. >> >> I agree. >> >> Part of them can be resolved by we sync all traffic back to an ASF >> mailing list, like most of the ASF projects I participated in[5]. We can >> thus archive most of the context but since they are for archiving only, the >> readability can be bad. >> >> To sum up, as new generation developers and users grow and they are more >> familiar with the GitHub platform, before we find a competitor to compare >> with, and since we can more or less sync the conversation back to ASF >> INFRA, I'm +1 for giving GH issue and GH discussion a chance. >> >> But, in the other hand, if we can link the JIRA project and the code repo >> properly, given that our mailing list's and JIRA's responsiveness is high, >> it's good enough for me that we use GH PR for the patching process only, >> keep issues on JIRA and make most significant discussion on the mailing >> list only. While, GH discussions is a net win as a user forum just like a >> stack overflow tag - we can ensure no development decision is made there >> and everything is back to the mailing list. >> >> Best, >> tison. >> >> [1] https://issues.apache.org/jira/browse/MPOM-418 >> [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln >> [3] https://github.com/apache/maven-apache-parent >> >> [4] https://www.goodreads.com/en/book/show/54140556 >> >> [5] >> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88 >> >> >> Tamás Cservenák 于2023年5月27日周六 18:10写道： >> >>> Howdy, >>> >>> I do agree with Lukasz here...but >>> >>> In general, my intention with bringing up this on Slack was motivated by >>> following reasons: >>> - we do have ML (signup needed), >>> - we do have JIRA (ask
Re: GH issues and GH discussions
> It occurs to me that not that long ago, Jira used to be open signup. > is there a specific reason it changed? Does that reason still apply? It's still open and self-serving at [1]. Just need one more moderate step from committers or PMC members. To reduce spam, yes. Best, tison. [1] https://selfserve.apache.org/jira-account.html Gary Gregory 于2023年5月27日周六 18:55写道： > How does StackOverflow fit in if at all? Any pros and cons to share? > > Gary > > On Sat, May 27, 2023, 06:43 tison wrote: > > > > single point of entrance > > > > One last comment - it's a maintainer strategy to reduce the burden of > > monitoring multiple channels, and users generally gather to where their > > questions can be answered. But it's not a user strategy; they ask on the > > platform they are used to or closest to where the issue happens. > > > > So we may not say "a specific channel is _not_ supported, you should not > > ask there", but "most of the critical mass answering questions on > platform > > X". Users make their choice reflected to where the critical mass work > > instead of being forced there. > > > > Best, > > tison. > > > > > > tison 于2023年5月27日周六 18:36写道： > > > > > I agree with Tamas' suggestion about the single point of entrance. Here > > > are several examples I experienced: > > > > > > 1. Apache SkyWalking[1] uses a single GH Issue to track all its issues > > and > > > Discussions for user questions and some rough ideas. > > > 2. Apache Pulsar[2] (I'm one of its committers) uses multiple GH Issues > > > for different repos, while for the tightly coupled site repo[3], I > merge > > > the Issue tracker to the main repo. Single Discussions instance for all > > > "Pulsar" related questions. > > > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA > project > > > for all its repos issue trackers, and only user@ and user-zh@ mailing > > > lists for user questions. Given their high responsiveness, it works > well > > > for most of its users. Although other unofficial channels (with PMC > > members > > > there) (like DingTalk group or Slack workspace) exist to answer > > questions, > > > most users can be guided to the mailing list since it's still the most > > > active channel. > > > > > > Maven has a more complex repo cluster[4], and decisions can differ. > > > > > > Best, > > > tison. > > > > > > [1] https://github.com/apache/skywalking > > > [2] http://github.com/apache/pulsar > > > [3] http://github.com/apache/pulsar-site > > > [4] https://maven.apache.org/scm.html > > > > > > > > > tison 于2023年5月27日周六 18:28写道： > > > > > >> As a Maven user experiencing finding issue tracker recently[1][2], > here > > >> are my two coins: > > >> > > >> 1. GitHub Issues help to get issues reported at the exact code repo. > > >> > > >> I found a usage question for ASF parent pom and find the code repo > > at[3], > > >> no GitHub Issues and I jump to the linked JIRA project MPOM, while the > > >> maintainer tells me it's not the correct place. > > >> > > >> I'm familiar with the mailing list way so it's not quite a trouble to > > ask > > >> here. But as time goes on, more and more developers and users get used > > to > > >> the GitHub platform. No matter if it's a good thing, it's a fact[4]. > > >> > > >> So, for lowering the bar for user participation, I agree we can give > GH > > >> issues and GH discussions a try. > > >> > > >> 2. GitHub is a proprietary service that is unreliable in an > > >> organization's view. > > >> > > >> I agree. > > >> > > >> Part of them can be resolved by we sync all traffic back to an ASF > > >> mailing list, like most of the ASF projects I participated in[5]. We > can > > >> thus archive most of the context but since they are for archiving > only, > > the > > >> readability can be bad. > > >> > > >> To sum up, as new generation developers and users grow and they are > more > > >> familiar with the GitHub platform, before we find a competitor to > > compare > > >> with, and since we can more or less sync the conversation back to ASF > > >> INFRA, I'm +1 for
Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4
+1 (non-binding) Build and test with JDK 8 on macOS OK. Checksum matches. BTW - It happens I submit a PR[1] to this plugin yesterday and wait for a review :D Best, tison. [1] https://github.com/apache/maven-project-info-reports-plugin/pull/61 Hervé Boutemy 于2023年5月28日周日 22:53写道： > +1 > > Reproducible Builds ok: reference build done with JDK 8 on Windows > > Regards, > > Hervé > > Le vendredi 26 mai 2023, 21:29:11 CEST Michael Osipov a écrit : > > Hi, > > > > we solved 6 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&ve > > rsion=12353222 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/projects/MPIR/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1948/ > > > https://repository.apache.org/content/repositories/maven-1948/org/apache/mav > > > en/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-report > > s-plugin-3.4.4-source-release.zip > > > > Source release checksum(s): > > maven-project-info-reports-plugin-3.4.4-source-release.zip > > sha512: > > > c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484 > > ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b > > > > Staging site: > > > https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-> > LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > - > > 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 > >
Re: Deploy with multiple platform artifacts build separately
FYI - I implement it with https://github.com/tisonkun/ci-opendal. Just if it helps anyone has the same question :D Best, tison. tison 于2023年5月26日周五 11:33写道： > Thank you Tamas! > > Then I follow Netty's practice and successfully run the automatically > deploy[1][2]. > > While there are still two issues, they may not be quite related in Maven > domain: > > 1. Distribute Maven and GPG secrets - does Maven support token like > password? I'm a bit concerned to convey my text password to even our INFRA > member to configure a platform secret. Maybe I can just release locally, > but right now I already use GitHub Actions to do multiple platform building > and full automation seems reasonable to try. > 2. Cross compile for different arch due to the lack of arm64 machine on > GitHub Actions. Yes, this is totally unrelated to Maven then :D Maybe how > to package two classifier with different config at once is, but there > should be multiple workaround. > > Best, > tison. > > [1] > https://github.com/tisonkun/opendal/actions/runs/5082466604/jobs/9132438693 > [2] https://github.com/tisonkun/opendal/actions/runs/5082466604/workflow > > > > Tamás Cservenák 于2023年5月25日周四 20:23写道： > >> Howdy, >> >> Sonatype OSS and ASF Reposes are both Nx2 so the same applies: >> >> When you deploy for the first time, Nx2 staging creates a staging >> repository that is "open". >> The created repository will have its own ID and hence, own deployment URL >> as well. >> >> The trick is that this endpoint: >> ttps://repository.apache.org/service/local/staging/deploy/maven2 >> At the first request this endpoint creates a staging repo (on the fly) and >> from that point on, it just routes the incoming request to it, as if those >> requests would come in directly to the newly created repository. >> >> In Nx2 UI, when you click on Staging Repository -> your staging repo (as >> you need permission as well to write there), the lower part of the screen >> will tell you the URL of the staging repository. >> >> You can use authenticated HTTP requests (even using curl -X PUT and even >> -X >> DELETE) to MODIFY the content of your staging repository as you wish. >> >> Once the staging repository is closed, it is "untouchable", no content >> changes are possible against it. >> >> So to answer your questions: >> - maven will NOT allow you to perform multiple deploys (see similar >> problem >> https://issues.apache.org/jira/browse/MDEPLOY-118) >> - but nothing stops you to use curl or even mvn deploy-file against your >> (open) staging repository. >> >> At the end, there are "rule checks" that contents of staging repository >> must pass (like presence of sources, javadoc, hashes and signatures). But >> Nx2 will tell you if something is missing. >> >> HTH >> Tamas >> >> >> >> On Thu, May 25, 2023 at 2:10 PM tison wrote: >> >> > Hi devs, >> > >> > I'm trying to deploy Apache OpenDAL with multiple platform artifacts on >> its >> > Java binding[1]. >> > >> > Using the ASF Parent POM, I freely get a `mvn -P apache-relase deply` >> > target to make the release - that is great! >> > >> > Although, every time when I execute this command, I can only release for >> > one platform (the one the command runs on). I'd like to release for >> > multiple platforms (said at least for (osx, linux) x (x86_64, >> aarch_64)), >> > but struggling that I can even build them on different machines. >> > >> > I don't know if I can - >> > 1. Deploy multiple times for the same version; >> > 2. Manually merge artifacts and finally upload those artifacts at once. >> > >> > Existing examples like Netty[2] work against the Sonatype repository, >> while >> > Apache OpenDAL, IIUC, should work against the ASF repository. >> > >> > Looking forward to your help! >> > >> > Best, >> > tison. >> > >> > [1] https://github.com/apache/incubator-opendal/issues/2313 >> > [2] https://netty.io/wiki/releasing-new-version.html >> > >> >
nexusUrl checked even skipRemoteStaging specified to true
Hi, I don't know if it's a Maven issue or INFRA issue or plugin issue (as I saw the related part is written by the current Maven PMC chair, I posted it here). The question is, when I stage a package for multiple platforms, I use a local staging flavor that specifies -DskipRemoteStaging=true. It works well in my personal repo[1], but failed when I try it on the apache/incubator-opendal repo[2]. The log complains strangely that "Mandatory plugin parameter 'nexusUrl' is missing" while I do skip the remote staging phase. I'll appreciate if you can take a look. Best, tison. [1] https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow [2] https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525
Re: nexusUrl checked even skipRemoteStaging specified to true
Suspected related code[1]. and cc dev@opendal.a.o Best, tison. [1] https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 tison 于2023年6月25日周日 15:50写道： > Hi, > > I don't know if it's a Maven issue or INFRA issue or plugin issue (as I > saw the related part is written by the current Maven PMC chair, I posted it > here). > > The question is, when I stage a package for multiple platforms, I use a > local staging flavor that specifies -DskipRemoteStaging=true. It works > well in my personal repo[1], but failed when I try it on the > apache/incubator-opendal repo[2]. > > The log complains strangely that "Mandatory plugin parameter 'nexusUrl' is > missing" while I do skip the remote staging phase. > > I'll appreciate if you can take a look. > > Best, > tison. > > [1] > https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow > [2] > https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 > >
Re: nexusUrl checked even skipRemoteStaging specified to true
After restore the action, it fails now. May I ask what is the proper nexusUrl for apache snapshot? Best, tison. tison 于2023年6月25日周日 15:51写道： > Suspected related code[1]. > > and cc dev@opendal.a.o > > Best, > tison. > > [1] > https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 > > > tison 于2023年6月25日周日 15:50写道： > >> Hi, >> >> I don't know if it's a Maven issue or INFRA issue or plugin issue (as I >> saw the related part is written by the current Maven PMC chair, I posted it >> here). >> >> The question is, when I stage a package for multiple platforms, I use a >> local staging flavor that specifies -DskipRemoteStaging=true. It works >> well in my personal repo[1], but failed when I try it on the >> apache/incubator-opendal repo[2]. >> >> The log complains strangely that "Mandatory plugin parameter 'nexusUrl' >> is missing" while I do skip the remote staging phase. >> >> I'll appreciate if you can take a look. >> >> Best, >> tison. >> >> [1] >> https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow >> [2] >> https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 >> >>
Re: nexusUrl checked even skipRemoteStaging specified to true
Thanks for your information! Then I can I achieve the similar target? I need to build staging artifacts in different platforms and then merge it and deploy. Best, tison. Tamás Cservenák 于2023年6月25日周日 16:13写道： > For RAO it is https://repository.apache.org/ > > But using this plugin is really not recommended, even Sonatype abandoned > it. > > Hth > T > > On Sun, Jun 25, 2023, 10:11 tison wrote: > > > After restore the action, it fails now. May I ask what is the proper > > nexusUrl for apache snapshot? > > > > Best, > > tison. > > > > > > tison 于2023年6月25日周日 15:51写道： > > > > > Suspected related code[1]. > > > > > > and cc dev@opendal.a.o > > > > > > Best, > > > tison. > > > > > > [1] > > > > > > https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 > > > > > > > > > tison 于2023年6月25日周日 15:50写道： > > > > > >> Hi, > > >> > > >> I don't know if it's a Maven issue or INFRA issue or plugin issue (as > I > > >> saw the related part is written by the current Maven PMC chair, I > > posted it > > >> here). > > >> > > >> The question is, when I stage a package for multiple platforms, I use > a > > >> local staging flavor that specifies -DskipRemoteStaging=true. It > works > > >> well in my personal repo[1], but failed when I try it on the > > >> apache/incubator-opendal repo[2]. > > >> > > >> The log complains strangely that "Mandatory plugin parameter > 'nexusUrl' > > >> is missing" while I do skip the remote staging phase. > > >> > > >> I'll appreciate if you can take a look. > > >> > > >> Best, > > >> tison. > > >> > > >> [1] > > >> > https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow > > >> [2] > > >> > > > https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 > > >> > > >> > > >
Re: nexusUrl checked even skipRemoteStaging specified to true
And I remember that when I add the nexusUrl just as suggested above, the action run failed with 403: Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy (default-cli) on project opendal-java: Execution default-cli of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy failed: 403 - Forbidden tison 于2023年6月25日 周日16:16写道： > Thanks for your information! > > Then I can I achieve the similar target? I need to build staging artifacts > in different platforms and then merge it and deploy. > > Best, > tison. > > > Tamás Cservenák 于2023年6月25日周日 16:13写道： > >> For RAO it is https://repository.apache.org/ >> >> But using this plugin is really not recommended, even Sonatype abandoned >> it. >> >> Hth >> T >> >> On Sun, Jun 25, 2023, 10:11 tison wrote: >> >> > After restore the action, it fails now. May I ask what is the proper >> > nexusUrl for apache snapshot? >> > >> > Best, >> > tison. >> > >> > >> > tison 于2023年6月25日周日 15:51写道： >> > >> > > Suspected related code[1]. >> > > >> > > and cc dev@opendal.a.o >> > > >> > > Best, >> > > tison. >> > > >> > > [1] >> > > >> > >> https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 >> > > >> > > >> > > tison 于2023年6月25日周日 15:50写道： >> > > >> > >> Hi, >> > >> >> > >> I don't know if it's a Maven issue or INFRA issue or plugin issue >> (as I >> > >> saw the related part is written by the current Maven PMC chair, I >> > posted it >> > >> here). >> > >> >> > >> The question is, when I stage a package for multiple platforms, I >> use a >> > >> local staging flavor that specifies -DskipRemoteStaging=true. It >> works >> > >> well in my personal repo[1], but failed when I try it on the >> > >> apache/incubator-opendal repo[2]. >> > >> >> > >> The log complains strangely that "Mandatory plugin parameter >> 'nexusUrl' >> > >> is missing" while I do skip the remote staging phase. >> > >> >> > >> I'll appreciate if you can take a look. >> > >> >> > >> Best, >> > >> tison. >> > >> >> > >> [1] >> > >> >> https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow >> > >> [2] >> > >> >> > >> https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 >> > >> >> > >> >> > >> > -- Best, tison.
Re: nexusUrl checked even skipRemoteStaging specified to true
Aha..Unfortunately not. I use sonatype plugin and follow Netty's practice. It seems for snapshot, previously (the same version of plugin) it can auto set nexusUrl and serverId. But now it cannot: $ cat .index org/apache/opendal/opendal-java/0.2.0-SNAPSHOT/opendal-java-0.2.0-SNAPSHOT.jar=org.apache.opendal:opendal-java:0.2.0-SNAPSHOT:n/a:jar:jar:opendal-java-0.2.0-SNAPSHOT.pom:n/a:apache.snapshots.https: https://repository.apache.org/content/repositories/snapshots ... Best, tison. Tamás Cservenák 于2023年6月25日周日 16:34写道： > Hm, > > I remember your use case as we discussed it here: > https://lists.apache.org/thread/vqgbdp61y5jg5fgdhmgx4zycl4ps39s8 > > I had a feeling you sorted it out, and did it without the aforementioned > plugin... > > > T > > On Sun, Jun 25, 2023 at 10:20 AM tison wrote: > > > And I remember that when I add the nexusUrl just as suggested above, the > > action run failed with 403: > > > > Failed to execute goal > > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy > (default-cli) > > on project opendal-java: Execution default-cli of goal > > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy failed: > 403 - > > Forbidden > > > > tison 于2023年6月25日 周日16:16写道： > > > > > Thanks for your information! > > > > > > Then I can I achieve the similar target? I need to build staging > > artifacts > > > in different platforms and then merge it and deploy. > > > > > > Best, > > > tison. > > > > > > > > > Tamás Cservenák 于2023年6月25日周日 16:13写道： > > > > > >> For RAO it is https://repository.apache.org/ > > >> > > >> But using this plugin is really not recommended, even Sonatype > abandoned > > >> it. > > >> > > >> Hth > > >> T > > >> > > >> On Sun, Jun 25, 2023, 10:11 tison wrote: > > >> > > >> > After restore the action, it fails now. May I ask what is the proper > > >> > nexusUrl for apache snapshot? > > >> > > > >> > Best, > > >> > tison. > > >> > > > >> > > > >> > tison 于2023年6月25日周日 15:51写道： > > >> > > > >> > > Suspected related code[1]. > > >> > > > > >> > > and cc dev@opendal.a.o > > >> > > > > >> > > Best, > > >> > > tison. > > >> > > > > >> > > [1] > > >> > > > > >> > > > >> > > > https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 > > >> > > > > >> > > > > >> > > tison 于2023年6月25日周日 15:50写道： > > >> > > > > >> > >> Hi, > > >> > >> > > >> > >> I don't know if it's a Maven issue or INFRA issue or plugin issue > > >> (as I > > >> > >> saw the related part is written by the current Maven PMC chair, I > > >> > posted it > > >> > >> here). > > >> > >> > > >> > >> The question is, when I stage a package for multiple platforms, I > > >> use a > > >> > >> local staging flavor that specifies -DskipRemoteStaging=true. It > > >> works > > >> > >> well in my personal repo[1], but failed when I try it on the > > >> > >> apache/incubator-opendal repo[2]. > > >> > >> > > >> > >> The log complains strangely that "Mandatory plugin parameter > > >> 'nexusUrl' > > >> > >> is missing" while I do skip the remote staging phase. > > >> > >> > > >> > >> I'll appreciate if you can take a look. > > >> > >> > > >> > >> Best, > > >> > >> tison. > > >> > >> > > >> > >> [1] > > >> > >> > > >> > https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow > > >> > >> [2] > > >> > >> > > >> > > > >> > > > https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 > > >> > >> > > >> > >> > > >> > > > >> > > > -- > > Best, > > tison. > > >
Re: nexusUrl checked even skipRemoteStaging specified to true
Or the question can be - I have a Maven project having multiple classifier variants to deploy. I can build them separately on different machine. How can I finish the last mile to deploy it to Apache Nexus server. (for snapshots now). Best, tison. tison 于2023年6月25日周日 16:41写道： > Aha..Unfortunately not. I use sonatype plugin and follow Netty's practice. > It seems for snapshot, previously (the same version of plugin) it can auto > set nexusUrl and serverId. But now it cannot: > > $ cat .index > > org/apache/opendal/opendal-java/0.2.0-SNAPSHOT/opendal-java-0.2.0-SNAPSHOT.jar=org.apache.opendal:opendal-java:0.2.0-SNAPSHOT:n/a:jar:jar:opendal-java-0.2.0-SNAPSHOT.pom:n/a:apache.snapshots.https: > https://repository.apache.org/content/repositories/snapshots > ... > > Best, > tison. > > > Tamás Cservenák 于2023年6月25日周日 16:34写道： > >> Hm, >> >> I remember your use case as we discussed it here: >> https://lists.apache.org/thread/vqgbdp61y5jg5fgdhmgx4zycl4ps39s8 >> >> I had a feeling you sorted it out, and did it without the aforementioned >> plugin... >> >> >> T >> >> On Sun, Jun 25, 2023 at 10:20 AM tison wrote: >> >> > And I remember that when I add the nexusUrl just as suggested above, the >> > action run failed with 403: >> > >> > Failed to execute goal >> > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy >> (default-cli) >> > on project opendal-java: Execution default-cli of goal >> > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy failed: >> 403 - >> > Forbidden >> > >> > tison 于2023年6月25日 周日16:16写道： >> > >> > > Thanks for your information! >> > > >> > > Then I can I achieve the similar target? I need to build staging >> > artifacts >> > > in different platforms and then merge it and deploy. >> > > >> > > Best, >> > > tison. >> > > >> > > >> > > Tamás Cservenák 于2023年6月25日周日 16:13写道： >> > > >> > >> For RAO it is https://repository.apache.org/ >> > >> >> > >> But using this plugin is really not recommended, even Sonatype >> abandoned >> > >> it. >> > >> >> > >> Hth >> > >> T >> > >> >> > >> On Sun, Jun 25, 2023, 10:11 tison wrote: >> > >> >> > >> > After restore the action, it fails now. May I ask what is the >> proper >> > >> > nexusUrl for apache snapshot? >> > >> > >> > >> > Best, >> > >> > tison. >> > >> > >> > >> > >> > >> > tison 于2023年6月25日周日 15:51写道： >> > >> > >> > >> > > Suspected related code[1]. >> > >> > > >> > >> > > and cc dev@opendal.a.o >> > >> > > >> > >> > > Best, >> > >> > > tison. >> > >> > > >> > >> > > [1] >> > >> > > >> > >> > >> > >> >> > >> https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 >> > >> > > >> > >> > > >> > >> > > tison 于2023年6月25日周日 15:50写道： >> > >> > > >> > >> > >> Hi, >> > >> > >> >> > >> > >> I don't know if it's a Maven issue or INFRA issue or plugin >> issue >> > >> (as I >> > >> > >> saw the related part is written by the current Maven PMC chair, >> I >> > >> > posted it >> > >> > >> here). >> > >> > >> >> > >> > >> The question is, when I stage a package for multiple platforms, >> I >> > >> use a >> > >> > >> local staging flavor that specifies -DskipRemoteStaging=true. >> It >> > >> works >> > >> > >> well in my personal repo[1], but failed when I try it on the >> > >> > >> apache/incubator-opendal repo[2]. >> > >> > >> >> > >> > >> The log complains strangely that "Mandatory plugin parameter >> > >> 'nexusUrl' >> > >> > >> is missing" while I do skip the remote staging phase. >> > >> > >> >> > >> > >> I'll appreciate if you can take a look. >> > >> > >> >> > >> > >> Best, >> > >> > >> tison. >> > >> > >> >> > >> > >> [1] >> > >> > >> >> > >> >> https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow >> > >> > >> [2] >> > >> > >> >> > >> > >> > >> >> > >> https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 >> > >> > >> >> > >> > >> >> > >> > >> > >> >> > > -- >> > Best, >> > tison. >> > >> >
Re: nexusUrl checked even skipRemoteStaging specified to true
I get it now because we don't use a -SNAPSHOT suffix so the logic changes.. Let me workaround for the SNAPSHOT now and see if the formal release cause a 403. Best, tison. tison 于2023年6月25日周日 18:47写道： > Or the question can be - I have a Maven project having multiple > classifier variants to deploy. I can build them separately on different > machine. How can I finish the last mile to deploy it to Apache Nexus > server. (for snapshots now). > > Best, > tison. > > > tison 于2023年6月25日周日 16:41写道： > >> Aha..Unfortunately not. I use sonatype plugin and follow Netty's >> practice. It seems for snapshot, previously (the same version of plugin) it >> can auto set nexusUrl and serverId. But now it cannot: >> >> $ cat .index >> >> org/apache/opendal/opendal-java/0.2.0-SNAPSHOT/opendal-java-0.2.0-SNAPSHOT.jar=org.apache.opendal:opendal-java:0.2.0-SNAPSHOT:n/a:jar:jar:opendal-java-0.2.0-SNAPSHOT.pom:n/a:apache.snapshots.https: >> https://repository.apache.org/content/repositories/snapshots >> ... >> >> Best, >> tison. >> >> >> Tamás Cservenák 于2023年6月25日周日 16:34写道： >> >>> Hm, >>> >>> I remember your use case as we discussed it here: >>> https://lists.apache.org/thread/vqgbdp61y5jg5fgdhmgx4zycl4ps39s8 >>> >>> I had a feeling you sorted it out, and did it without the aforementioned >>> plugin... >>> >>> >>> T >>> >>> On Sun, Jun 25, 2023 at 10:20 AM tison wrote: >>> >>> > And I remember that when I add the nexusUrl just as suggested above, >>> the >>> > action run failed with 403: >>> > >>> > Failed to execute goal >>> > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy >>> (default-cli) >>> > on project opendal-java: Execution default-cli of goal >>> > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy failed: >>> 403 - >>> > Forbidden >>> > >>> > tison 于2023年6月25日 周日16:16写道： >>> > >>> > > Thanks for your information! >>> > > >>> > > Then I can I achieve the similar target? I need to build staging >>> > artifacts >>> > > in different platforms and then merge it and deploy. >>> > > >>> > > Best, >>> > > tison. >>> > > >>> > > >>> > > Tamás Cservenák 于2023年6月25日周日 16:13写道： >>> > > >>> > >> For RAO it is https://repository.apache.org/ >>> > >> >>> > >> But using this plugin is really not recommended, even Sonatype >>> abandoned >>> > >> it. >>> > >> >>> > >> Hth >>> > >> T >>> > >> >>> > >> On Sun, Jun 25, 2023, 10:11 tison wrote: >>> > >> >>> > >> > After restore the action, it fails now. May I ask what is the >>> proper >>> > >> > nexusUrl for apache snapshot? >>> > >> > >>> > >> > Best, >>> > >> > tison. >>> > >> > >>> > >> > >>> > >> > tison 于2023年6月25日周日 15:51写道： >>> > >> > >>> > >> > > Suspected related code[1]. >>> > >> > > >>> > >> > > and cc dev@opendal.a.o >>> > >> > > >>> > >> > > Best, >>> > >> > > tison. >>> > >> > > >>> > >> > > [1] >>> > >> > > >>> > >> > >>> > >> >>> > >>> https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 >>> > >> > > >>> > >> > > >>> > >> > > tison 于2023年6月25日周日 15:50写道： >>> > >> > > >>> > >> > >> Hi, >>> > >> > >> >>> > >> > >> I don't know if it's a Maven issue or INFRA issue or plugin >>> issue >>> > >> (as I >>> > >> > >> saw the related part is written by the current Maven PMC >>> chair, I >>> > >> > posted it >>> > >> > >> here). >>> > >> > >> >>> > >> > >> The question is, when I stage a package for multiple >>> platforms, I >>> > >> use a >>> > >> > >> local staging flavor that specifies -DskipRemoteStaging=true. >>> It >>> > >> works >>> > >> > >> well in my personal repo[1], but failed when I try it on the >>> > >> > >> apache/incubator-opendal repo[2]. >>> > >> > >> >>> > >> > >> The log complains strangely that "Mandatory plugin parameter >>> > >> 'nexusUrl' >>> > >> > >> is missing" while I do skip the remote staging phase. >>> > >> > >> >>> > >> > >> I'll appreciate if you can take a look. >>> > >> > >> >>> > >> > >> Best, >>> > >> > >> tison. >>> > >> > >> >>> > >> > >> [1] >>> > >> > >> >>> > >> >>> https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow >>> > >> > >> [2] >>> > >> > >> >>> > >> > >>> > >> >>> > >>> https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 >>> > >> > >> >>> > >> > >> >>> > >> > >>> > >> >>> > > -- >>> > Best, >>> > tison. >>> > >>> >>
Re: nexusUrl checked even skipRemoteStaging specified to true
All works now. Removed INFRA from cc. I'd like to ask the Maven developers that if the sonatype plugin is deprecated, is there some alternatives in the community? `mvn deploy` seems limited or hard to use (works well for pure java project, I agree) at least I don't know how to release multi classifier projects and how to merge staging artifacts. Best, tison. tison 于2023年6月25日周日 18:52写道： > I get it now because we don't use a -SNAPSHOT suffix so the logic changes.. > > Let me workaround for the SNAPSHOT now and see if the formal release cause > a 403. > > Best, > tison. > > > tison 于2023年6月25日周日 18:47写道： > >> Or the question can be - I have a Maven project having multiple >> classifier variants to deploy. I can build them separately on different >> machine. How can I finish the last mile to deploy it to Apache Nexus >> server. (for snapshots now). >> >> Best, >> tison. >> >> >> tison 于2023年6月25日周日 16:41写道： >> >>> Aha..Unfortunately not. I use sonatype plugin and follow Netty's >>> practice. It seems for snapshot, previously (the same version of plugin) it >>> can auto set nexusUrl and serverId. But now it cannot: >>> >>> $ cat .index >>> >>> org/apache/opendal/opendal-java/0.2.0-SNAPSHOT/opendal-java-0.2.0-SNAPSHOT.jar=org.apache.opendal:opendal-java:0.2.0-SNAPSHOT:n/a:jar:jar:opendal-java-0.2.0-SNAPSHOT.pom:n/a:apache.snapshots.https: >>> https://repository.apache.org/content/repositories/snapshots >>> ... >>> >>> Best, >>> tison. >>> >>> >>> Tamás Cservenák 于2023年6月25日周日 16:34写道： >>> >>>> Hm, >>>> >>>> I remember your use case as we discussed it here: >>>> https://lists.apache.org/thread/vqgbdp61y5jg5fgdhmgx4zycl4ps39s8 >>>> >>>> I had a feeling you sorted it out, and did it without the aforementioned >>>> plugin... >>>> >>>> >>>> T >>>> >>>> On Sun, Jun 25, 2023 at 10:20 AM tison wrote: >>>> >>>> > And I remember that when I add the nexusUrl just as suggested above, >>>> the >>>> > action run failed with 403: >>>> > >>>> > Failed to execute goal >>>> > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy >>>> (default-cli) >>>> > on project opendal-java: Execution default-cli of goal >>>> > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy failed: >>>> 403 - >>>> > Forbidden >>>> > >>>> > tison 于2023年6月25日 周日16:16写道： >>>> > >>>> > > Thanks for your information! >>>> > > >>>> > > Then I can I achieve the similar target? I need to build staging >>>> > artifacts >>>> > > in different platforms and then merge it and deploy. >>>> > > >>>> > > Best, >>>> > > tison. >>>> > > >>>> > > >>>> > > Tamás Cservenák 于2023年6月25日周日 16:13写道： >>>> > > >>>> > >> For RAO it is https://repository.apache.org/ >>>> > >> >>>> > >> But using this plugin is really not recommended, even Sonatype >>>> abandoned >>>> > >> it. >>>> > >> >>>> > >> Hth >>>> > >> T >>>> > >> >>>> > >> On Sun, Jun 25, 2023, 10:11 tison wrote: >>>> > >> >>>> > >> > After restore the action, it fails now. May I ask what is the >>>> proper >>>> > >> > nexusUrl for apache snapshot? >>>> > >> > >>>> > >> > Best, >>>> > >> > tison. >>>> > >> > >>>> > >> > >>>> > >> > tison 于2023年6月25日周日 15:51写道： >>>> > >> > >>>> > >> > > Suspected related code[1]. >>>> > >> > > >>>> > >> > > and cc dev@opendal.a.o >>>> > >> > > >>>> > >> > > Best, >>>> > >> > > tison. >>>> > >> > > >>>> > >> > > [1] >>>> > >> > > >>>> > >> > >>>> > >> >>>> > >>>> https://github.com/sonatype/nexus-maven-plugins/blame/d36fd861662d566071390ff75dae79846f46901c/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/remote/Parameters.java#L95 >>>> > >> > > >>>> > >> > > >>>> > >> > > tison 于2023年6月25日周日 15:50写道： >>>> > >> > > >>>> > >> > >> Hi, >>>> > >> > >> >>>> > >> > >> I don't know if it's a Maven issue or INFRA issue or plugin >>>> issue >>>> > >> (as I >>>> > >> > >> saw the related part is written by the current Maven PMC >>>> chair, I >>>> > >> > posted it >>>> > >> > >> here). >>>> > >> > >> >>>> > >> > >> The question is, when I stage a package for multiple >>>> platforms, I >>>> > >> use a >>>> > >> > >> local staging flavor that specifies >>>> -DskipRemoteStaging=true. It >>>> > >> works >>>> > >> > >> well in my personal repo[1], but failed when I try it on the >>>> > >> > >> apache/incubator-opendal repo[2]. >>>> > >> > >> >>>> > >> > >> The log complains strangely that "Mandatory plugin parameter >>>> > >> 'nexusUrl' >>>> > >> > >> is missing" while I do skip the remote staging phase. >>>> > >> > >> >>>> > >> > >> I'll appreciate if you can take a look. >>>> > >> > >> >>>> > >> > >> Best, >>>> > >> > >> tison. >>>> > >> > >> >>>> > >> > >> [1] >>>> > >> > >> >>>> > >> >>>> https://github.com/tisonkun/ci-opendal/actions/runs/5107624733/workflow >>>> > >> > >> [2] >>>> > >> > >> >>>> > >> > >>>> > >> >>>> > >>>> https://github.com/apache/incubator-opendal/actions/runs/5368618052/jobs/9739424356?pr=2525 >>>> > >> > >> >>>> > >> > >> >>>> > >> > >>>> > >> >>>> > > -- >>>> > Best, >>>> > tison. >>>> > >>>> >>>
Best pratice for aggregator plugin
Hi, I'm developing a Maven plugin to check files' license header with aggregator=true because the backed functions are expected to work against the root path of the whole project. As stated in[1], I met an issue that although it works well if you configure the plugin in the parent module and run the goal from the root path. But what if you want to bind it with the VERIFY phase? The plugin will be inherited into all of the children modules and they will resolve relative path incorrectly. I'd like to ask the Maven devs for best practices in this situation. Best, tison. [1] https://github.com/korandoru/hawkeye/pull/96
Surefire Plugin: Tests failure on abstract class only shows the abstract class name
See https://github.com/junit-team/junit5/issues/3475 for details. Perhaps JUnit5ConsoleOutputReporter is related but I failed to located the certain line constructing the test method name. Best, tison.
Re: Surefire Plugin: Tests failure on abstract class only shows the abstract class name
To demostrate the expected manner, I want: [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.535 s <<< FAILURE! - in org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest [ERROR] org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull Time elapsed: 0.491 s <<< FAILURE! java.lang.AssertionError: to be: [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.535 s <<< FAILURE! - in org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest [ERROR] org.apache.opendal.behavior.FsTest>org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull Time elapsed: 0.491 s <<< FAILURE! java.lang.AssertionError: Or other approach to specify the actual test class. Best, tison. tison 于2023年9月23日周六 01:11写道： > See https://github.com/junit-team/junit5/issues/3475 for details. > > Perhaps JUnit5ConsoleOutputReporter is related but I failed to located the > certain line constructing the test method name. > > Best, > tison. >
Re: Surefire Plugin: Tests failure on abstract class only shows the abstract class name
The "usePhrasedClassNameInRunning" property in
"JUnit5StatelessTestsetInfoReporter" helps a bit:
@DisplayName("FsTest")
public class FsTest extends BehaviorTest {
// ...
}
[INFO] Running FsTest AsyncWriteTest
[ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
0.636 s <<< FAILURE! -- in FsTest AsyncWriteTest
[ERROR]
org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull --
Time elapsed: 0.594 s <<< FAILURE!
java.lang.AssertionError:
But not in the very end summary:
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull
[ERROR] Run 1: BehaviorTest$AsyncWriteTest.testReadFull:110
You can clone https://github.com/apache/incubator-opendal/pull/3161 and
fail some tests case conditionally for debugging.
Best,
tison.
tison 于2023年9月23日周六 01:17写道：
> To demostrate the expected manner, I want:
>
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.535 s <<< FAILURE! - in
> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest
> [ERROR]
> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull Time
> elapsed: 0.491 s <<< FAILURE!
> java.lang.AssertionError:
>
> to be:
>
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.535 s <<< FAILURE! - in
> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest
> [ERROR]
> org.apache.opendal.behavior.FsTest>org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull
> Time elapsed: 0.491 s <<< FAILURE!
> java.lang.AssertionError:
>
> Or other approach to specify the actual test class.
>
> Best,
> tison.
>
>
> tison 于2023年9月23日周六 01:11写道：
>
>> See https://github.com/junit-team/junit5/issues/3475 for details.
>>
>> Perhaps JUnit5ConsoleOutputReporter is related but I failed to located
>> the certain line constructing the test method name.
>>
>> Best,
>> tison.
>>
>
Re: Surefire Plugin: Tests failure on abstract class only shows the abstract class name
Bubble up. Or where I can file an issue to track if it's likely an
improvement.
Best,
tison.
tison 于2023年9月23日周六 09:48写道：
> The "usePhrasedClassNameInRunning" property in
> "JUnit5StatelessTestsetInfoReporter" helps a bit:
>
> @DisplayName("FsTest")
> public class FsTest extends BehaviorTest {
> // ...
> }
>
> [INFO] Running FsTest AsyncWriteTest
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.636 s <<< FAILURE! -- in FsTest AsyncWriteTest
> [ERROR]
> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull --
> Time elapsed: 0.594 s <<< FAILURE!
> java.lang.AssertionError:
>
> But not in the very end summary:
>
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]
> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull
> [ERROR] Run 1: BehaviorTest$AsyncWriteTest.testReadFull:110
>
> You can clone https://github.com/apache/incubator-opendal/pull/3161 and
> fail some tests case conditionally for debugging.
>
> Best,
> tison.
>
>
> tison 于2023年9月23日周六 01:17写道：
>
>> To demostrate the expected manner, I want:
>>
>> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
>> 0.535 s <<< FAILURE! - in
>> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest
>> [ERROR]
>> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull Time
>> elapsed: 0.491 s <<< FAILURE!
>> java.lang.AssertionError:
>>
>> to be:
>>
>> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
>> 0.535 s <<< FAILURE! - in
>> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest
>> [ERROR]
>> org.apache.opendal.behavior.FsTest>org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull
>> Time elapsed: 0.491 s <<< FAILURE!
>> java.lang.AssertionError:
>>
>> Or other approach to specify the actual test class.
>>
>> Best,
>> tison.
>>
>>
>> tison 于2023年9月23日周六 01:11写道：
>>
>>> See https://github.com/junit-team/junit5/issues/3475 for details.
>>>
>>> Perhaps JUnit5ConsoleOutputReporter is related but I failed to located
>>> the certain line constructing the test method name.
>>>
>>> Best,
>>> tison.
>>>
>>
Do we have a list for changes between 3.9 and 4.0?
Hi, I'm going to try out the 4.0 branch, and I would like to have a list of important changes. Currently, each alpha version has its release note, but that's like a log instead of a somewhat migration guide. Do we have an up-to-date list of changes between 3.9 and 4.0? Best, tison.
Re: Do we have a list for changes between 3.9 and 4.0?
I saw somewhat https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12346477 now. Best, tison. tison 于2023年10月16日周一 13:52写道： > Hi, > > I'm going to try out the 4.0 branch, and I would like to have a list of > important changes. Currently, each alpha version has its release note, but > that's like a log instead of a somewhat migration guide. > > Do we have an up-to-date list of changes between 3.9 and 4.0? > > Best, > tison. >
Re: [VOTE] Release Apache Maven Daemon 1.0-m8
The link to release note is broken. Best, tison. Guillaume Nodet 于2023年10月26日周四 14:44写道： > I've staged a candidate release at > https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0-m8/ > > This release provides distributions based on Maven 3.9.5 and > 4.0.0-alpha-8 releases. > The release notes are available at : > > https://github.com/apache/maven-mvnd/releases/tag/untagged-56be0cecfa7305fcd889 > > Please review and vote ! > -- > > Guillaume Nodet > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Daemon 1.0-m8
> Yes, sorry about that. It's draft release and not visible if you're not a > member of the github apache organization. I am. So perhaps only @maven-committer can view it? Best, tison. Guillaume Nodet 于2023年10月26日周四 14:52写道： > Yes, sorry about that. It's draft release and not visible if you're not a > member of the github apache organization. > The pages is as below: > > Maven Daemon comes into two different flavours: m39 which embeds Maven > 3.9.x, and m40 which embeds Maven 4.0.0-alpha-x. > What's Changed > >- [MNG-6847] Use diamond operator by @timtebeek ><https://github.com/timtebeek> in #886 ><https://github.com/apache/maven-mvnd/pull/886> >- Update: Maven 3.9.5 + Resolver 1.9.16 by @cstamas ><https://github.com/cstamas> in #887 ><https://github.com/apache/maven-mvnd/pull/887> >- Fix terminal width (fixes #870 ><https://github.com/apache/maven-mvnd/issues/870>) by @gnodet ><https://github.com/gnodet> in #891 ><https://github.com/apache/maven-mvnd/pull/891> >- Update build instructions for Windows by @KasNotten ><https://github.com/KasNotten> in #890 ><https://github.com/apache/maven-mvnd/pull/890> >- Removed superfluous public for tests by @khmarbaise ><https://github.com/khmarbaise> in #882 ><https://github.com/apache/maven-mvnd/pull/882> >- Support JDK 21 at build time by @gnodet <https://github.com/gnodet> > in >#894 <https://github.com/apache/maven-mvnd/pull/894> >- Make sure the plugin works with maven 3 by @gnodet ><https://github.com/gnodet> in #893 ><https://github.com/apache/maven-mvnd/pull/893> >- Small improvements to DaemonPrompter by @gnodet ><https://github.com/gnodet> in #898 ><https://github.com/apache/maven-mvnd/pull/898> >- Switch to Maven 4.0.0-alpha-8 by @gnodet <https://github.com/gnodet> > in > #895 <https://github.com/apache/maven-mvnd/pull/895> >- Upgrade JLine from 3.23.0 to 3.24.0 by @gnodet ><https://github.com/gnodet> in #899 ><https://github.com/apache/maven-mvnd/pull/899> > > New Contributors > >- @timtebeek <https://github.com/timtebeek> made their first >contribution in #886 <https://github.com/apache/maven-mvnd/pull/886> >- @KasNotten <https://github.com/KasNotten> made their first >contribution in #890 <https://github.com/apache/maven-mvnd/pull/890> >- @khmarbaise <https://github.com/khmarbaise> made their first >contribution in #882 <https://github.com/apache/maven-mvnd/pull/882> > > *Full Changelog*: 1.0-m7...1.0-m8 > <https://github.com/apache/maven-mvnd/compare/1.0-m7...1.0-m8> > > > > Le jeu. 26 oct. 2023 à 08:48, tison a écrit : > > > > The link to release note is broken. > > > > Best, > > tison. > > > > > > Guillaume Nodet 于2023年10月26日周四 14:44写道： > > > > > I've staged a candidate release at > > > https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0-m8/ > > > > > > This release provides distributions based on Maven 3.9.5 and > > > 4.0.0-alpha-8 releases. > > > The release notes are available at : > > > > > > > > https://github.com/apache/maven-mvnd/releases/tag/untagged-56be0cecfa7305fcd889 > > > > > > Please review and vote ! > > > -- > > > > > > Guillaume Nodet > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > > Guillaume Nodet >
Nexus returns 400 Bad Request
Hi, When deploying artifacts to Nexus repository, 400 Bad Request can be one of the most confusing error code. See [1] as an example. Sonatype has a page to document some common causes of 400 Bad Request [2]. But I wonder if we can return an error message (diagnostic) along with the error code, so that users can get what conditions broken exactly. I suppose it has been discussed before. Is there any reference about this? What is the related components / code I can check for potential contributions (fixes)? Best, tison. [1] https://issues.apache.org/jira/browse/INFRA-25344 [2] https://central.sonatype.org/faq/400-error/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
How to test lifecycle extension?
Hi, I'm writing a Mojo with an Extension extending AbstractMavenLifecycleParticipant. Now, I'd like to write some tests on the extension logic. Although Maven provides docs about writing tests over Mojos[1], it doesn't tell how to test if an extension [2] is properly loaded and executed. Are there some examples of such test cases? Best, tison. [1] https://maven.apache.org/plugin-developers/plugin-testing.html#using-plexustestcase [2] https://maven.apache.org/guides/mini/guide-using-extensions.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Nexus returns 400 Bad Request
Thanks for your reply! > Maybe that is a bug in Nexus itself. I ever thought of it. But according to Romain's comment, it seems the MavenSession has the information but not printed out. > if you feel motivated to send a pr it would be welcomed I guess. I'd like to spend some time to see if I can write one. Could you show me some related code locations that I can start with? Maven has a lot of repos and I don't know which components are related to this logic. Best, tison. Hervé Boutemy 于2024年1月6日周六 16:05写道： > > interesting details > > IMHO, we're back to the HTTP wire protocol between Maven CLI and repositories > not being precisely defined on edge cases > = what to put as HTTP return code, what to put as reason phrase (deprecated in > HTTP/1.1, removed in HTTP/2), and what to get from HTTP body > > idea has been shared some time ago about using RFC 7807, but nothing has been > really done > see https://issues.apache.org/jira/browse/MNG-6795 , marked as candidate for > Maven 4, but did not get much traction for now > > Regards, > > Hervé > > Le vendredi 5 janvier 2024, 19:11:57 CET Romain Manni-Bucau a écrit : > > Hi, > > > > This is a valid error but if you want to see it you need to enable HTTP > > frames. > > > > For the record the error returns a HTML response with this content: > > *Cannot find a matching staging profile*. > > > > If you want to check them out it depends a bit of your maven version but > > for 3.9 you just comment the two last lines > > of $MAVEN_HOME/conf/logging/simplelogger.properties > > (org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for > > maven 4 you can use the JVM httpclient system properties IIRC). > > > > But agree our client could be more precise on the error instead of just > > throwing a 400 without any message, if you feel motivated to send a pr it > > would be welcomed I guess. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > <https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le ven. 5 janv. 2024 à 18:46, Michael Osipov a écrit : > > > On 2024/01/04 14:00:08 tison wrote: > > > > Hi, > > > > > > > > When deploying artifacts to Nexus repository, 400 Bad Request can be > > > > one of the most confusing error code. See [1] as an example. > > > > > > > > Sonatype has a page to document some common causes of 400 Bad Request > > > > [2]. But I wonder if we can return an error message (diagnostic) along > > > > with the error code, so that users can get what conditions broken > > > > exactly. > > > > > > > > I suppose it has been discussed before. Is there any reference about > > > > this? What is the related components / code I can check for potential > > > > contributions (fixes)? > > > > > > > > Best, > > > > tison. > > > > > > > > [1] https://issues.apache.org/jira/browse/INFRA-25344 > > > > [2] https://central.sonatype.org/faq/400-error/ > > > > > > Looking at the INFRA issue it seems that 400 is just wrong. There is not > > > client issue here, but a permission issue which should give you 403. Maybe > > > that is a bug in Nexus itself. > > > > > > - > > > 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
Re: How to test lifecycle extension?
I found Maven Invoker is a component that can be used [1]. Let me try to make an example. Best, tison. [1] https://maven.apache.org/shared/maven-invoker/usage.html tison 于2024年1月25日周四 11:09写道： > > Hi, > > I'm writing a Mojo with an Extension extending > AbstractMavenLifecycleParticipant. > > Now, I'd like to write some tests on the extension logic. Although > Maven provides docs about writing tests over Mojos[1], it doesn't tell > how to test if an extension [2] is properly loaded and executed. > > Are there some examples of such test cases? > > Best, > tison. > > [1] > https://maven.apache.org/plugin-developers/plugin-testing.html#using-plexustestcase > [2] https://maven.apache.org/guides/mini/guide-using-extensions.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to test lifecycle extension?
Implemented in https://github.com/tisonspieces/os-detector/pull/4. Best, tison. tison 于2024年2月5日周一 21:34写道： > > I found Maven Invoker is a component that can be used [1]. Let me try > to make an example. > > Best, > tison. > > [1] https://maven.apache.org/shared/maven-invoker/usage.html > > tison 于2024年1月25日周四 11:09写道： > > > > Hi, > > > > I'm writing a Mojo with an Extension extending > > AbstractMavenLifecycleParticipant. > > > > Now, I'd like to write some tests on the extension logic. Although > > Maven provides docs about writing tests over Mojos[1], it doesn't tell > > how to test if an extension [2] is properly loaded and executed. > > > > Are there some examples of such test cases? > > > > Best, > > tison. > > > > [1] > > https://maven.apache.org/plugin-developers/plugin-testing.html#using-plexustestcase > > [2] https://maven.apache.org/guides/mini/guide-using-extensions.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Merge staged classifiers and deploy
Hi, I found the other thread talks about nexus-staging-plugin and it's deprecated. In Apache OpenDAL, we're currently relying on nexus-staging-plugin for merging staged classifiers (i.e., JARs with native library on different platforms) and deploy. We wrote [1] and [2] for doing so, and IIRC I spent a few days but fail to find the way achieve this in maven-deploy-plugin. [1] https://github.com/apache/opendal/blob/v0.45.1/.github/workflows/release_java.yml [2] https://github.com/apache/opendal/blob/v0.45.1/scripts/merge_local_staging.py Did you ever encounter this case? Is there any reference? Best, tison.
Re: Merge staged classifiers and deploy
Hello, Any updates here? Also the challenge I found is that I can't understand how Maven and the repository cooperate on deployment. Is there some docs or specs describe the concepts and workflows so that I can try to customize my own solutions? Now I'd like to release one new classifier "all" that contains all the native libs as resources, but I don't know how to start working on it .. Best, tison. Tamás Cservenák 于2024年5月3日周五 09:27写道： > > Howdy, > > We have a similar use case (unsolved yet, done manually) in maven-mvnd, > where native binaries for various OS es (produced by GraalVM) need to be > collected > > Stay tuned. > > T > > On Thu, May 2, 2024 at 3:38 AM tison wrote: > > > Hi, > > > > I found the other thread talks about nexus-staging-plugin and it's > > deprecated. > > > > In Apache OpenDAL, we're currently relying on nexus-staging-plugin for > > merging staged classifiers (i.e., JARs with native library on different > > platforms) and deploy. > > > > We wrote [1] and [2] for doing so, and IIRC I spent a few days but fail to > > find the way achieve this in maven-deploy-plugin. > > > > [1] > > > > https://github.com/apache/opendal/blob/v0.45.1/.github/workflows/release_java.yml > > [2] > > > > https://github.com/apache/opendal/blob/v0.45.1/scripts/merge_local_staging.py > > > > Did you ever encounter this case? Is there any reference? > > > > Best, > > tison. > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: GitHub issues and release announcement ...
This sounds great! For implementation, I can imagine a workflow triggered by a published event [1], but I wonder how to send an email from within the workflow, or use other forward methods. [1] https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release Best, tison. Slawomir Jaranowski 于2025年2月11日周二 21:57写道： > > Hi, > > GitHub sends an announcement about the new version to subscribers on > GitHub project after publishing release. > > If we still need to send announcements to annou...@maven.apache.org > for some ASF formal reason > maybe we can automatically send it by GitHub ... what do you think? > > -- > Sławomir Jaranowski > > - > 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
Re: [DISCUSS] Support YAML poms
Good to know https://github.com/takari/polyglot-maven. Just my two cents: I often find YAML easy to be wrong due to its implicit type conversion (1.20 cam be "1.2", while 1.19 can be "1.19") and indents changing meaning. In the Cargo ecosystem, we use TOML to describe build logic, and it works very well. IIRC so does the Python ecosystem [1]. [1] https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ Best, tison. Tamás Cservenák 于2025年3月6日周四 00:21写道： > > +1 go for it! > > On Wed, Mar 5, 2025, 17:17 Guillaume Nodet wrote: > > > Hey ! > > > > A while ago, I created a Hocon based POM parser [1], leveraging Maven > > 4 new capabilities to support new syntaxes for POMs. > > However, as much as that syntax seems interesting, I've been pointed > > that it's not really supported. So I never actually released it. > > But I'd still like to get out a new syntax and so I wrote one to > > support the well known YAML syntax. I thus created a small extension > > to support it [2]. > > It's much more concise wrt GAV ids and especially dependencies [3]. > > > > So I'd like to get it into the Maven project and release it. > > > > [1] https://github.com/apache/maven-hocon-extension > > [2] https://github.com/gnodet/maven-yaml-extension > > [3] > > https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resources/dependency-gav.yaml#L21-L30 > > > > -- > > > > 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
