Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 9:18 PM, Nick Stolwijk wrote: I took a quick look at the Maven-Nexus-plugin and there is an option to disable it (skipNexusStagingDeployMojo), so I would start there. I in fact did start there. I don't know if you happened to read this part of my question which started this thread: > … let's instead find an easy way to turn it off. I don't see in the documentation (see link above) that there's even > a "skip" property. Is there? I see that the Maven Deploy Plugin has such a feature. > I also see that there is a `skipNexusStagingDeployMojo`, but that appears to be neither a configuration property > nor a user property, but only a "plugin flag" which is "passed in from the CLI" using `-D`. > Is there a "skip" configuration property for the Nexus Staging Maven Plugin ? So I guess I'm back to where I started. Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
I took a quick look at the Maven-Nexus-plugin and there is an option to disable it (skipNexusStagingDeployMojo), so I would start there. Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Mon, 31 Jul 2023 at 01:50, Garret Wilson wrote: > How is the best way you would recommend to turn off publishing in parent B? > > Garret > > On 7/30/2023 8:47 PM, Nick Stolwijk wrote: > > In that case I would publish your parent with all the Good Stuff (parent > A) > > in the central repository, and have a second parent inheriting Parent A > > where publishing is turned off. So your super secret, multi gazillion > > project can inherit from parent B and so no publishing is going on, > unless > > they turn on the maven-flatten-plugin and a publish plugin. > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Mon, 31 Jul 2023 at 01:30, Garret Wilson > wrote: > > > >> On 7/30/2023 8:16 PM, Nils Breunese wrote: > >>> … > >>> Can I ask why you publish this root POM as a public artifact to Maven > >> Central? > >> > >> 1. To be a good open-source citizen and help others with all the goodies > >> this POM provides (many of them which should be in Maven by default but > >> are not). > >> > >> 2. To provide a standard baseline for expectations for all of our > >> projects (e.g. build properties that are populated), including our > >> open-source projects and our hypothetical super-secret > >> multi-million-dollar projects. > >> > >>> If you’re using it to build super-secret million-dollar projects that > >> shouldn’t be published publicly, it might be safer to publish this root > POM > >> to an internal Maven repository as well (as I suppose you already do for > >> the projects that inherit from this root POM)? > >> > >> But the error lies in conflating the two conceptually. > >> > >> The child project is what is super-secret and multi-gazillion dollars > >> worth. The parent project is just a tool; it is not super-secret nor > >> worth multi-gazillion dollars. > >> > >> You realize that Maven comes with its own super POM, right? So we could > >> ask the same question: if I'm building a super-secret gazillion-dollar > >> project, might not it be safer to find out how to disable Maven's own > >> super POM? But of course we know that's a silly question. > >> > >> One should have nothing at all to with the other. The super POM just > >> sets up some common properties that everyone can use. My root POM just > >> sets up some common properties that everyone can use. I should be able > >> to publish my root POM and easily disable publishing for its children. > >> > >> This is one of Maven's drawbacks: inheriting too much from the POM. For > >> example if you publish a parent POM that has one license (e.g. Apache > >> 2.0), suddenly all its children inherit the same license (although most > >> people aren't aware of this) without specific overriding. See my Stack > >> Overflow question [Publish open-source Maven parent POM without > >> inheriting ``](https://stackoverflow.com/q/73239332) and > >> [MNG-7562](https://issues.apache.org/jira/browse/MNG-7562). > >> > >> The central issue in both cases is that the Maven designers in general > >> seemed not to have realized the need to distinguish between "information > >> related to publication of this POM" with "information that is to be > >> inherited to child POMs". > >> > >> Garret > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
How is the best way you would recommend to turn off publishing in parent B? Garret On 7/30/2023 8:47 PM, Nick Stolwijk wrote: In that case I would publish your parent with all the Good Stuff (parent A) in the central repository, and have a second parent inheriting Parent A where publishing is turned off. So your super secret, multi gazillion project can inherit from parent B and so no publishing is going on, unless they turn on the maven-flatten-plugin and a publish plugin. Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Mon, 31 Jul 2023 at 01:30, Garret Wilson wrote: On 7/30/2023 8:16 PM, Nils Breunese wrote: … Can I ask why you publish this root POM as a public artifact to Maven Central? 1. To be a good open-source citizen and help others with all the goodies this POM provides (many of them which should be in Maven by default but are not). 2. To provide a standard baseline for expectations for all of our projects (e.g. build properties that are populated), including our open-source projects and our hypothetical super-secret multi-million-dollar projects. If you’re using it to build super-secret million-dollar projects that shouldn’t be published publicly, it might be safer to publish this root POM to an internal Maven repository as well (as I suppose you already do for the projects that inherit from this root POM)? But the error lies in conflating the two conceptually. The child project is what is super-secret and multi-gazillion dollars worth. The parent project is just a tool; it is not super-secret nor worth multi-gazillion dollars. You realize that Maven comes with its own super POM, right? So we could ask the same question: if I'm building a super-secret gazillion-dollar project, might not it be safer to find out how to disable Maven's own super POM? But of course we know that's a silly question. One should have nothing at all to with the other. The super POM just sets up some common properties that everyone can use. My root POM just sets up some common properties that everyone can use. I should be able to publish my root POM and easily disable publishing for its children. This is one of Maven's drawbacks: inheriting too much from the POM. For example if you publish a parent POM that has one license (e.g. Apache 2.0), suddenly all its children inherit the same license (although most people aren't aware of this) without specific overriding. See my Stack Overflow question [Publish open-source Maven parent POM without inheriting ``](https://stackoverflow.com/q/73239332) and [MNG-7562](https://issues.apache.org/jira/browse/MNG-7562). The central issue in both cases is that the Maven designers in general seemed not to have realized the need to distinguish between "information related to publication of this POM" with "information that is to be inherited to child POMs". Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
In that case I would publish your parent with all the Good Stuff (parent A) in the central repository, and have a second parent inheriting Parent A where publishing is turned off. So your super secret, multi gazillion project can inherit from parent B and so no publishing is going on, unless they turn on the maven-flatten-plugin and a publish plugin. Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Mon, 31 Jul 2023 at 01:30, Garret Wilson wrote: > On 7/30/2023 8:16 PM, Nils Breunese wrote: > > … > > Can I ask why you publish this root POM as a public artifact to Maven > Central? > > 1. To be a good open-source citizen and help others with all the goodies > this POM provides (many of them which should be in Maven by default but > are not). > > 2. To provide a standard baseline for expectations for all of our > projects (e.g. build properties that are populated), including our > open-source projects and our hypothetical super-secret > multi-million-dollar projects. > > > If you’re using it to build super-secret million-dollar projects that > shouldn’t be published publicly, it might be safer to publish this root POM > to an internal Maven repository as well (as I suppose you already do for > the projects that inherit from this root POM)? > > But the error lies in conflating the two conceptually. > > The child project is what is super-secret and multi-gazillion dollars > worth. The parent project is just a tool; it is not super-secret nor > worth multi-gazillion dollars. > > You realize that Maven comes with its own super POM, right? So we could > ask the same question: if I'm building a super-secret gazillion-dollar > project, might not it be safer to find out how to disable Maven's own > super POM? But of course we know that's a silly question. > > One should have nothing at all to with the other. The super POM just > sets up some common properties that everyone can use. My root POM just > sets up some common properties that everyone can use. I should be able > to publish my root POM and easily disable publishing for its children. > > This is one of Maven's drawbacks: inheriting too much from the POM. For > example if you publish a parent POM that has one license (e.g. Apache > 2.0), suddenly all its children inherit the same license (although most > people aren't aware of this) without specific overriding. See my Stack > Overflow question [Publish open-source Maven parent POM without > inheriting ``](https://stackoverflow.com/q/73239332) and > [MNG-7562](https://issues.apache.org/jira/browse/MNG-7562). > > The central issue in both cases is that the Maven designers in general > seemed not to have realized the need to distinguish between "information > related to publication of this POM" with "information that is to be > inherited to child POMs". > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 8:16 PM, Nils Breunese wrote: … Can I ask why you publish this root POM as a public artifact to Maven Central? 1. To be a good open-source citizen and help others with all the goodies this POM provides (many of them which should be in Maven by default but are not). 2. To provide a standard baseline for expectations for all of our projects (e.g. build properties that are populated), including our open-source projects and our hypothetical super-secret multi-million-dollar projects. If you’re using it to build super-secret million-dollar projects that shouldn’t be published publicly, it might be safer to publish this root POM to an internal Maven repository as well (as I suppose you already do for the projects that inherit from this root POM)? But the error lies in conflating the two conceptually. The child project is what is super-secret and multi-gazillion dollars worth. The parent project is just a tool; it is not super-secret nor worth multi-gazillion dollars. You realize that Maven comes with its own super POM, right? So we could ask the same question: if I'm building a super-secret gazillion-dollar project, might not it be safer to find out how to disable Maven's own super POM? But of course we know that's a silly question. One should have nothing at all to with the other. The super POM just sets up some common properties that everyone can use. My root POM just sets up some common properties that everyone can use. I should be able to publish my root POM and easily disable publishing for its children. This is one of Maven's drawbacks: inheriting too much from the POM. For example if you publish a parent POM that has one license (e.g. Apache 2.0), suddenly all its children inherit the same license (although most people aren't aware of this) without specific overriding. See my Stack Overflow question [Publish open-source Maven parent POM without inheriting ``](https://stackoverflow.com/q/73239332) and [MNG-7562](https://issues.apache.org/jira/browse/MNG-7562). The central issue in both cases is that the Maven designers in general seemed not to have realized the need to distinguish between "information related to publication of this POM" with "information that is to be inherited to child POMs". Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Garret Wilson wrote: > It is not a job for profiles. If I put it in a profile, a developer has to > only mistakenly use `-P nexus` or whatever the profile is, and our > super-secret million-dollar project gets published. I want it to be disabled > altogether. Can I ask why you publish this root POM as a public artifact to Maven Central? If you’re using it to build super-secret million-dollar projects that shouldn’t be published publicly, it might be safer to publish this root POM to an internal Maven repository as well (as I suppose you already do for the projects that inherit from this root POM)? Nils. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
I think the idea of the flatten-maven-plugin is a Good Idea. It removes any inheritance in the POM structure before publishing to a repository. It is a "weak" implementation of the consumer POM that Maven is working towards. It doesn't change your artifacts, it just flattens the POM so it isn't dependending on any parent when published. I use it in a lot of projects which only publish some of the modules and I don't like the parent to be published. When you publish your parent, you have to take responsibility for it. I only publish the modules I would like to share, without inheritance. It also makes it easier with dependency management, the reasoning about which import takes preference with an inherited parent import is really hard to understand. Take a look at it, and maybe it will solve your problem. Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Mon, 31 Jul 2023 at 00:45, Garret Wilson wrote: > On 7/30/2023 7:34 PM, Nick Stolwijk wrote: > > I am missing the purpose of publishing the parent pom. Is it because > other > > projects can inherit of it, > > Yes. > > > or is it because your own projects (that you > > want to be published) are inherited from it? > > Yes. > > > In the second case, you can use the maven-flatten-plugin to have the > > published projects not be dependent on your parent project. In that case > > you can use the parent projects to setup the > > configuration and activate it in the child modules in the build section. > If > > you enable the maven-flatten-plugin in the parent project for each child > > project there is no project inheritance anymore in the published > artifacts, > > so there is no need to publish your parent pom. > > I confess I don't know much about the Maven Flatten Plugin, but it > sounds suspiciously like the Maven Shade Plugin, which Seemed Like A > Good Idea At The Time To Muck With Everything, but from much personal > experience the details bring nothing but pain and suffering. > > So if I flatten everything, how do I publish a BOM of my multimodule > aggregate subprojects without bringing in project-specific dependencies > that shouldn't go in the BOM? > > I don't want to dismiss suggestions too quickly if I don't fully > understand them, but sincerely, just the idea sound like it would bring > lots of tears for years and years. > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 7:34 PM, Nick Stolwijk wrote: I am missing the purpose of publishing the parent pom. Is it because other projects can inherit of it, Yes. or is it because your own projects (that you want to be published) are inherited from it? Yes. In the second case, you can use the maven-flatten-plugin to have the published projects not be dependent on your parent project. In that case you can use the parent projects to setup the configuration and activate it in the child modules in the build section. If you enable the maven-flatten-plugin in the parent project for each child project there is no project inheritance anymore in the published artifacts, so there is no need to publish your parent pom. I confess I don't know much about the Maven Flatten Plugin, but it sounds suspiciously like the Maven Shade Plugin, which Seemed Like A Good Idea At The Time To Muck With Everything, but from much personal experience the details bring nothing but pain and suffering. So if I flatten everything, how do I publish a BOM of my multimodule aggregate subprojects without bringing in project-specific dependencies that shouldn't go in the BOM? I don't want to dismiss suggestions too quickly if I don't fully understand them, but sincerely, just the idea sound like it would bring lots of tears for years and years. Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 6:32 PM, Tamás Cservenák wrote: There is no need for another plugin... well, let me explain: all the "vanilla" plugins of Maven (install, deploy, release) support everything that aforementioned plugin does: install at end, deploy at end, stage/deploy, there is ONLY two things they cannot do: "close" and "release" (the staging repo). Tamás, thanks again for this explanation. I have never drilled down in to the deployment process. I'm reading the [Nexus Staging Maven Plugin documentation](https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md), and if I'm understanding it correctly, this plugin actually somehow _disables_ the Maven Deploy Plugin in Maven 3.x? So if I were to put the Nexus Staging Maven Plugin into a separate profile, and then run `mvn deploy` without specifying that profile, does that mean that by default the Maven Deploy Plugin would kick in automatically and still try to upload my artifacts somewhere? Where would it try to upload them to? Is there some documentation on deploying my artifacts to Maven Central without using the Nexus Maven Plugin? I configured all this deployment stuff probably 10 years ago. I'm going back to my notes, and it looks like here are the instructions, straight from Sonatype, for [Deploying to OSSRH with Apache Maven](https://central.sonatype.org/publish/publish-maven/#nexus-staging-maven-plugin-for-deployment-and-release). There it's pretty clear: > The Nexus Staging Maven Plugin is the recommended way to deploy your components to OSSRH and release them to the Central Repository. It appears that Sonatype hasn't been informed that the Nexus Staging Plugin is end-of-life, shouldn't be used, and won't work in Maven 4. :) Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
I am missing the purpose of publishing the parent pom. Is it because other projects can inherit of it, or is it because your own projects (that you want to be published) are inherited from it? In the second case, you can use the maven-flatten-plugin to have the published projects not be dependent on your parent project. In that case you can use the parent projects to setup the configuration and activate it in the child modules in the build section. If you enable the maven-flatten-plugin in the parent project for each child project there is no project inheritance anymore in the published artifacts, so there is no need to publish your parent pom. Maybe this is the solution you are looking for. Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sun, 30 Jul 2023 at 23:50, Garret Wilson wrote: > I think we'll have to "agree to disagree" on this one. > > But I'll note that by following the same logic presented below, > CloudFormation and Terraform would require the developer to log into the > AWS console to finalize a deployment. That similarly would be > unacceptable to me. > > Thanks for pointing out that this plugin is end-of-life and explaining > the implications of dropping it. > > Garret > > On 7/30/2023 6:44 PM, Tamás Cservenák wrote: > > Well, I disagree: > > The App UI you are staging to will show you: > > - who staged, > > - what is staged > > - in case or error (ie. signature mismatch or checksum mismatch) where > are > > the problems > > - etc > > > > Is not prone to errors, as you do not modify content at all by doing that > > (Maven did deliver it already), reproducibility really depends only on > your > > build, not this 3rd party service (they blindly accepts bytes and just > > checks some rules "ok"/"not ok"), as for security you already provided > > credentials while staging. > > > > Given the "stability" history of oss or s01, I have to say that it is > even > > _desirable_ to be able to use UI for these steps, as otherwise you are > just > > "burning" versions (failed releases) for reasons totally unrelated to > > Maven, but for some 3rd party service that provides you "way" to get > > something to Central. > > > > Unless... we talk about some private Nx instance? Or Sonatype oss one? As > > in that case scripting would work for it. > > After all, this is proprietary software (they call it "oss" but is more > > like "free"), with its own proprietary REST API... > > > > T > > > > On Sun, Jul 30, 2023 at 11:37 PM Garret Wilson > > wrote: > > > >> On 7/30/2023 6:32 PM, Tamás Cservenák wrote: > >>> There is no need for another plugin... well, let me explain: > >>> all the "vanilla" plugins of Maven (install, deploy, release) support > >>> everything that aforementioned plugin does: install at end, deploy at > >> end, > >>> stage/deploy, there is ONLY two things they cannot do: "close" and > >>> "release" (the staging repo). > >>> > >>> For those two things, you'd need to use the browser, navigate to oss or > >> s01 > >>> server, log in, and using Nexus UI close or release your staging > >> repository. > >>> If this is acceptable to you, you should just drop the use of that > >> plugin. > >> > >> Requiring me to use my browser and log into a site and muck around with > >> a mouse just to release software is not acceptable. > >> > >> That might have been acceptable in 2003. > >> > >> We just don't do things like that nowadays. It's not just for > >> convenience. It's bad practice, prone to errors, hard to reproduce, > >> introduces security issues, unwieldy to maintain, and a general > >> infrastructure-as-code anti-pattern for 100 reasons, which you can > >> probably recite as well as I can. > >> > >> Garret > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
I think we'll have to "agree to disagree" on this one. But I'll note that by following the same logic presented below, CloudFormation and Terraform would require the developer to log into the AWS console to finalize a deployment. That similarly would be unacceptable to me. Thanks for pointing out that this plugin is end-of-life and explaining the implications of dropping it. Garret On 7/30/2023 6:44 PM, Tamás Cservenák wrote: Well, I disagree: The App UI you are staging to will show you: - who staged, - what is staged - in case or error (ie. signature mismatch or checksum mismatch) where are the problems - etc Is not prone to errors, as you do not modify content at all by doing that (Maven did deliver it already), reproducibility really depends only on your build, not this 3rd party service (they blindly accepts bytes and just checks some rules "ok"/"not ok"), as for security you already provided credentials while staging. Given the "stability" history of oss or s01, I have to say that it is even _desirable_ to be able to use UI for these steps, as otherwise you are just "burning" versions (failed releases) for reasons totally unrelated to Maven, but for some 3rd party service that provides you "way" to get something to Central. Unless... we talk about some private Nx instance? Or Sonatype oss one? As in that case scripting would work for it. After all, this is proprietary software (they call it "oss" but is more like "free"), with its own proprietary REST API... T On Sun, Jul 30, 2023 at 11:37 PM Garret Wilson wrote: On 7/30/2023 6:32 PM, Tamás Cservenák wrote: There is no need for another plugin... well, let me explain: all the "vanilla" plugins of Maven (install, deploy, release) support everything that aforementioned plugin does: install at end, deploy at end, stage/deploy, there is ONLY two things they cannot do: "close" and "release" (the staging repo). For those two things, you'd need to use the browser, navigate to oss or s01 server, log in, and using Nexus UI close or release your staging repository. If this is acceptable to you, you should just drop the use of that plugin. Requiring me to use my browser and log into a site and muck around with a mouse just to release software is not acceptable. That might have been acceptable in 2003. We just don't do things like that nowadays. It's not just for convenience. It's bad practice, prone to errors, hard to reproduce, introduces security issues, unwieldy to maintain, and a general infrastructure-as-code anti-pattern for 100 reasons, which you can probably recite as well as I can. Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Well, I disagree: The App UI you are staging to will show you: - who staged, - what is staged - in case or error (ie. signature mismatch or checksum mismatch) where are the problems - etc Is not prone to errors, as you do not modify content at all by doing that (Maven did deliver it already), reproducibility really depends only on your build, not this 3rd party service (they blindly accepts bytes and just checks some rules "ok"/"not ok"), as for security you already provided credentials while staging. Given the "stability" history of oss or s01, I have to say that it is even _desirable_ to be able to use UI for these steps, as otherwise you are just "burning" versions (failed releases) for reasons totally unrelated to Maven, but for some 3rd party service that provides you "way" to get something to Central. Unless... we talk about some private Nx instance? Or Sonatype oss one? As in that case scripting would work for it. After all, this is proprietary software (they call it "oss" but is more like "free"), with its own proprietary REST API... T On Sun, Jul 30, 2023 at 11:37 PM Garret Wilson wrote: > On 7/30/2023 6:32 PM, Tamás Cservenák wrote: > > There is no need for another plugin... well, let me explain: > > all the "vanilla" plugins of Maven (install, deploy, release) support > > everything that aforementioned plugin does: install at end, deploy at > end, > > stage/deploy, there is ONLY two things they cannot do: "close" and > > "release" (the staging repo). > > > > For those two things, you'd need to use the browser, navigate to oss or > s01 > > server, log in, and using Nexus UI close or release your staging > repository. > > > > If this is acceptable to you, you should just drop the use of that > plugin. > > Requiring me to use my browser and log into a site and muck around with > a mouse just to release software is not acceptable. > > That might have been acceptable in 2003. > > We just don't do things like that nowadays. It's not just for > convenience. It's bad practice, prone to errors, hard to reproduce, > introduces security issues, unwieldy to maintain, and a general > infrastructure-as-code anti-pattern for 100 reasons, which you can > probably recite as well as I can. > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 6:32 PM, Tamás Cservenák wrote: There is no need for another plugin... well, let me explain: all the "vanilla" plugins of Maven (install, deploy, release) support everything that aforementioned plugin does: install at end, deploy at end, stage/deploy, there is ONLY two things they cannot do: "close" and "release" (the staging repo). For those two things, you'd need to use the browser, navigate to oss or s01 server, log in, and using Nexus UI close or release your staging repository. If this is acceptable to you, you should just drop the use of that plugin. Requiring me to use my browser and log into a site and muck around with a mouse just to release software is not acceptable. That might have been acceptable in 2003. We just don't do things like that nowadays. It's not just for convenience. It's bad practice, prone to errors, hard to reproduce, introduces security issues, unwieldy to maintain, and a general infrastructure-as-code anti-pattern for 100 reasons, which you can probably recite as well as I can. Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
There is no need for another plugin... well, let me explain: all the "vanilla" plugins of Maven (install, deploy, release) support everything that aforementioned plugin does: install at end, deploy at end, stage/deploy, there is ONLY two things they cannot do: "close" and "release" (the staging repo). For those two things, you'd need to use the browser, navigate to oss or s01 server, log in, and using Nexus UI close or release your staging repository. If this is acceptable to you, you should just drop the use of that plugin. If "close" or "release" from maven CLI is a "must have" for you, then... - you can opt from some scripting for example @le...@flowlogix.com did that, or, - provide some PR for that (in release plugin?)... :) HTH T On Sun, Jul 30, 2023 at 10:00 PM Garret Wilson wrote: > Oh, I'll gladly switch to another plugin. I can just change out the > whole inheritance tree—no problem. Goodness knows that this plugin has a > bunch of problems (e.g. NEXUS-26993 and NEXUS-31301, which tickets don't > seem to be visible anymore). > > I thought sure I asked about this (probably in NEXUS-26993 and/or > NEXUS-31301); I don't remember the response exactly, but I thought the > new plugin was only for some special customers. > > What should I be using instead, and where is its documentation? I want > to use the latest and greatest! > > Garret > > On 7/30/2023 4:54 PM, Tamás Cservenák wrote: > > And how about not using this plugin? Even it's maintainer dropped it, is > > EOL. Furthermore, things this plugin does means is (or is to be) unusable > > with Maven4. So is a dead end. > > > > A new project should not start using it, really. > > > > Hth > > T > > > > On Sun, Jul 30, 2023, 20:29 Garret Wilson > wrote: > > > >> I have a "root" POM which I use as the inheritance ancestor of all my > >> projects: https://github.com/globalmentor/globalmentor-root > >> > >> By default it's configured to use the [Nexus Staging Maven > >> Plugin]( > >> > https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md > ). > >> > >> It even has a handy `nexus.host` property to define the Nexus server > >> (because Sonatype actually puts accounts on separate old-school hosts, > >> but I digress). > >> > >> The catch-22 here is that I need this configuration to be turned on for > >> me to publish this POM to Maven Central, yet there are descendant > >> projects that use it that I never want to publish to Maven Central. I > >> don't want this publishing feature turned on by default in child > >> projects. I would prefer to have a flag that I simply turn on in child > >> projects (i.e. opt-in) that are to be made public. Any way to have the > >> Nexus Staging Maven Plugin enabled in the POM itself for publishing to > >> Maven Central, but have it disabled by default for inherited problems? > >> > >> I'm guessing the answer is "no", so let's instead find an easy way to > >> turn it off. I don't see in the documentation (see link above) that > >> there's even a "skip" property. Is there? I see that the Maven Deploy > >> Plugin has such a feature. I also see that there is a > >> `skipNexusStagingDeployMojo`, but that appears to be neither a > >> configuration property nor a user property, but only a "plugin flag" > >> which is "passed in from the CLI" using `-D`. Is there a "skip" > >> configuration property for the Nexus Staging Maven Plugin ? > >> > >> Does anybody know of a better approach for easily disabling publishing > >> to Maven Central in an inheriting project? > >> > >> Garret > >> > >> P.S. I'm debating whether this question would be better published on > >> Stack Overflow, but in my experience it seems that the Maven experts > >> seem to respond here more than on Stack Overflow. > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
Oh, I'll gladly switch to another plugin. I can just change out the whole inheritance tree—no problem. Goodness knows that this plugin has a bunch of problems (e.g. NEXUS-26993 and NEXUS-31301, which tickets don't seem to be visible anymore). I thought sure I asked about this (probably in NEXUS-26993 and/or NEXUS-31301); I don't remember the response exactly, but I thought the new plugin was only for some special customers. What should I be using instead, and where is its documentation? I want to use the latest and greatest! Garret On 7/30/2023 4:54 PM, Tamás Cservenák wrote: And how about not using this plugin? Even it's maintainer dropped it, is EOL. Furthermore, things this plugin does means is (or is to be) unusable with Maven4. So is a dead end. A new project should not start using it, really. Hth T On Sun, Jul 30, 2023, 20:29 Garret Wilson wrote: I have a "root" POM which I use as the inheritance ancestor of all my projects: https://github.com/globalmentor/globalmentor-root By default it's configured to use the [Nexus Staging Maven Plugin]( https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md). It even has a handy `nexus.host` property to define the Nexus server (because Sonatype actually puts accounts on separate old-school hosts, but I digress). The catch-22 here is that I need this configuration to be turned on for me to publish this POM to Maven Central, yet there are descendant projects that use it that I never want to publish to Maven Central. I don't want this publishing feature turned on by default in child projects. I would prefer to have a flag that I simply turn on in child projects (i.e. opt-in) that are to be made public. Any way to have the Nexus Staging Maven Plugin enabled in the POM itself for publishing to Maven Central, but have it disabled by default for inherited problems? I'm guessing the answer is "no", so let's instead find an easy way to turn it off. I don't see in the documentation (see link above) that there's even a "skip" property. Is there? I see that the Maven Deploy Plugin has such a feature. I also see that there is a `skipNexusStagingDeployMojo`, but that appears to be neither a configuration property nor a user property, but only a "plugin flag" which is "passed in from the CLI" using `-D`. Is there a "skip" configuration property for the Nexus Staging Maven Plugin ? Does anybody know of a better approach for easily disabling publishing to Maven Central in an inheriting project? Garret P.S. I'm debating whether this question would be better published on Stack Overflow, but in my experience it seems that the Maven experts seem to respond here more than on Stack Overflow. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
And how about not using this plugin? Even it's maintainer dropped it, is EOL. Furthermore, things this plugin does means is (or is to be) unusable with Maven4. So is a dead end. A new project should not start using it, really. Hth T On Sun, Jul 30, 2023, 20:29 Garret Wilson wrote: > I have a "root" POM which I use as the inheritance ancestor of all my > projects: https://github.com/globalmentor/globalmentor-root > > By default it's configured to use the [Nexus Staging Maven > Plugin]( > https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md). > > It even has a handy `nexus.host` property to define the Nexus server > (because Sonatype actually puts accounts on separate old-school hosts, > but I digress). > > The catch-22 here is that I need this configuration to be turned on for > me to publish this POM to Maven Central, yet there are descendant > projects that use it that I never want to publish to Maven Central. I > don't want this publishing feature turned on by default in child > projects. I would prefer to have a flag that I simply turn on in child > projects (i.e. opt-in) that are to be made public. Any way to have the > Nexus Staging Maven Plugin enabled in the POM itself for publishing to > Maven Central, but have it disabled by default for inherited problems? > > I'm guessing the answer is "no", so let's instead find an easy way to > turn it off. I don't see in the documentation (see link above) that > there's even a "skip" property. Is there? I see that the Maven Deploy > Plugin has such a feature. I also see that there is a > `skipNexusStagingDeployMojo`, but that appears to be neither a > configuration property nor a user property, but only a "plugin flag" > which is "passed in from the CLI" using `-D`. Is there a "skip" > configuration property for the Nexus Staging Maven Plugin ? > > Does anybody know of a better approach for easily disabling publishing > to Maven Central in an inheriting project? > > Garret > > P.S. I'm debating whether this question would be better published on > Stack Overflow, but in my experience it seems that the Maven experts > seem to respond here more than on Stack Overflow. > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
If its that risky not to use profiles then it shouldn't be in the root parent pom at all. Do like one would for signing: rely on the environment to be setup for that purpose, i.e. put it in settings.xml You can still have the guts of it in the pom. Delany On Sun, 30 Jul 2023 at 21:46, Garret Wilson wrote: > On 7/30/2023 4:37 PM, Mantas Gridinas wrote: > > Sounds like a job for profiles, … > > It is not a job for profiles. If I put it in a profile, a developer has > to only mistakenly use `-P nexus` or whatever the profile is, and our > super-secret million-dollar project gets published. I want it to be > disabled altogether. > > > Another idea is to have 2 poms: one for your root, the other for module > > definitions, and latter would use relative parent for the former. > > Hidden somewhere in your answer is the assumption that I do not publish > this second POM. So now I have a sharing issue—developers can no longer > use this second POM from Maven Central, and I have to have some other > distribution mechanism. > > With that in mind, I could just simply not publish the root POM to begin > with. Problem solved. Except that the problem is not solved. The problem > is how I publish a POM and have its children not have the publishing > enabled by default. Your answer, boiled down to its essence, says, "just > don't publish the root POM"—but publishing the root POM is part of the > problem statement, and what makes the problem difficult. > > > Third one is to fiddle with -m/--modules flag by telling maven to only > > include modules in the reactor provided by that flag. > > I was never too good with the violin. I would prefer not to fiddle with > things. I also don't want to use CLI flags. I simply want to have a > child POM work normally, with publishing disabled unless I add something > simple to the child POM itself. > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 4:37 PM, Mantas Gridinas wrote: Sounds like a job for profiles, … It is not a job for profiles. If I put it in a profile, a developer has to only mistakenly use `-P nexus` or whatever the profile is, and our super-secret million-dollar project gets published. I want it to be disabled altogether. Another idea is to have 2 poms: one for your root, the other for module definitions, and latter would use relative parent for the former. Hidden somewhere in your answer is the assumption that I do not publish this second POM. So now I have a sharing issue—developers can no longer use this second POM from Maven Central, and I have to have some other distribution mechanism. With that in mind, I could just simply not publish the root POM to begin with. Problem solved. Except that the problem is not solved. The problem is how I publish a POM and have its children not have the publishing enabled by default. Your answer, boiled down to its essence, says, "just don't publish the root POM"—but publishing the root POM is part of the problem statement, and what makes the problem difficult. Third one is to fiddle with -m/--modules flag by telling maven to only include modules in the reactor provided by that flag. I was never too good with the violin. I would prefer not to fiddle with things. I also don't want to use CLI flags. I simply want to have a child POM work normally, with publishing disabled unless I add something simple to the child POM itself. Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 4:00 PM, Delany wrote:
What happens if you add this to the pluginManagement/plugin section?
false
Delany
Delany, I think you are referring to the `` tag for build
plugins documented here:
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_.3Cinherited.3E_Tag_In_Build_Plugins
Thanks for pointing out this option. It's good to know this exists.
But wouldn't that prevent the entire configuration from being inherited?
Look at the [source code of the
POM](https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml)
I linked to. It has this configuration:
```
ossrh
https://${nexus.host}/
true
```
If I don't inherit the configuration, then I have to duplicate that
boilerplate int he child POMs. I _want_ to inherit the configuration. I
just don't want it to be enabled by default. That is two very different
things.
Garret
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Sounds like a job for profiles, but I do not remember if you can load modules via profiles. The idea is your default profile/pom would not include the modules block, while your "development" or some other profile would have such block. Caveat here is intellij and/or others will break once you start adding more modules because they would put them in the wrong place. Another idea is to have 2 poms: one for your root, the other for module definitions, and latter would use relative parent for the former. Your devtool would be configured to use the "fuller" pom as project definition. In this case youll be providing a different entrypoint via -f. Third one is to fiddle with -m/--modules flag by telling maven to only include modules in the reactor provided by that flag. Frankly i'd go with the modules list approach. The way i see it it's least invasive. On Sun, Jul 30, 2023, 21:29 Garret Wilson wrote: > I have a "root" POM which I use as the inheritance ancestor of all my > projects: https://github.com/globalmentor/globalmentor-root > > By default it's configured to use the [Nexus Staging Maven > Plugin]( > https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md). > > It even has a handy `nexus.host` property to define the Nexus server > (because Sonatype actually puts accounts on separate old-school hosts, > but I digress). > > The catch-22 here is that I need this configuration to be turned on for > me to publish this POM to Maven Central, yet there are descendant > projects that use it that I never want to publish to Maven Central. I > don't want this publishing feature turned on by default in child > projects. I would prefer to have a flag that I simply turn on in child > projects (i.e. opt-in) that are to be made public. Any way to have the > Nexus Staging Maven Plugin enabled in the POM itself for publishing to > Maven Central, but have it disabled by default for inherited problems? > > I'm guessing the answer is "no", so let's instead find an easy way to > turn it off. I don't see in the documentation (see link above) that > there's even a "skip" property. Is there? I see that the Maven Deploy > Plugin has such a feature. I also see that there is a > `skipNexusStagingDeployMojo`, but that appears to be neither a > configuration property nor a user property, but only a "plugin flag" > which is "passed in from the CLI" using `-D`. Is there a "skip" > configuration property for the Nexus Staging Maven Plugin ? > > Does anybody know of a better approach for easily disabling publishing > to Maven Central in an inheriting project? > > Garret > > P.S. I'm debating whether this question would be better published on > Stack Overflow, but in my experience it seems that the Maven experts > seem to respond here more than on Stack Overflow. > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
On 7/30/2023 3:45 PM, Thomas Broyer wrote: The easiest way to opt-in is to configure the plugin in of the parent POM, and then only "apply" to chosen projects by declaring the plugin in the (only needs the groupId and artifactId then) Let me make sure I'm understanding what you're suggesting: 1. Configure the plugin in `` in the root POM. 2. Do _not_ add the plugin to the `` section in the root POM. Is that what you are proposing? So then how do I publish the root POM itself to Maven Central? (That was the "catch-22" part in the description.) Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
What happens if you add this to the pluginManagement/plugin section? false Delany On Sun, 30 Jul 2023 at 20:29, Garret Wilson wrote: > I have a "root" POM which I use as the inheritance ancestor of all my > projects: https://github.com/globalmentor/globalmentor-root > > By default it's configured to use the [Nexus Staging Maven > Plugin]( > https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md). > > It even has a handy `nexus.host` property to define the Nexus server > (because Sonatype actually puts accounts on separate old-school hosts, > but I digress). > > The catch-22 here is that I need this configuration to be turned on for > me to publish this POM to Maven Central, yet there are descendant > projects that use it that I never want to publish to Maven Central. I > don't want this publishing feature turned on by default in child > projects. I would prefer to have a flag that I simply turn on in child > projects (i.e. opt-in) that are to be made public. Any way to have the > Nexus Staging Maven Plugin enabled in the POM itself for publishing to > Maven Central, but have it disabled by default for inherited problems? > > I'm guessing the answer is "no", so let's instead find an easy way to > turn it off. I don't see in the documentation (see link above) that > there's even a "skip" property. Is there? I see that the Maven Deploy > Plugin has such a feature. I also see that there is a > `skipNexusStagingDeployMojo`, but that appears to be neither a > configuration property nor a user property, but only a "plugin flag" > which is "passed in from the CLI" using `-D`. Is there a "skip" > configuration property for the Nexus Staging Maven Plugin ? > > Does anybody know of a better approach for easily disabling publishing > to Maven Central in an inheriting project? > > Garret > > P.S. I'm debating whether this question would be better published on > Stack Overflow, but in my experience it seems that the Maven experts > seem to respond here more than on Stack Overflow. > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
The easiest way to opt-in is to configure the plugin in of the parent POM, and then only "apply" to chosen projects by declaring the plugin in the (only needs the groupId and artifactId then) That only works if you're calling Maven with lifecycle phases though, I think it'll error out if you try to directly invoke the plugin's goals. (I don't know that plugin —or not enough— so can't tell if you're impacted) Le dim. 30 juil. 2023, 20:29, Garret Wilson a écrit : > I have a "root" POM which I use as the inheritance ancestor of all my > projects: https://github.com/globalmentor/globalmentor-root > > By default it's configured to use the [Nexus Staging Maven > Plugin]( > https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md). > > It even has a handy `nexus.host` property to define the Nexus server > (because Sonatype actually puts accounts on separate old-school hosts, > but I digress). > > The catch-22 here is that I need this configuration to be turned on for > me to publish this POM to Maven Central, yet there are descendant > projects that use it that I never want to publish to Maven Central. I > don't want this publishing feature turned on by default in child > projects. I would prefer to have a flag that I simply turn on in child > projects (i.e. opt-in) that are to be made public. Any way to have the > Nexus Staging Maven Plugin enabled in the POM itself for publishing to > Maven Central, but have it disabled by default for inherited problems? > > I'm guessing the answer is "no", so let's instead find an easy way to > turn it off. I don't see in the documentation (see link above) that > there's even a "skip" property. Is there? I see that the Maven Deploy > Plugin has such a feature. I also see that there is a > `skipNexusStagingDeployMojo`, but that appears to be neither a > configuration property nor a user property, but only a "plugin flag" > which is "passed in from the CLI" using `-D`. Is there a "skip" > configuration property for the Nexus Staging Maven Plugin ? > > Does anybody know of a better approach for easily disabling publishing > to Maven Central in an inheriting project? > > Garret > > P.S. I'm debating whether this question would be better published on > Stack Overflow, but in my experience it seems that the Maven experts > seem to respond here more than on Stack Overflow. > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
elegant way to disable Nexus staging/deployment in child POMs
I have a "root" POM which I use as the inheritance ancestor of all my projects: https://github.com/globalmentor/globalmentor-root By default it's configured to use the [Nexus Staging Maven Plugin](https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md). It even has a handy `nexus.host` property to define the Nexus server (because Sonatype actually puts accounts on separate old-school hosts, but I digress). The catch-22 here is that I need this configuration to be turned on for me to publish this POM to Maven Central, yet there are descendant projects that use it that I never want to publish to Maven Central. I don't want this publishing feature turned on by default in child projects. I would prefer to have a flag that I simply turn on in child projects (i.e. opt-in) that are to be made public. Any way to have the Nexus Staging Maven Plugin enabled in the POM itself for publishing to Maven Central, but have it disabled by default for inherited problems? I'm guessing the answer is "no", so let's instead find an easy way to turn it off. I don't see in the documentation (see link above) that there's even a "skip" property. Is there? I see that the Maven Deploy Plugin has such a feature. I also see that there is a `skipNexusStagingDeployMojo`, but that appears to be neither a configuration property nor a user property, but only a "plugin flag" which is "passed in from the CLI" using `-D`. Is there a "skip" configuration property for the Nexus Staging Maven Plugin ? Does anybody know of a better approach for easily disabling publishing to Maven Central in an inheriting project? Garret P.S. I'm debating whether this question would be better published on Stack Overflow, but in my experience it seems that the Maven experts seem to respond here more than on Stack Overflow. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
