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.
Related
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 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.
Concerning the pom.xml Maven file:
Is there any specific rule to apply to the ordering of declared sections?
Does it have any importance or impact on the build?
Shall I follow any official convention?
Although in most of the cases it is irrevant whether one section is declared before another, readeabilty could be indeed impacted when choosing a weird layout (e.g. Maven coordinates at the end).
But that's not the most important point, because yes, ordering of certain elements can impact your build.
Order of plugin declarations
The order of plugin sections wihtin the build/plugins section may be important. Since Maven 3.0.3 (MNG-2258), different plugin executions attached to the same Maven phase will be invoked in their order of declaration in the pom.xml file, after any execution attached via default bindings. That is, ordering is important in this case, since it may affect the behavior of the build.
Order of dependency declarations
Additionally, also order of dependency declarations within the dependencies section may affect your build towards Dependency Mediation, that is, the first declared dependency wins in case of conflict against a transitive dependency. So, once again, ordering is important in certain cases.
Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
As a rule of thump: declare first the dependencies you directly reference in your code (that is, as import statements).
Order of module declaration
Although not relevant in most of the case, because (the) other important rules applies before, Maven will also respect the order of declaration of module element within the modules section during a multi-module build as last decision point. The reactor mechanism will in fact:
The following relationships are honoured when sorting projects:
a project dependency on another module in the build
a plugin declaration where the plugin is another modules in the build
a plugin dependency on another module in the build
a build extension declaration on another module in the build
the order declared in the element (if no other rule applies)
Note: bold added here.
Standard layout
Last but not least, although ordering is not important for other sections of the pom.xml file, good habit is to follow the official Maven recommendations:
The team has voted during the end of June 2008 to follow a specific POM convention to ordering POM elements.
As a simplified version, follow this order of declaration:
<project>
<modelVersion/>
<parent/>
<groupId/>
<artifactId/>
<version/>
<packaging/>
<properties/>
<dependencyManagement/>
<dependencies/>
<build/>
<reporting/>
<profiles/>
</project>
As a final note, the sortpom-maven-plugin can also be used to automatically apply this standard ordering, simply invoking the following on the concerned pom.xml file:
mvn com.github.ekryd.sortpom:sortpom-maven-plugin:2.5.0:sort \
-Dsort.keepBlankLines -Dsort.predefinedSortOrder=recommended_2008_06
Also note, the exceptions above are not handled, but documented by the plugin as special cases where indeed ordering may affect your build.
For further reading:
Official Maven doc: Plugin Bindings
Official Maven doc: Dependency Mediation
Official Maven doc: Maven Code Style And Code Conventions
i have a maven multi-module project:
root
commons
common-module
plugins
plugin
commons and plugins don't have the same parent, and are "standalone".
in commons-module i define 2 profiles, projectA and projectB. in each of these profiles i define properties, such as dep.version, dep1.version etc...
later i use these properties in dependencyManagemnt for the version part in the dependencies of "dep" and "dep1" section.
in plugins (who is parent for plugin) i have a dependency scope import on commons-module to obtain the list of dependencies.
when i build the plugin module, it doesn't seem to matter if i do -PprojectA or -PprojectB: maven says they don't exist. they do exist, but in commons module, which i import.
so the dependencies i get don't have the correct versions when i mvn dependency:tree
is what i'm trying to achieve possible, am i don't something wrong, is this a maven bug, or a none-supported feature? anyone got a clue?
thanks,
Nathan.
Import scope only imports the dependencyManagement, not the dependencies themselves. You still need to declare the dependency on the artifact, and then the version, and scope etc will be picked up from the dependencyManagement.
I don't think import will work for pluginManagment sections. The documentation you linked to only mentions dependencyManagement, and the only other mention I've seen is this unanswered question to the mailing list.
Dependencies aren't allowed to change the POM of modules that simply use those dependencies. It wouldn't be a safe thing to do. Imagine that you're adding another dependency to your project, and suddenly the build stops working because the dependency actually overrides some of your settings.
POM interpolation inherits settings only from ancestor projects, going up the <parent> chain.
You are trying to use the import scope with profiles. However, profiles are not activated transitively, so the different dependencies in your import-scoped dependency's POM aren't being activated.
It's probably not recommended, but you could have two different commons modules, and include the import-scoped dependency in profiles that refer to one or the other in your current project.
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.