In my maven project, I am looking for a way to create an artifact alias for an artifact that I have created. The reason is that a specific artifact used to be deployed under with a different artifactId and I want to keep supporting this old artifactId for the time being, even for new releases, without having to have a full duplicate module for this other artifact.
For example. Say I have the artifact foo-bar in version 1.0 of my project and I decided to rename this artifact to foo-baz in version 2.0, but I still want to support the foo-bar artifactId until the release of version 3.0, for backwards compatibility reasons.
So therefore I want to find a way to define foo-bar as an alias for foo-baz. Is this possible to do?
This is called a relocation but If I correctly remember you can't relocate an artifactId you can only relocate an groupId...Apart from that I would announce that change with the current 2.X releases and then simply change the artifactId for the first 3.X release. The decision to rename an artifact is a breaking change which in itself is a reason to make major version change..which you seemed to miss...
Related
This question is a little different than the other "checking for latest dependency version" type questions.
Let's say we have a project, DepProjA, that builds and publishes an artifact for our other Java apps to import as a dependency. For example, AppProj1 lists DepProjA as a dependency in its pom.xml file.
<dependency>
<groupId>com.mycompany.depproj</groupId>
<artifactId>depproja-lib</artifactId>
<version>feature-addthisfeature</version>
</dependency>
As you may notice, DepProjA, publishes "feature" versions of this JAR with the version named after the working branch name. This is so that other teams can test these particular feature updates before they are published as an official version update. If a bug is found and the fix is pushed under the same branch, the "feature" artifact is updated. However,when we rebuild AppProj1 to try and pull and utilize that latest artifact, it seems to be using the previous local version instead.
Is there an option, either in the pom.xml, or the mvn CLI options, so that maven will always pull down the latest artifact instead of using whatever version is cached? I know I can do a "blanket approach" like purging cache and such, but looking for something that targets specific dependencies. Kind of similar with Docker images where the tag itself won't change, but the underlying SHA can be updated when a new version of that tag is published.
An alternate idea I don't even know is possible: When publishing an artifact, is there a way to add custom metadata or labels that I could then reference? For example, I add a "cicdlabel" that could reference the pipeline ID that published the latest version. Then, I could change that in the application's dependency info when I know there is a change:
<dependency>
<groupId>com.mycompany.myproject</groupId>
<artifactId>myproject-lib</artifactId>
<version>feature-addthisfeature</version>
<cicdlabel>12345</cicdlabel>
</dependency>
In Maven by design released artifacts are immutable.
You can not update the same release version of artifact in Maven central.
It ensure that your build is reproducible, when we change content of released artifact the same build can break in the future.
In your case you should use SNAPSHOT versions for your artifact, and SNAPSHOT version can be updated.
You can use updatePolicy for your repository configuration in your settings.xml.
Yo can use mvn -U .. for update SNAPSHOT versions on every build.
I want to find all the higher versions available for each dependency and download them all of them. I tried to get the version by this command
versions:display-dependency-updates
But it is only displaying the latest version. Instead how should I find all higher versions using a java.
First of all, updating all the dependencies of a project just for having the latest version isn't the most recommended option. You may encounter unintended consequences such as, for example, changing the Java version with which the projects were compiled so you can't deploy your application on your server. My recommendation is that you always keep control of the dependencies you use in your projects and define a specific value appropriate to your needs. But if the supplier of the dependencies is a trustworthy organization and maintains compatibility between its versions, you can use the maven dependency syntax to get the latest. Dependency Version Ranges
I'm upgrading some dependency versions I have in a java/maven/spring application, which is using our nexus repo as the central repository mirroring maven central.
I tried upgrading hibernate to it's newest version of 3.5.4-Final as listed:
Hibernate newest release stable version
And when I run maven install, I see in my nexus server that there is now 3.5.4-Final listed, but inside its directory there is only a pom.xml file for the project and none of it's associated JAR's.
When I inspect the POM, I can see it's packaging is listed as POM and not JAR.
Why is this, and how can I make maven take the jar packaged version of the library rather than just the POM?
EDIT - mvn install error message posted:
[ERROR] Failed to execute goal on project app: Could not resolve dependencies for project com.app:app:war:16.2.1-SNAPSHOT: Failure to find org.hibernate:hibernate:jar:3.5.4-Final in http://ssp-nexus1.mynexus-server.com:8081/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of company.nexus.mirror has elapsed or updates are forced -> [Help 1]
As mentioned in the link you provided
Aggregator of the Hibernate Core modules.
So, the artifact you linked is effectively a pom which aggregates (as a multimodule) other Hibernate artefacts.
Instead, the hibernate-core artifact, as an example, can be found here, as a standard maven dependency (that is, a jar).
By default dependencies have type jar, so if you add the maven coordinates (GAV) for a dependency that is instead of type pom, maven will then look up for it as a jar. So that's why you are getting the error mentioned in your edit.
You should remove its dependency from your pom and only add the hibernate dependency you effectively need. As a rule of thumb, add the dependency you explicitly use in your code (as import statements, for instance) or your configuration files, and let then maven take care of the required transitive dependencies, given that they will be available on your company repository, obviously.
Update
Following your latest comments and feedback, here is a further explanation about why just changing the version of the existing Hibernate dependency you got to this issue:
The new 3.5.4-Final and the previous 3.2.7.ga version share the same groupId and artifactId on the Maven repository
However, the former has type pom (it's a pom file), while the latter has type jar (the default one)
So, the previously existing version was working fine and changing the version of the dependency you switched it from jar to pom, breaking the maven resolution (which was looking for a jar for a version which instead was a pom)
This mainly happened because you switched from a ga to a FINAL version. For a further explanation about the difference between these versions, you can check this SO question and this one
As a side note, I find a bit inconsistent that changing a version number also changes the dependency type, it might a point of debate, but if I were the Hibernate team, I would handle this version management differently.
Is there a common way of finding out which version of a Maven artifact is compiled against which Java version?
It always seems to take way too long to
Work out that it is a jvm version issue
Find out which jvm version the current aritfact uses
Track back through the versions of the artifact to find one that works
If there is not a common mechanism, do some artifacts adopt a naming convention?
There is a standard way of naming, using the classifier attribute of an artifact.
Building same project in Maven with different artifactid (based on JDK used)
I need to confirm what I suspect as I cannot find any documentation on it, so this would appear a silly question, and since I am a learner at eclipse PDE.
Initially,
I had a parent project pom of an eclipse plugin project with
<version>1.1.0-SNAPSHOT</version>
with two child projects, with both their poms referring to the parent pom as version 1.1.0-SNAPSHOT.
I was able to build the projects successfully and had a site which I use to install the plugin into eclipse.
Then, I wanted my personal temp version called 1.1.1-mine. So I modified the three poms to
1.1.1-mine
I also updated the META-INF/MANIFEST.MF and feature.xml from
0.13.0.qualifier
to
0.13.1.qualifier
However, the build encountered the following error.
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.15.0:validate-version (default-validate-version) on project org.sonatype.m2e.subclipse: OSGi version 1.1.1.qualifier in META-INF/MANIFEST.MF does not match Maven version 1.1.1-mine in pom.xml
Does qualifier have to be a maven version keyword? Because, the build proceeded without error after I changed mine to SNAPSHOT in the poms.
If not, what did I do wrong?
What can I do to allow me to have version 1.1.1-mine?
In a nutshell, OSGi .qualifier means the same thing as -SNAPSHOT.
Since OSGi doesn't allow for more than 3 numbers in a version (+ qualifier), creating a -mine version is a bit tricky.
According to the FAQ, you can tell Tycho a string that it should be use to replace qualifier with:
mvn -DforceContextQualifier=mine
Note that this disables all the goodness you get from SNAPSHOT versions (namely that you can deploy the bundle several times).