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 > >
