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