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.
Related
I have a maven module which is configured with a feature packaging (an Apache Karaf feature). This project has no primary artifact to deploy but an attached feature.xml file. When I try to deploy the project to Github package the upload seems to work:
Uploaded to github: https://maven.pkg.github.com/cdelg-ct/repo/com/mycompany/app/my-mod/1.0-SNAPSHOT/my-mod-1.0-20200701.090836-1-features.xml
But then, the above file does not show up in the Github Packages UI and other projects cannot depend on it (Could not find artifact). Note the pom is well deployed as the other sibling jar modules.
Did anyone manage to get classifier to work with Github Maven Packages?
You are using a SNAPSHOT version.
By default, SNAPSHOT versions are not fetched.
Quick way to check it, try a release version.
If it works, you have to configure your maven settings to allow spapshots versions.
I'm currently setting up revapi-maven-plugin for a project, using latest version (0.7.0), and we want to check on our jenkins that no regression appears in our API during development.
Then for my process I don't want to check the regression between a snapshot and a release but between two snapshots.
Unfortunately (?) we use a different repository for our snapshots and our releases, and apparently revapi-maven-plugin seems not able to get the latest snapshot version from the snapshot repo.
Or is it and I did not understand how to do that?
I already put those value in my configuration but it does not change anything:
<alwaysCheckForReleaseVersion>false</alwaysCheckForReleaseVersion>
<oldVersion>LATEST</oldVersion>
This is supported since the version 0.8.0 of the revapi-maven-plugin.
The documentation of the oldVersion property reads (https://revapi.org/modules/revapi-maven-plugin/check-mojo.html#oldVersion):
If you don't want to compare a different artifact than the one being built, specifying just the old version is simpler way of specifying the old artifact. The default value is "RELEASE" meaning that the old version is the last released version of the artifact being built (either remote or found locally (to account for artifacts installed into the local repo that are not available in some public remote repository)). The version of the compared artifact will be strictly older than the version of the new artifact. If you specify "LATEST", the old version will be resolved to the newest version available remotely, including snapshots (if found in one of the repositories active in the build). The version of the compared artifact will be either older or equal to the version of the new artifact in this case to account for comparing a locally built snapshot against the latest published snapshot.
In development, I can reference the latest version of an artifact as 1.2.3-SNAPSHOT. Now I need the same behaviour for release candidates, i.e. I would like to be able to depend on the latest release candidate (there should also be a procedure for the developer to declare development versions as release candidates).
I am not sure how to implement this behaviour properly. Should I use an additional repository for release candidates and move development versions to this repository if the developer requests it? Or can I somehow define a "second snapshot list", like 1.2.3-RC?
You can get there be re-configure a few things:
use a version range for the dependency
change the updatePolicy for the repository you store the release candidates. see https://maven.apache.org/settings.html (updatePolicy). If you store the artifacts in a maven proxy usually you need to allow to overwrite releases.
Remember in a multi module build that they might upload modules before detecting a failed build (due to mvn deploy being a phase not a goal). You need to verify the complete build is ok before starting to upload artifacts in the maven repository. Or stage them somehow.
Remember this will most certainly prevent your builds being reproducible. Since an RC dependency might change between builds. You would need to change the version range - which is not always an issue. Ranges may work for you.
I've better experience to let developers stay on snapshots but have the CI server set an explicit version (for example using the versions plugin) prior to deployment / releasing for the dependency the artifact uses.
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
I use maven version range for the dependencies in my parent pom.It works fine when I do a build on snapshot or a release.
But how should I need to proceed when I want to use the specific version of dependencies in a branch ?
For example: when I use version range such as (1.2.0,) it will always fetch the latest jar from the nexus repository. The latest would be like 1.2.5 as of when I do a release, since the dependencies are getting changed over and over.Now the latest version of my dependencies is 1.2.8-SNAPSHOT
In branch when I want 1.2.5 version for my dependencies, it is always looking for the latest one which is 1.2.5+
How to resolve this, while searching for similar questions I found that it could be resolved using maven-version-plugin. That requires a changes in the pom to add the plugin. But is there a solution without changing the pom and getting exact version for a dependency?
Any suggestions?
There is no solution without changing the pom at this point, if I understand the scenario correctly: In the release of a prior version of your product, the version of one (or more) of its dependencies was not fixated to the version available at the time. Now, in support of that previous release, the build has a different result than at the time of release.
There is no suggestion except to change the branch's pom to use the 'back' version available at the time of the release. Consider it a short term fix to a bug in the release process.