Develop Reference

How to ignore a dependency in dependency-lock-maven-plugin

In my maven project I want to implement dependency-locking.
One approach I've found is using dependency-lock-maven-plugin.
My project has multiple maven modules.
parent
core
service
third-maven-module
When I run mvn clean package it will generate a new core-0.0.1-SNAPSHOT.jar every time.
Now apart from checking version dependency-lock-maven-plugin also checks SHA, which in this case gets changed every time & then the plugin throws error stating SHA is different.
Now to avoid this in plugin's version 0.0.78f56707b3a1d639c8e769bba1686587e9a8956 we can simple add below lines:
<configuration>
<ignore>
<dependency>com.myservice:core:*</dependency>
</ignore>
</configuration>
It works but now I can see that this version has vulnerabilities, so I want to use the latest version 1.0
But it looks like the configuration to ignore a dependency has been changed & documentation does not says much.
Please suggest how can I ignore a dependency in dependency-lock-maven-plugin.

maven tries to retrieve wrong snapshot version from repository because of bad maven-metadata.xml

I'm using maven to fetch dependencies from our company's internal repositories. We use Artifactory. Everything works ok, but sometimes I have a recurring problem. After mvn -U clean compile I get an error.
Could not resolve dependencies for project company_groupId:company_dependency-articfactId:jar:0.0.1-SNAPSHOT: Could not find artifact company_groupId:company_dependency-articfactId:jar:2.0.17-20210429.123648-56 in snapshots2 (https://company.repository/snapshots)
When I look which jars repository actually contains, it appears it has 3 files in company_dependency-articfactId/0.0.1-SNAPSHOT
maven-metadata.xml
company_dependency-articfactId-2.0.17-20210430.091957-56.jar
company_dependency-articfactId-2.0.17-20210430.091957-56.pom
So, maven searches for date 20210429 and what repository actually contains is date 20210430 .
I thought maybe something removes dependencies, but the I looked inside maven-metadata.xml .
Comments added for better understanding.
<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
<groupId>company_dependencyId</groupId>
<artifactId>company_dependency-articfactId</artifactId>
<version>2.0.17-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20210430.091957</timestamp> <!-- ok version -->
<buildNumber>56</buildNumber>
</snapshot>
<lastUpdated>20210430092512</lastUpdated>
<snapshotVersions>
<snapshotVersion>
<extension>jar</extension>
<value>2.0.17-20210429.123648-56</value> <!-- WRONG version -->
<updated>20210429123648</updated>
</snapshotVersion>
<snapshotVersion>
<extension>pom</extension>
<value>2.0.17-20210430.091957-56</value> <!-- ok version -->
<updated>20210430091957</updated>
</snapshotVersion>
</snapshotVersions>
</versioning>
</metadata>
As you can see, jar version of snapshot actually points to the wrong jar, which doesn't exist.
I looked at other dependencies and they're ok. So it's not something, which happens to all artifacts at a specific date.
I've no idea what could have caused this. Maybe somebody has already encountered such an issue?
Also I have couple of specific questions.
Could this mismatch between pom and jar versions of snapshots occur naturally? Like a script, which uploads next version for pom, but not for jar?
Could it be some kind of an error, when we have already uploaded pom, but couldn't upload jar for some reason? I mean it probably could happen, but is it reasonable to think that actually happens regularly?
Maybe it's a normal thing to upload pom and jar separately?
I haven't experienced anything like that before, so any help is much appreciated.

There's a couple of bugs in Artifactory, which could have caused this. For example https://www.jfrog.com/jira/browse/RTFACT-21321 https://www.jfrog.com/jira/browse/RTFACT-6514 or https://www.jfrog.com/jira/browse/RTFACT-21321 .
The problem could be solved by recreating metadata as J Fabian Meier suggested.

Got same problem. After some research it seams to be a known & already fixed bug https://issues.apache.org/jira/browse/MNG-6754.
Upgrading your maven should fix it.

Maven dependency: ranges resolving issue

I want to use a range for the version of some dependency. But I don't really get it how it should be defined for my case.
Here's the results of lookup - maven-metadata-nexus.xml file.
<versioning>
<latest>0.1.0-SNAPSHOT</latest>
<versions>
<version>0.0.13-SNAPSHOT</version>
<version>0.0.14-SNAPSHOT</version>
<version>0.0.15-SNAPSHOT</version>
<version>0.0.16-SNAPSHOT</version>
<version>0.0.17-SNAPSHOT</version>
<version>0.1.0-SNAPSHOT</version>
</versions>
<lastUpdated>20190826092951</lastUpdated>
</versioning>
I want to import the latest 0.1.x dependency, so I thought writing range this way would do the thing
<dependency>
<groupId>my.group.id</groupId>
<artifactId>my-artifact</artifactId>
<version>[0.1, 0.2)</version>
</dependency>
However, maven says that there's no version of my artifact available.
Defining range as [0.1.0-SNAPSHOT, 0.2) fixes the problem, but I don't really understand why I need to be so specific with the boundary and is it a good practice or not. What's the right way to define such ranges?

Maven treats SNAPSHOT version differently than "normal" versions.
"normal" (published in a repo) version is typically immutable. It can't be updated nor removed and no matter when you access it will still be the same.
SNAPSHOT versions are the opposite of that. They can change at any time (think work in progress).
Typically SNAPSHOTs are only to be found in your local repo. If you want to use SNAPSHOTs from remote repo you have to explicitly tell Maven that repo provides SNAPSHOT versions.
With that distinction in mind, Maven folks have decided that
Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. There is no need to compile against development code unless you are explicitly using a new feature, under which the snapshot will become the lower bound of your version specification.

JBPM6 process definition versioning

We have process definition deployed in production and lots of process instances are initialized and in flight.
Now there are changes required to be done in process definition (.bpmn file) to accommodate other business scenarios.
We understand that we can not just replace the old .bpmn file with new one because old .bpmn file may be referred by in flight processes.
What is easiest and best way to handle this situation?
Note: We are using JBPM 6.0

To create a new version:
Make your edits to the process definition and anything else in the project.
Make sure the project and process definition is saved.
In the Project editor->Project General Settings change the version number.
Save, build and deploy.
A new version is deployed. The deployment id will have the new version number:
GenusOU:MCTestWF1:2.0
In the repository there will be a separate version directory for each version in the project.
The project's maven-metadata.xml will contain all versions:
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>GenusOU</groupId>
<artifactId>MCTestWF1</artifactId>
<versioning>
<release>3.0</release>
<versions>
<version>1.0</version>
<version>2.0</version>
<version>3.0</version>
</versions>
<lastUpdated>20160825183701</lastUpdated>
</versioning>
</metadata>

Finding list of versions available in a Maven repository for a specific plugin?

Given the following repository URL from my pom.xml how can I determine what the latest versions of spring and hibernate are available in the repository?
http://repo1.maven.org/maven2

Retrieve the maven-metadata.xml file, placed in the artifact directory, e.g. https://repo1.maven.org/maven2/com/sun/media/jai_codec/maven-metadata.xml for an artifact with the groupId com.sun.media and artifactId jai_codec.
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>com.example</groupId>
<artifactId>project</artifactId>
<versioning>
<latest>0.0.5</latest>
<release>0.0.5</release>
<versions>
<version>0.0.3</version>
<version>0.0.4</version>
<version>0.0.5</version>
</versions>
<lastUpdated>20090725212606</lastUpdated>
</versioning>
</metadata>

Programatically or just manually?
Since the repository works over HTTP you can just navigate it manually:
http://repo2.maven.org/maven2/org/springframework/spring/
http://repo2.maven.org/maven2/org/hibernate/hibernate/
http://repo2.maven.org/maven2/org/hibernate/hibernate-core/

As Robert's answer says, the maven-metadata.xml file for each artifact in the repository holds the version information you need. In particular note the latest and release elements in the metadata. The latest element denotes the last version to be published, this may not be the version you want though. For example it could be a maintenance release to an older version, a release candidate, or a milestone. The release version denotes the last published version intended to be treated as a release, so generally you'd want to take this version.
For information the Maven super POM has a special release-profile profile, activated by setting the performRelease property (e.g. by passing -DperformRelease on the command line). Amongst other things, activating this property will set the updateReleaseInfo property of the deploy-plugin so that the metadata will be updated when you deploy.

Depending on what the real use case is, it can be worth looking at http://www.mojohaus.org/versions-maven-plugin/