I've just recently started doing Java development and I picked up Maven2 for dependency management and project task automation.
One peculiar issue I've stumbled upon, that I haven't been able to fully understand, is that for certain artifacts you need to configure exclusions for their dependencies, otherwise you get a Maven Missing artifact groupId:artifactId:version:lifecycle error. I've tried creating a Spring MVC project from the supplied STS Spring project templates and the Maven POM contained exclusions for log4j, which, when removed, would produce an error.
So what do I do when I manually add a dependency and get the missing artifact error for some of it's dependencies. Do I just jump and add them to the list of exclusions or should I be more careful about it?
And why does this happen? I'm assuming it may be perhaps that an artifact has a dependency of a certain version and another artifact has the same dependency of a different version, where both can't exist on the classpath or is it something else I'm missing?
You would configure exclusions if that particular dependency is being supplied elsewhere, either explicitly in your POM, or by another dependency.
If I got an "artifact not found" message my first thought would not be to exclude it, but to find out where it's required, then add it in the relevant scope to my POM.
Related
I am trying to convert my existing web app project into maven. I have a bunch of jars in my project manually downloaded and kept in a directory. While converting to maven, I need the name of group id and artifact id of these jars so that I can mention it in pom.xml.
Is there any other way than manually searching for each jar name in mvnrepository.com?
I think you're slightly out of luck. There might be a chance that some of the jars contain the information you're looking for under
META-INF/maven/<groupId>/<artifactId>/pom.properties
But other than that, #JFabianMeier is right, it's manual labor. And please be aware that Maven uses transitive dependencies that may affect your classpath differently than when you specify the jars from a directory.
You might have to add exclusions to your POM's transitive dependencies to get the classpath as you want it.
I have three Java projects. The first is an application, com.foo:foo-application:1.0.0, and the second is a module used as a dependency to that application, com.foo:foo-framework:1.0.0. The third is a Maven plugin authored by our team, com.foo:foo-plugin:1.0.0.
My intention is that any project, e.g. foo-application, which uses classes available in foo-framework must also validate that it has used those classes correctly, where said validation is enforced by foo-plugin.
Is there a way to enforce this behaviour within foo-framework's POM.xml, whereby any Maven module which declares it as a dependency in its own POM will have foo-plugin executed as part of its build lifecycle?
No (at least no way that I'm aware of).
when you declare a dependency on something, youre declaring a dependency on its output artifacts (and transitively their dependencies as optionally described in that artifact's pom.xml file). There's no place in a pom file to force anything on the build importing it - the build importing it may not even be a maven build.
it appears you may be able to do something similar via other tools though - for example checkstyle supports discovering rules from dependencies on the classpath (not exactly what you want and depends on users of your library running checkstyle configured just right)
Is there a simple way to list the differences between the artefacts added to the classpath by one version of a Maven project and another?
Here is the problem I'm trying to solve. If I change the version of an artefact declared in a Maven project, the list of transitive dependencies added to the classpath by the dependency may change. I want know what those changes are before I commit a change to a dependency version. The primary reason I want to know what transitive dependencies will change on the classpath when I change the version number of declared dependency is concern that changing the version number of a declared dependency may cause the version of a transitive dependency to change to one that has a security vulnerability in it.
At the moment, I'm using the dependencies plugin tree goal to produce a before and after change dependency tree and then comparing the two by eye. This is not ideal.
I also know of a way to achieve my goal using the OWASP dependency check Maven plugin but this also seem not ideal.
Can anyone suggest a better solution to my problem that using the dependencies plugin or the OWASP dependency check plugin? Is there a Maven plugin to produce what I need?
Thanks
Please try
mvn dependency:list
It will list all the dependencies with version information.
now you can see the difference using any diff checker tool online.
Is there a way to install a BOM as part of maven invocation before maven tries
to resolve it. See related questions for a normal dependency
Install local jar dependency as part of the lifecycle, before Maven attempts to resolve it
Is there are way to install maven dependencies before maven attempts to resolve them?
I have tried to run a plugin in validate phase, but maven always resolved the
bom first be it a import scope bom or used as a parent bom.
About BOM: http://www.baeldung.com/spring-maven-bom
The expected usage of maven BOM is within the dependencyManagement section of a pom.xml.
Maven documentation states:
Other projects that wish to use the library should import this pom into the dependencyManagement section of their pom. (Please refer to Introduction to the Dependency Mechanism)
In a multi-module project you would usually have a dependencyManagement section with the parent pom only.
Also, just for clarification: The bom is NOT causing dependencies to the artifacts indicated therein. It is merely indicating the versions of the "ingredients" that are intended to be used together (for dependencies that are composed of several artifacts expected to be used together) in case a dependency is added somewhere in a related pom such dependencyManagement applies to.
With such setup maven will resolve the bom at time of processing dependencyManagement section. This is time of evaluating the surrounding pom.xml (or any referencing sub-module). The bom is then added to the local repository like any other dependency.
So, under normal circumstances there is no need for "fetching the bom from the net and installing it into the local repository".
Now, why would a bom artifact not be available at the time a maven call is being started?
The artifact source (repository) is not accessible
Then, downloading the artifact and providing it into local repository would be the way to go.
The artifact version is not known before (or is decided at starting time, e.g. either be specifying a profile or indicating the version as a runtime parameter)
Then the dependency mechanisms of maven still would work as expected.
The bom artifact content (list of artifacts or respective versions) is not known before (e.g. as it is depending on outcome of some build step during the build run)
Then, you likely need to rethink your build process, as it looks like you are trying to force maven into something it is not designed to support. Likely, the "dynamic" part is intrinsic to your project and thus, the dynamic dependency really should be a sub-module within your (multi-module) project. But it is really hard to advise without more input on a specific use case.
While a specific artifact to be consumed within a build step might be provided late (by relying on lazy evaluation of dependencies), this will much more difficult with bom dependencies. As such are dependency management entities that need to be resolved before the first time any dependency needs to be resolved as maven can not known what artifacts are contained within the bom.
If actually there is a usecase that absolutely requires such bom to be provided dynamically, then the only chance is a two layer process, where the top layer is providing the bom and the lower layer is then using it. Please note, that such a solution absolutely needs two independent maven processes (so, NOT just a simple multi-module project) in order to get the resolution of the depenceManagement dependency deferred until it is known.
Typically, a maven built jar artifact will have it's pom included under META-INF. I recently noticed that the Spring jars don't have this. So, that causes me to wonder about the purpose of that pom.
It seems like maven retrieves the pom directly from the repository when it's doing things that require knowledge of the artifacts meta-data, e.g. when determining dependencies.
So, what's the embedded one for?
The Maven docs suggest two reasons for the pom in this location.
1) Merely for reference, as a convenience. As the docs say, it makes the artifact "self describing"
2) You can get at this information from within your application using Java. This enables the arfiact to auto-report it's version within the application.
http://maven.apache.org/guides/getting-started/index.html
The pom you will find in the repository is not necessarily the one used to build the artifact. It is aimed at the users of the artifact and can be customized when building your artifact.
The one included inside the artifact IS the one used to produce the artifact.
There are options to not have it included in the artifact.