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.
Related
There are a fair amount of questions online involving how to use Maven / Aether to download dependencies for a given artifact.
I am however stumped as to downloading the parent poms.
I have similar code found online that does
CollectResult result = system.collectDependencies(session, request);
However the result is strictly the dependencies (compile, test, provided, runtime etc..) of the given artifact.
I am trying to setup an "offline" maven repository and as such need all relevant pom files as well. Certain plugins set a parent pom that I need to make sure is included as part of this transitive closure.
Additional Rationale
I am working on developing a solution to wrap Maven applications as a Nix derivation.
In order to attain hermetic/reproducible builds Nix disallows access to the internet; which means using Maven traditionally does not work.
I can instead pre-hydrate a maven repository given the known dependencies.
I am working on a project https://github.com/fzakaria/mvn2nix which turns a Maven (pom.xml) into a full list of all dependencies needed so that they can be downloaded.
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)
I'm trying to use a number of the BOMs in the org.jboss.bom group to bring in the API stacks that are compatible with EAP 6.3.0. My understanding is, that's what they're for. But when I reference them (using 'provided' or even 'compile' scope), the dependencies don't become transitively available. Given that "compile" scope is used on the items inside the BOMs, Maven's documentation of the dependency mechanism seems to indicate that those items should be added to the classpath of my project. Yet I'm getting undefined symbols for the classes that should be brought in.
For example, in project P, I'm including org.jboss.bom.wfk:jboss-javaee-6.0-with-spring:2.4.0-redhat-2 with 'provided' scope, yet org.springframework.context.ApplicationContext is undefined in P.
This is all happening in JBoss Dev Studio 8.1.0.GA, if that makes a difference.
I figured out the solution myself by reading the Maven Dependency documentation in more detail.
Here's my take-away: you cannot depend on the Eclipse m2e plugin to see you through the Maven dependency weeds. Know when/how to use the <dependencyManagement> section of the POM (and when not to use it). Know in particular the specific invocation Maven needs when you want to use a BOM: import the BOM in a <dependencyManagement> section with <type> of pom and <scope> of import, and then in the "regular" <dependencies> section (not <dependencyManagement>) specifically call out the sub-artifacts you need from the POM, but omit the version. (It's all spelled out here.)
The intent of the BOM is not to allow you to mass-import dependencies by referencing only the BOM artifact; rather, it's to make sure the versions of dependencies are the right ones, as defined by the BOM.
Do not assume that Maven allows you to express things in logically/mathematically reduced terms. Find out how to please the beast, and do not rely on a wizard to figure this out for you. Read the Maven docs in detail, find out the recipes and follow them exactly.
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.
I need some verification of how Maven works.
How important is it for us to specify the project dependencies explicitly (<dependencies>) in pom.xml? Some said that it's necessary only when we need a specific version of that jar, otherwise Maven will be able to find the jar in your local / Maven's remote repository. However, I find that sometimes I could not build or package a Maven project without specifying/declaring the dependencies.
So.. is the declaration really necessary?
If your code just uses "plain" Java and does not depend on any other libraries you do not need to declare any dependencies (because you do not depend on anything other than the Java runtime).
In most cases you will use some 3rd party libraries - thus you have to declare them as dependencies in your project to let maven construct a valid classpath which lets your build work (transitive dependencies will be resolved automatically - as already mentioned).
Regarding to the specific version of a jar have a look at the Project Dependencies section of the "Maven: The Complete Reference" book provided by Sonatype. You have several options to declare the version you need (including version ranges).
Do not expect that the declaration
<version>1.2.4</version>
will force Maven to use that version. That is only meant as "allow anything, but prefer 1.2.4". If you need to force maven to use a specific version and nothing else you have to use
<version>[1.2.4]</version>
Yes, the dependencies are needed. Most plugins use them to construct the necessary classpath, or to determine what to include in the artifact. Maven is declarative - you are declaring what you need, not how and where to find them locally.
You need not to declare Transitive dependencies of a JAR. Other than that, everything must be declared. Here is a good read on how maven mananges dependencies. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
You always need to specify the dependencies. Maven can't predict, which libraries you need. What you in most times don't need to specify, are additional Maven repositories. You need that only when you have libraries as dependencies, which are not contained in Maven Central.
What you also can eliminate in your projects, are the version numbers of your dependencies, if you have a parent POM, where the versions are specified.