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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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),
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
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
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
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
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
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
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:
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
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
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
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
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
38 matches
Mail list logo