in the documentation of maven is written
You'll notice that all plugins in Maven look much like a dependency -
and in some ways they are. This plugin will be automatically
downloaded and used - including a specific version if you request it
(the default is to use the latest available).
Source: https://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plugins
Does "the default is to use the latest available" include snapshots or not?
Related
I've written a Maven plugin which we're using as part of our release process - as well as the usual release basically does some extra admin. I'd like to use this plugin for releasing the plugin itself but I'm not sure this is possible.
If I include the plugin in its own POM, using ${version} as the version number then I can't release because before deploying the release build it can't find the release build in the Nexus repo. If I use an earlier version, I get a clash (I don't think Maven likes two versions of the same project at once) and I'm not having any luck using a 'provided' scope as the plugin tag doesn't support this.
Is what I'm trying to do possible or should I resign myself to having a different release procedure for the plugin itself?
Thanks,
-Dave
My setup:
I'm using Grails 2.3.8
I have several private plugins I publish to my local Nexus repository manually via "grails publish-plugin"
I have several Grails applications that use these plugins
Distributed development team
My goal:
Able to deploy new versions of my private plugins and have my Grails apps automatically use those latest versions without having to modify their BuildConfig.groovy files
I know about inline/inplace plugin definitions and that is not what I want
Possible solutions:
As I understand it there might be at least two ways of achieving my goal:
Deploy snapshot versions of my plugins and have my Grails apps use those snapshot versions (e.g., version = "0.1-SNAPSHOT")
Configure my Grails apps's BuildConfig.groovy to use "latest.release" or Maven version ranges. Examples:
compile 'com.mycompany:some-plugin:latest.version'
compile 'com.mycompany:some-plugin:[0.1,)'
The problem:
The two methods above sort of work.
They both result in the latest version of my plugin to be downloaded, at least initially. However, if I publish a new version of the plugin (be it snapshot or release), re-running "grails run-app" on my Grails applications do not attempt to download/install the newer versions which are available.
I feel like the maven-metadata-*.xml files in my M2_HOME local repo are limiting the versions which are known to exist (even though Nexus has newer versions available).
When I define my Nexus repo using mavenRepo(), do I need to pass in some parameters to tell Grails to always check for new versions on the remote repo and not rely on the local repo?
Graeme's suggestion here does not seem to help either: Dependencies and lastest.release
Any help would be great. :-)
Have you configured the updatePolicy for the repository? See
http://grails.org/doc/latest/guide/conf.html#changingDependencies
Section "Aether and SNAPSHOT dependencies". Example:
mavenRepo "http://myrepo", {
updatePolicy "interval:1"
}
I'm using 2.3.7 and seemed to experience a similar problem. Using a SNAPSHOT plugin should be what you want during development. One workaround solution I used was to delete the SNAPSHOT release from Artifactory and then after building a new SNAPSHOT the plugin change was recognized. I am guessing you are using the Maven build which is now the default you could try switching to the ivy build and see if that helps. A JIRA should be created if you are able to recreate this. I believe this is an issue and I do not recall this when working with an older version (2.1.5) and using the ivy build.
i have following requirement.
i need to download the latest version of artifact from custom nexus repository rather than snapshot repository.
please suggest
Thanks.
To get the latest version of any artifact, just omit the <version> tag from the dependency. This way maven will always fetch the latest version of this artifact from the remote repo.
Warning: Keep in mind that this is not the preferred way to handle dependencies nor it is the proper flow of dependency management. By keeping the version number open ended, there is a very high probability that your project may fetch a particular version of any library that is now not backward compatible and may break your functionality in the project. It is, therefore, always recommended to specify a particular version number of all artifacts that are required for any application and when updating any library version, one should properly test it.
EDIT
For maven3 you can use the facility of an open ended version tag. Something like this
<version>[1.12.4,)</version>
Take a look into this page for further details about version ranges
According to this issue: https://issues.apache.org/jira/browse/MNG-3092 snapshots cannot be excluded (at least until this is fixed).
Old versions of maven-dependency-plugin include a dependency:properties goal. New versions don't seem to include it. Has it been moved to another plugin, or is it simply deprecated with no chance to access its features (namely having a property for each dependency, allowing as an example activation of profile based upon dependencies) ?
The properties-goal is available since version 2.2 (the latest version) of the dependency plugin. Maven 3 uses 2.1 as default, so you have to specify the version of the dependency plugin manually in your pom in the build section.
I need to create a maven artifact (org.foo.bar:blarb:1.0.0) that is dependent on exactly two versions of another artifact (org.blab.har:har:1.7.0 and org.blab.har:har:1.8.0, 1.7.1 and 1.8.1 are not allowed).
Others will be consuming my artifact downstream. Unless they explicitly specify, I want the default har artifact used to be 1.7.0. But, there can be something added to the pom to specify 1.8.0. (If it is not possible to specify a lower version as the default, I can live with 1.8.0 being the default, but would prefer not to.)
Can you show me a snippet that I would place in the blarb pom so that this can happen?
One possibility is to use version ranges.
You could try specifying the following in the dependency for org.blab.har:har
<version>[1.7.0],[1.8.0]</version>
This will indicate to maven to pick either 1.7.0 or 1.8.0. I guess the default would 1.8.0 (the higher version)