Jörg,

I asked for a working example and not theory for a reason: The plugin
POM already uses properties, and it simply does not work to override
them. Example:

<properties>
  <foo.version>1</foo.version>
</properties>
...
<dependency>
  <groupId>org.acme</groupId>
  <artifactId>foo</artifactId>
  <version>${foo.version}</version>
</dependency>

Now, the project using the plugin does this:

<properties>
  <foo.version>2</foo.version>
</properties>

<plugin>
  <groupId>org.acme</groupId>
  <artifactId>my-plugin</artifactId>
  <version>3</version>
</plugin>

Overriding the property in the project using the plugin does not seem to
have any effect. I verified that the plugin POM still contains the
property and the version number is not flattened in any way.

Is this even supposed to work like that? Are plugin properties
overridable like this? It would be nice, but I guess they are not part
of the reactor. That is also the reason why my project can use one
version of a dependency and a plugin can use another one without them
affecting each other.

So please, if you have a working example for what you say should work,
please provide it, so I can reproducer what you recommend me to do.

-- 
Alexander Kriegisch
https://scrum-master.de


Jörg Schaible schrieb am 06.02.2024 04:58 (GMT +07:00):

> Hello Alexander,
> 
> On Sunday, 4. February 2024, 04:20:22 CET Alexander Kriegisch write:
>> Hi Jörg.
>> 
>> Thanks for the reply. Can you please elaborate with examples? Option 1
>> is what I need, but that does not work. Or maybe we have a
>> misunderstanding about the term "property". Are we talking about a
>> simple Maven property or a mojo configuration property?
> 
> We're talking about "simple" Maven properties. However, since we talk about 
> dependencies of a plugin, there's one important thing to know: A plugin is 
> loaded only once in a reactor, i.e. its first usage will define its 
> dependencies. And, the property approach will not work, if you flatten your 
> parent pom, i.e. the property is replaced by its value before deploying to a 
> repository.
> 
> Regards,
> Jörg
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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

Reply via email to