Hi,
On 3/10/15 5:37 PM, Karl Heinz Marbaise wrote:
Hi,
On 3/10/15 5:03 PM, richard_senior wrote:
There is currently no phase in which you can run a plugin that is before
dependency resolution.
I missed a thing completely...
Starting with Maven 3.0.3 there exists the possibility to use an
EventSpy to extend Maven (it's not a plugin correct) but would solve
exactly your needs...
http://maven.apache.org/ref/3.0.3/maven-core/apidocs/org/apache/maven/eventspy/EventSpy.html
In the newest Maven version (3.3.0??)
http://jira.codehaus.org/browse/MNG-5771 there is more convinient way to
add extensions...
Hm...The question is what exactly would you like to solve?
I believe this is a problem for Maven.
Not really..there are some very rare special circumstances...which might
be improved...
Imagine I wanted to create a plugin which could be used by the whole
company, and enforced a particular version naming strategy.
If you really want to force a whole company the correct location would
be the repository manager and not the build tool...cause everything will
be deployed to the repository...
The naming rules can be supported by some kind of plugin for your build
tools (whatever build tool you use)...In Maven sounds like a job for
maven-enforcer...(creating your own rule) or using the existing ones...
So take Spring for example, they are using an RC and RELEASE naming
convention.
It can also being handled just simply by doing release via CI solution
which does not allow to change the versions and follow a particular rule
set...(automation is the keyword).
Imagine I wanted to allow people to name their artifacts _BRANCH_5.
What do you exactly mean? Are we talking about groupId, artifactId,
version (classifiers etc.) ?
In a corporate environment they are not allowed to do what they like
they have to follow rules (as defined)...
My plugin with find that and realise that a repository named
'http://blah/blah/BRANCH_5' should be added to the repositories list
(before
resolution obviously).
Now you are talking about repositories? Something completely different...
Also, I can now get my plugin to add a different distrubutionManagement
section allowing the artifacts to be deployed to
http://blah/blah/BRANCH_5.
In a corporate environment having different repositories will cause many
headaches...and has no benefit instead of a single repository (despite
the fact of SNAPSHOT/Releases etc.)...
Apart from that you can define some properties in distributionManagment
which can be defined on command line...and defaults can be picked up
from settings.xml file (on CI)....
By the simple act of naming artifacts I can now manage multiple
workstreams
in my pipeline with ease, and without requiring special settings files or
parent POM's.
What kind of things are you talking ?
Can you give an example?
Branches?
While I'm on the subject of Maven deficiencies, why is it not possible to
specify distrubutionManagement in settings?
Cause it's defined (xsd http://maven.apache.org/xsd/settings-1.0.0.xsd)
that way...if it's a good idea that's a different story...It might
belong into the settings.xml on the first glance..but settings.xml is
also not the best idea...see http://jira.codehaus.org/browse/MNG-5657
Furthermore there are differences between project and system
configuration parts...
And currently i see distributionManagement as project parts...which can
be defined in a corporate parent pom....
In fact.. it doesn't matter why... it's wrong.
In some rare situations it looks like being wrong....
Sometimes ... just sometimes.. I do believe I might try Gradle.
Just try Gradle...but not all that glitters is gold...
So the conclusion of your post?
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
