|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
yes, the reason for this is that this plugin doesn't run a maven reactor, but rather follows the maven conventions to read artifact information from a maven repository (http://docs.codehaus.org/display/MAVEN/Repository+Metadata). It knows nothing of pom.xml and settings.xml and other maven things.
The reason I built the plugin in the first place was to avoid bootstrapping the heavy maven just to find a couple of strings. I use it in a lot of deployment jobs which themselves don't run maven, but rather wget things for deployment or update metadata about future deployments.
Basically all the plugin does is a single HTTP GET of the maven-metadata.xml file, parses it and presents the information inside in a dropdown (or has some simple logic to select one of those versions automatically) and does some simple string concatenations to generate a few env vars.
It would be a lot of work for me to read and parse settings.xml files, or to integrate a maven reactor and I wouldn't want to do it anyway, because at the time I wrote this plugin there were others who already did that.
You can try this plugin instead if you like: https://wiki.jenkins-ci.org/display/JENKINS/Maven+Repository+Client
I myself haven't used that plugin, but it seems from the description it will do what you want.