Hi Robert,
> Hi Karl-Heinz,
All maven-dependencies used by a plugin are removed from the plugin
classpath. These classes will be picked up from its parent classloader:
the executing Maven instance.
For that reason I don't see the need to split it up into 2 separate
modules. I would upgrade the
Hi Karl-Heinz,
All maven-dependencies used by a plugin are removed from the plugin
classpath. These classes will be picked up from its parent classloader:
the executing Maven instance.
For that reason I don't see the need to split it up into 2 separate
modules. I would upgrade the Maven dep
Hi Robert,
first thanks for your thoughs and hints...
> Hi Karl-Heinz,
Let's make a clear separation between the plugin, the enforcer-api and
the standard rules.
Only the first one can be restricted to a specific Maven version by
specifying the prerequisite for Maven.
Although the standard
Hi Karl-Heinz,
Let's make a clear separation between the plugin, the enforcer-api and the
standard rules.
Only the first one can be restricted to a specific Maven version by
specifying the prerequisite for Maven.
Although the standard rules are included by default, there's no real
relations
Hi Robert,
first of all thanks for your answer
> For Maven2 all arguments are immediately processed, you can't trace back
the values of -pl or -amd.
I think you should go for the easy and solid solution by requiring
specific Maven versions.
For instance: In the rule, read the version value
Hi Karl Heinz,
For Maven2 all arguments are immediately processed, you can't trace back
the values of -pl or -amd.
I think you should go for the easy and solid solution by requiring
specific Maven versions.
For instance: In the rule, read the version value of
/META-INF/maven/org.apache.mave
Hi to all devs...
currently I'm struggling with the above implementation. The current
implementation works fine with all tests etc. But based on the above
issue (of course needed)
So if i like to check the Maven -pl Options ..
Robert Scholte already gave me some hints to use things like
