You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Garret Wilson <ga...@globalmentor.com> on 2023/07/30 18:28:59 UTC
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nick Stolwijk <ni...@gmail.com>.
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 <ga...@globalmentor.com> 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 <pluginManagement> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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 <pluginManagement> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nick Stolwijk <ni...@gmail.com>.
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 <pluginManagement> 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 <ga...@globalmentor.com> 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 <ga...@globalmentor.com>
> > 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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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 <ga...@globalmentor.com>
> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ga...@globalmentor.com>
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 @lenny@flowlogix.com
<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 <ga...@globalmentor.com>
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 <ga...@globalmentor.com>
> 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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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 <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 8/2/2023 10:45 PM, Garret Wilson wrote:
> …
> I won't explain here what's going on; I intend to write a blog post
> about it some day. The end result is that if the
> `com.globalmentor:globalmentor-root` POM is in effect, the
> `maven.deploy.skip` property is set to `true`; for any other
> descendant project, the `maven.deploy.skip` property is set to
> `false`. It works like this pseudocode:
(Sorry, this part of the explanation swapped `true` and `false`; it's
the opposite of what I said: if the `com.globalmentor:globalmentor-root`
POM is in effect, the `maven.deploy.skip` property is set to `false`.)
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 8/3/2023 7:31 AM, Delany wrote:
> Quite honestly this is a horrendous abuse of configuration, not to mention
> design and security principles, and thoroughly inelegant.
I 100% agree with you on your assessment of the _implementation_. If you
know of a more elegant implementation without writing a plugin, please
tell me. Otherwise, it's the fault of Maven to force me to write such an
ugly kludge. Maven should provide a simple expression language for
setting properties.
From the point of view of the _interface_ (that is, the user's view—the
developer using the child POMs), it is very clean and elegant: the
presence of a single user property determines whether deployment is
enabled or not.
Once I write a plugin that sets properties based upon an expression, we
can replace this horrendous implementation while leaving this clean and
elegant interface exactly as it is.
> It brings to mind a Go proverb "A little copying is better than a little
> dependency."
This has nothing to do with dependency. Copying boilerplate to disable
deployment would in no way lower the coupling i.e. it would not reduce
any dependency in any way.
> I've had my say though. If you want to set a property and not have it
> inherited in other repos, put it in .\.mvn\maven.config
I don't want to create other files. I want everything in my POM.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Delany <de...@gmail.com>.
Quite honestly this is a horrendous abuse of configuration, not to mention
design and security principles, and thoroughly inelegant.
It brings to mind a Go proverb "A little copying is better than a little
dependency."
I've had my say though. If you want to set a property and not have it
inherited in other repos, put it in .\.mvn\maven.config
Delany
On Thu, 3 Aug 2023 at 03:45, Garret Wilson <ga...@globalmentor.com> wrote:
> On 8/1/2023 7:42 PM, Garret Wilson wrote:
> > …
> > Now the child POMs can turn off deployment by simply setting
> > `maven.deploy.skip` to `false`, and kill two birds with one stone:
> > deployment will be disabled whether the Nexus Staging Plugin or the
> > Maven Deploy Plugin was used.
>
> In my previous message I explained how to set up the Nexus Staging
> Plugin so that it can easily be disabled in child projects (along with
> the Maven Build Plugin) using one simple property: `maven.deploy.skip`.
> Now for the next step, the grand finale.
>
> In my original question, I asked if there was a way to keep the Nexus
> Staging Plugin from being inherited in child POMs by default. Really
> "inherited" is an implementation detail. What I really wanted to know is
> if there was to configure the Nexus Staging Plugin to be enabled by
> default in the parent POM, but be disabled by default in the child POM.
> The semantic distinction is subtle, but important; it turns out that
> there's no way to turn off inheritance, but with a few tricks (i.e.
> quite a few very ugly hacks), we can change the default configuration
> based upon whether the plugin is being invoked in the parent POM (here
> `com.globalmentor:globalmentor-root`) or from some child POM.
>
> If Maven supported expressions (oh, if only), this would be rather
> straightforward. Since it doesn't we'll use
> `org.codehaus.mojo:build-helper-maven-plugin` to do things that no one
> should ever have to do (or even consider) in a POM; it looks like this:
>
> ```xml
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>build-helper-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>set-is-skip-deploy-false-or-prefixed</id>
> <phase>validate</phase>
> <goals>
> <goal>regex-property</goal>
> </goals>
> <configuration>
> <name>maven.deploy.skip</name>
> <value>_${project.groupId}_${project.artifactId}</value>
> <regex>^_com\.globalmentor_globalmentor-root$</regex>
> <replacement>false</replacement>
> <failIfNoMatch>false</failIfNoMatch>
> </configuration>
> </execution>
> <execution>
> <id>set-is-skip-deploy</id>
> <phase>initialize</phase>
> <goals>
> <goal>regex-property</goal>
> </goals>
> <configuration>
> <name>maven.deploy.skip</name>
> <value>${maven.deploy.skip}</value>
> <regex>^_.*</regex>
> <replacement>true</replacement>
> <failIfNoMatch>false</failIfNoMatch>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ```
>
> I won't explain here what's going on; I intend to write a blog post
> about it some day. The end result is that if the
> `com.globalmentor:globalmentor-root` POM is in effect, the
> `maven.deploy.skip` property is set to `true`; for any other descendant
> project, the `maven.deploy.skip` property is set to `false`. It works
> like this pseudocode:
>
> ```xml
> <properties>
>
> <maven.deploy.skip>$("${project.groupId}:${project.artifactId}}"!="com.globalmentor:globalmentor-root)</maven.deploy.skip>
> ```
>
> (Wouldn't it be nice to have expressions like this.)
>
> I succeeded in pulling off effectively what I asked for. But in reality
> I would like the `maven.deploy.skip` property to be determined by
> whether `nexus.host` is set to some value, and I want `nexus.host` to be
> set to a default value in `com.globalmentor:globalmentor-root` but not
> in child POMs. But that sort of two-layered logic (although simple if
> Maven supported expressions) is too much for the ugly kludge I'm using
> (and more than my mind wants to deal with).
>
> So in the end I settled for a sort of compromise: I made the value of
> `maven.deploy.skip` dependent on whether `nexus.host` is set to a
> non-empty string. Thus the Nexus Staging Plugin is enabled by default,
> but in any child POM I can easily turn off deployment by setting the
> `nexus.host` to the empty string, like this:
>
> ```xml
> <properties>
> <nexus.host></nexus.host>
> ```
>
> This automatically turns off `maven.deploy.skip` via this ugly kludge:
>
> ```xml
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>build-helper-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>set-is-skip-deploy-true-or-prefixed</id>
> <phase>validate</phase>
> <goals>
> <goal>regex-property</goal>
> </goals>
> <configuration>
> <name>maven.deploy.skip</name>
> <value>_${nexus.host}</value>
> <regex>^_$</regex>
> <replacement>true</replacement>
> <failIfNoMatch>false</failIfNoMatch>
> </configuration>
> </execution>
> <execution>
> <id>set-is-skip-deploy</id>
> <phase>initialize</phase>
> <goals>
> <goal>regex-property</goal>
> </goals>
> <configuration>
> <name>maven.deploy.skip</name>
> <value>${maven.deploy.skip}</value>
> <regex>^_.*</regex>
> <replacement>false</replacement>
> <failIfNoMatch>false</failIfNoMatch>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ```
>
> I'll live with this for now. I'll probably wind up writing a Maven
> set-property-from-expression plugin at some point, when I can't digest
> this sort of nasty workaround any more.
>
> Garret
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 8/1/2023 7:42 PM, Garret Wilson wrote:
> …
> Now the child POMs can turn off deployment by simply setting
> `maven.deploy.skip` to `false`, and kill two birds with one stone:
> deployment will be disabled whether the Nexus Staging Plugin or the
> Maven Deploy Plugin was used.
In my previous message I explained how to set up the Nexus Staging
Plugin so that it can easily be disabled in child projects (along with
the Maven Build Plugin) using one simple property: `maven.deploy.skip`.
Now for the next step, the grand finale.
In my original question, I asked if there was a way to keep the Nexus
Staging Plugin from being inherited in child POMs by default. Really
"inherited" is an implementation detail. What I really wanted to know is
if there was to configure the Nexus Staging Plugin to be enabled by
default in the parent POM, but be disabled by default in the child POM.
The semantic distinction is subtle, but important; it turns out that
there's no way to turn off inheritance, but with a few tricks (i.e.
quite a few very ugly hacks), we can change the default configuration
based upon whether the plugin is being invoked in the parent POM (here
`com.globalmentor:globalmentor-root`) or from some child POM.
If Maven supported expressions (oh, if only), this would be rather
straightforward. Since it doesn't we'll use
`org.codehaus.mojo:build-helper-maven-plugin` to do things that no one
should ever have to do (or even consider) in a POM; it looks like this:
```xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>set-is-skip-deploy-false-or-prefixed</id>
<phase>validate</phase>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>maven.deploy.skip</name>
<value>_${project.groupId}_${project.artifactId}</value>
<regex>^_com\.globalmentor_globalmentor-root$</regex>
<replacement>false</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
<execution>
<id>set-is-skip-deploy</id>
<phase>initialize</phase>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>maven.deploy.skip</name>
<value>${maven.deploy.skip}</value>
<regex>^_.*</regex>
<replacement>true</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
```
I won't explain here what's going on; I intend to write a blog post
about it some day. The end result is that if the
`com.globalmentor:globalmentor-root` POM is in effect, the
`maven.deploy.skip` property is set to `true`; for any other descendant
project, the `maven.deploy.skip` property is set to `false`. It works
like this pseudocode:
```xml
<properties>
<maven.deploy.skip>$("${project.groupId}:${project.artifactId}}"!="com.globalmentor:globalmentor-root)</maven.deploy.skip>
```
(Wouldn't it be nice to have expressions like this.)
I succeeded in pulling off effectively what I asked for. But in reality
I would like the `maven.deploy.skip` property to be determined by
whether `nexus.host` is set to some value, and I want `nexus.host` to be
set to a default value in `com.globalmentor:globalmentor-root` but not
in child POMs. But that sort of two-layered logic (although simple if
Maven supported expressions) is too much for the ugly kludge I'm using
(and more than my mind wants to deal with).
So in the end I settled for a sort of compromise: I made the value of
`maven.deploy.skip` dependent on whether `nexus.host` is set to a
non-empty string. Thus the Nexus Staging Plugin is enabled by default,
but in any child POM I can easily turn off deployment by setting the
`nexus.host` to the empty string, like this:
```xml
<properties>
<nexus.host></nexus.host>
```
This automatically turns off `maven.deploy.skip` via this ugly kludge:
```xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>set-is-skip-deploy-true-or-prefixed</id>
<phase>validate</phase>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>maven.deploy.skip</name>
<value>_${nexus.host}</value>
<regex>^_$</regex>
<replacement>true</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
<execution>
<id>set-is-skip-deploy</id>
<phase>initialize</phase>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>maven.deploy.skip</name>
<value>${maven.deploy.skip}</value>
<regex>^_.*</regex>
<replacement>false</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
```
I'll live with this for now. I'll probably wind up writing a Maven
set-property-from-expression plugin at some point, when I can't digest
this sort of nasty workaround any more.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 7/30/2023 3:28 PM, Garret Wilson wrote:
> … 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 ?
Answering my own question: yes, the `skipNexusStagingDeployMojo` "flag"
indeed seems to work as a "configuration property". Setting this to
`true` disables the entire Nexus Staging Plugin, and the default Maven
Deploy Plugin doesn't seem to run either (because I assume that the
Nexus Staging Plugin has disabled it anyway).
> [INFO] Skipping Nexus Staging Deploy Mojo at user's demand.
If I were to remove the Nexus Staging Plugin, I _assume_ that the Maven
Deploy Plugin would take effect, in which case I would need to set its
`skip` configuration property to `true` (or set the `maven.deploy.skip`
user property).
This simple answer is a big step forward, but it's only halfway to
easily turning this off in the child POM. (Yes, I want things to be
easier than redeclaring a plugin configuration in the child POM.) The
next "obvious" step is to create a user property to turn off the Nexus
Staging Plugin. And we already have one—the `maven.deploy.skip` user
property for the Maven Deploy Plugin! So all we have to do is add this
to the Nexus Staging Plugin:
```xml
<skipNexusStagingDeployMojo>${maven.deploy.skip}</skipNexusStagingDeployMojo>
```
Now the child POMs can turn off deployment by simply setting
`maven.deploy.skip` to `false`, and kill two birds with one stone:
deployment will be disabled whether the Nexus Staging Plugin or the
Maven Deploy Plugin was used.
See, things don't have to be difficult.
I have one more tweak to make things even easier and protect even more
against accidental deployment. I'll explain how in a separate message.
Best,
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Thomas Broyer <t....@gmail.com>.
Le dim. 30 juil. 2023, 21:36, Garret Wilson <ga...@globalmentor.com> a
écrit :
> On 7/30/2023 3:45 PM, Thomas Broyer wrote:
> > The easiest way to opt-in is to configure the plugin in
> <pluginManagement>
> > of the parent POM, and then only "apply" to chosen projects by declaring
> > the plugin in the <build><plugins> (only needs the groupId and artifactId
> > then)
>
> Let me make sure I'm understanding what you're suggesting:
>
> 1. Configure the plugin in `<pluginManagement>` in the root POM.
>
> 2. Do _not_ add the plugin to the `<build><plugins>` 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.)
>
That's what I was proposing, yes (and I did miss the catch-22). But you can
add the plugin to the <build><plugins> in the root POM with
<inherit>false</inherit> as suggested by Delany.
The configuration will be inherited by all projects through the
pluginManagement as soon as you add the plugin to <build><plugins> of that
project (or a parent project).
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 7/30/2023 3:45 PM, Thomas Broyer wrote:
> The easiest way to opt-in is to configure the plugin in <pluginManagement>
> of the parent POM, and then only "apply" to chosen projects by declaring
> the plugin in the <build><plugins> (only needs the groupId and artifactId
> then)
Let me make sure I'm understanding what you're suggesting:
1. Configure the plugin in `<pluginManagement>` in the root POM.
2. Do _not_ add the plugin to the `<build><plugins>` 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Thomas Broyer <t....@gmail.com>.
The easiest way to opt-in is to configure the plugin in <pluginManagement>
of the parent POM, and then only "apply" to chosen projects by declaring
the plugin in the <build><plugins> (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 <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nils Breunese <ni...@breun.nl>.
Delany <de...@gmail.com> wrote:
> Oh hi Nils. Yeah well a compromise is reached. I would still support a ban
> on <servers> tag in project-specific settings - more for enforcer.
> Its just about maintaining good abstractions. "User settings" what should
> that mean? Its basically the settings that a user doesn't want to commit.
>
> You wanted "This is currently the only artifact repository that our build
> pipelines can access, but developers will sometimes want to build a project
> locally that requires other artifact repositories, e.g. a third-party
> GitHub project or an experimental Proof of Concept project which requires
> dependencies from a repository that hasn't been added to our in-company
> artifact repository yet. A global settings file that defaults to our
> private artifact repository would interfere with such local builds."
>
> I just don't get the use case since I regularly make use of an alternative
> repository configured in my user settings when I test maven pre-releases
>
> <profile>
> <id>stage</id>
> <activation>
> <property>
> <name>stage</name>
> </property>
> </activation>
> <repositories>
> <repository>
> <id>staging</id>
> <name>Maven Staging</name>
> <url>
> https://repository.apache.org/content/repositories/maven-${stage}/</url>
> </repository>
> </repositories>
> <pluginRepositories>
> <pluginRepository>
> <id>staging-plugin</id>
> <name>Maven Staging</name>
> <url>
> https://repository.apache.org/content/repositories/maven-${stage}/</url>
> </pluginRepository>
> </pluginRepositories>
> </profile>
> </profiles>
> </settings>
>
> When abstractions erode it becomes difficult to think. In this case though
> the idea of user settings was never a strong one.
We want our internal projects to be self-contained, so they work without a requirement for specific user or global Maven configuration, and we don’t want to require any non-internal projects to require any specific user or global Maven configuration either.
I’ve worked at companies we’re they said ‘your ~/.m2/settings.xml file needs to look exactly like this’, but then working with projects from outside the company (open source projects from GitHub for instance) became a hassle, because you need to temporarily change your user settings whenever you want to work with an external project on your machine. And of course there were always issues with people using an outdated or otherwise incorrect user settings file.
To get rid of those issues, we put `--settings=.mvn/settings.xml` in .mvn/maven.config in our internal projects to automatically apply the settings file included in the project (we have a Spring Initializr-based project generator which automatically adds these files in every project), which works, except that it doesn’t when Maven is not run from the root directory of a multi-module project. I understand project-specific settings should get rid of that limitation.
If anyone can think of a nicer solution than project-specific settings to accomplish such self-contained projects, I’d love to hear about it, because I agree that the project-specific settings feature also opens a new door to “you’re doing it wrong”.
Nils.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Delany <de...@gmail.com>.
Oh hi Nils. Yeah well a compromise is reached. I would still support a ban
on <servers> tag in project-specific settings - more for enforcer.
Its just about maintaining good abstractions. "User settings" what should
that mean? Its basically the settings that a user doesn't want to commit.
You wanted "This is currently the only artifact repository that our build
pipelines can access, but developers will sometimes want to build a project
locally that requires other artifact repositories, e.g. a third-party
GitHub project or an experimental Proof of Concept project which requires
dependencies from a repository that hasn't been added to our in-company
artifact repository yet. A global settings file that defaults to our
private artifact repository would interfere with such local builds."
I just don't get the use case since I regularly make use of an alternative
repository configured in my user settings when I test maven pre-releases
<profile>
<id>stage</id>
<activation>
<property>
<name>stage</name>
</property>
</activation>
<repositories>
<repository>
<id>staging</id>
<name>Maven Staging</name>
<url>
https://repository.apache.org/content/repositories/maven-${stage}/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>staging-plugin</id>
<name>Maven Staging</name>
<url>
https://repository.apache.org/content/repositories/maven-${stage}/</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
</settings>
When abstractions erode it becomes difficult to think. In this case though
the idea of user settings was never a strong one.
Delany
On Mon, 31 Jul 2023 at 18:44, Nils Breunese <ni...@breun.nl> wrote:
> Delany <de...@gmail.com> wrote:
>
> > In any case, what repository on the Internet is configured to allow
> > anonymous uploads? The settings.xml must always be populated with
> <server>
> > credentials for a deployment to take place.
> > If you fear someone accidentally uploading artefacts to random repos then
> > "you're doing it wrong". Credential in settings.xml and managed manually
> or
> > someone other provisioning system = a good night sleep
> > That's why I'm not a fan of
> https://issues.apache.org/jira/browse/MNG-5659
>
> If you’re committing any file with credentials "you’re doing it wrong”.
> There are however also valid use cases for which project-specific settings
> are a very nice solution, so I’m happy it’s finally coming in Maven 4.
>
> Nils.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nils Breunese <ni...@breun.nl>.
Delany <de...@gmail.com> wrote:
> In any case, what repository on the Internet is configured to allow
> anonymous uploads? The settings.xml must always be populated with <server>
> credentials for a deployment to take place.
> If you fear someone accidentally uploading artefacts to random repos then
> "you're doing it wrong". Credential in settings.xml and managed manually or
> someone other provisioning system = a good night sleep
> That's why I'm not a fan of https://issues.apache.org/jira/browse/MNG-5659
If you’re committing any file with credentials "you’re doing it wrong”. There are however also valid use cases for which project-specific settings are a very nice solution, so I’m happy it’s finally coming in Maven 4.
Nils.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 7/31/2023 1:27 PM, Delany wrote:
> …
>
> In any case, what repository on the Internet is configured to allow
> anonymous uploads? The settings.xml must always be populated with <server>
> credentials for a deployment to take place.
> If you fear someone accidentally uploading artefacts to random repos then
> "you're doing it wrong".
This question was never about "anonymous uploads" or "random repos". The
parent POM specifies a specific server, for which specific credentials
are specified in `settings.xml`. The issue is that this configuration is
inherited, so this question was simply how to elegantly disable this
behavior in child POMs, to prevent accidentally deploying a child
project to the same server with the same credentials as inherited from
the parent POM.
Your `<phase>none</phase>` idea is probably the best I'm going to get,
thanks. I'll add appropriate tricks to make that more easily configured
via a property, which I already know how to do.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Delany <de...@gmail.com>.
Deploy is a phase in the default lifecycle
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
So whatever plugins are bound to that phase will be executed if you ask
Maven to run to that phase. To see what those executions would be, run
mvn fr.jcgay.maven.plugins:buildplan-maven-plugin:1.5:list-phase
The "deploy" goal of the deploy-maven-plugin requires configuration of the
<distributionManagement> section
https://maven.apache.org/plugins/maven-deploy-plugin/usage.html
In any case, what repository on the Internet is configured to allow
anonymous uploads? The settings.xml must always be populated with <server>
credentials for a deployment to take place.
If you fear someone accidentally uploading artefacts to random repos then
"you're doing it wrong". Credential in settings.xml and managed manually or
someone other provisioning system = a good night sleep
That's why I'm not a fan of https://issues.apache.org/jira/browse/MNG-5659
Delany
On Mon, 31 Jul 2023 at 18:02, Garret Wilson <ga...@globalmentor.com> wrote:
> On 7/31/2023 3:07 AM, Delany wrote:
> > Perhaps you're getting confused because you conflate 2 issues:
> > … prevent general configuration like <licenses> from being inherited.
> > … preventing plugin configuration from being inherited.
>
> I do not conflate them—I do not think they are the same thing. I said
> they are both similar in one aspect: they have to be defined in order to
> publish the parent POM itself, but they semantically may not apply to
> projects that _use_ the parent POM, and thus may not be desired to be
> inherited.
>
> But I don't want to get off-track; perhaps it was unwise to even mention
> the `<license>` issue and risk going down a different rabbit hole. I'll
> stick to the plugin configuration inheritance topic.
>
> > The second, to disable executions by default, just configure the phase to
> > none. Do this if the plugin/goal lacks a <skip> parameter.
>
> Ah, I had forgotten about the `<phase>none</phase>` trick—thanks for
> reminding me, Delany.
>
> Let me confirm something: if I disable the Nexus Staging Maven Plugin by
> using `<phase>none</phase>` in a child POM, what will happen when a
> developer types `mvn deploy`? Nothing? I only ask because Tamás had
> mentioned the Maven Deploy Plugin. But I'm looking at the latest [super
> POM](https://maven.apache.org/ref/3.9.3/maven-model-builder/super-pom.html),
>
> and it looks like Maven Deploy Plugin is only activated in the
> `performRelease` profile (which is to be removed anyway).
>
> So if using `<phase>none</phase>` with the Nexus Staging Maven Plugin
> completely disables all staging and deployment, that may be the easiest
> way to disable it in the child POM. Thanks again for the tip.
>
> Garret
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 7/31/2023 1:02 PM, Garret Wilson wrote:
> …
> Let me confirm something: if I disable the Nexus Staging Maven Plugin
> by using `<phase>none</phase>` in a child POM, what will happen when a
> developer types `mvn deploy`? Nothing? I only ask because Tamás had
> mentioned the Maven Deploy Plugin. But I'm looking at the latest
> [super
> POM](https://maven.apache.org/ref/3.9.3/maven-model-builder/super-pom.html),
> and it looks like Maven Deploy Plugin is only activated in the
> `performRelease` profile (which is to be removed anyway).
Oops, nope, it looks like Maven somewhere internally (not in the Super
POM) still associates the Maven Deploy Plugin with the `deploy` phase:
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#default-lifecycle-bindings-packaging-ejb-ejb3-jar-par-rar-war
I guess if I want _all_ deployment disabled (I'll replace it with
something more interesting later—that's a whole different topic) in a
child POM, I'll need to set `<phase>none</phase>` for the Nexus Staging
Maven Plugin, and set `<skip>true</skip>` for the Maven Deploy Plugin.
(I see that Delany's response came as I was typing this; I'll still send
it because of the documentation link and the summary.)
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 7/31/2023 3:07 AM, Delany wrote:
> Perhaps you're getting confused because you conflate 2 issues:
> … prevent general configuration like <licenses> from being inherited.
> … preventing plugin configuration from being inherited.
I do not conflate them—I do not think they are the same thing. I said
they are both similar in one aspect: they have to be defined in order to
publish the parent POM itself, but they semantically may not apply to
projects that _use_ the parent POM, and thus may not be desired to be
inherited.
But I don't want to get off-track; perhaps it was unwise to even mention
the `<license>` issue and risk going down a different rabbit hole. I'll
stick to the plugin configuration inheritance topic.
> The second, to disable executions by default, just configure the phase to
> none. Do this if the plugin/goal lacks a <skip> parameter.
Ah, I had forgotten about the `<phase>none</phase>` trick—thanks for
reminding me, Delany.
Let me confirm something: if I disable the Nexus Staging Maven Plugin by
using `<phase>none</phase>` in a child POM, what will happen when a
developer types `mvn deploy`? Nothing? I only ask because Tamás had
mentioned the Maven Deploy Plugin. But I'm looking at the latest [super
POM](https://maven.apache.org/ref/3.9.3/maven-model-builder/super-pom.html),
and it looks like Maven Deploy Plugin is only activated in the
`performRelease` profile (which is to be removed anyway).
So if using `<phase>none</phase>` with the Nexus Staging Maven Plugin
completely disables all staging and deployment, that may be the easiest
way to disable it in the child POM. Thanks again for the tip.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Delany <de...@gmail.com>.
Perhaps you're getting confused because you conflate 2 issues:
One is about a way to prevent general configuration like <licenses> from
being inherited. Currently the only way to do this is through profiles -
which you reject off-hand.
Allowing a project model to be composited with MNG-5102 is another possible
solution.
The other is about preventing plugin configuration from being inherited.
But again there are 2 sides: general plugin configuration and execution
configuration.
You use inherited tag to prevent the first.
The second, to disable executions by default, just configure the phase to
none. Do this if the plugin/goal lacks a <skip> parameter. And if you want
the execution to fire on the parent, set the phase to none in
pluginManagement and a valid phase in plugin, but add inherited=false.
Profiles are not perfect but they do the job, and you can literally use
them for everything, including modules (although your IDE might be unhappy
about it).
You want convenience, but not too convenient! But you can't have your cake
and eat it.
For super-secret configuration, rely on configuring the build environment
via settings.xml.
Delany
On Mon, 31 Jul 2023 at 03:05, Garret Wilson <ga...@globalmentor.com> wrote:
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nick Stolwijk <ni...@gmail.com>.
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 <ga...@globalmentor.com> 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 <ga...@globalmentor.com>
> 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 `<license>`](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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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 <ga...@globalmentor.com> 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 `<license>`](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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nick Stolwijk <ni...@gmail.com>.
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 <ga...@globalmentor.com> 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 `<license>`](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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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 `<license>`](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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Nils Breunese <ni...@breun.nl>.
Garret Wilson <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Delany <de...@gmail.com>.
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 <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Mantas Gridinas <mg...@gmail.com>.
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 <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Garret Wilson <ga...@globalmentor.com>.
On 7/30/2023 4:00 PM, Delany wrote:
> What happens if you add this to the pluginManagement/plugin section?
>
> <inherited>false</inherited>
>
> Delany
Delany, I think you are referring to the `<inherited>` 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:
```
<configuration>
<serverId>ossrh</serverId>
<nexusUrl>https://${nexus.host}/</nexusUrl>
<autoReleaseAfterClose>true</autoReleaseAfterClose>
</configuration>
```
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: elegant way to disable Nexus staging/deployment in child POMs
Posted by Delany <de...@gmail.com>.
What happens if you add this to the pluginManagement/plugin section?
<inherited>false</inherited>
Delany
On Sun, 30 Jul 2023 at 20:29, Garret Wilson <ga...@globalmentor.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>