I'm having the two dependencies javaee-api and hibernate-entitymanager in my pom. But they don't work very well together: as soon as I add javaee-api, all my unit tests break due to java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/validation/Validation. Without javaee-api, everything works fine. Why is that?
(this question has been edited in order to fit the problem ;))
Maven Dependencies have no order , but the provide the concept of scopes.
So what you need to do is, use the scopes to build the right set of dependencies for:
compile time
runtime in the server: (use for example provided for dependencies that are needed at compiletime, but will be provided by the server, so your Application does/must not contain them
test time: use the test scope to add dependencies that are only needed for testing (junit for example)
In your special case it looks like that javax.validation interface libary is not aviable in the tests. May they are not incuded in javaee-api. If this is the case, then add:
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.0.0.GA</version>
<scope>test</scope>
</dependency>
But be careful, your explanation, about what is included in the server, and the described behaviour sounds strange to me. - I recommend to double check what the server provides and what javaee-api relay includes. But may I am wrong, and javax.validation is only needed for test explicit
The reason why the problem only occoures when javaee-api is included, could be, that javax validation sometimes is only turned on, when a implementation is aviable in the classpath.
The order of dependency matter in some cases. The "problem" is that if a libary/dependency is referenced in two places (direct and inderect) and the version of both references to the same library differers, Maven has to decide which version to use.
The first and most important criterium is the depth of the reference in the dependency tree. If you reference the library directly in your project POM, then this will be dominate all other. If the library is refered directly by a libary that is refered direcly by you, then this will dominate all other where is one more indirection.
But in case where are two references (to the same library in different versions) in the same depth of the dependency tree, the first one will win. (more details).
First of all,
This is caused by the fact that the java-ee-api.jar contains crippled classes. There are alternative dependencies around which fix this problem. Changing the order in the pom.xml did the trick for me, too.
As far as I know, in Maven2 the order of the dependency is not kept and there is no guarantee on the order of how those dependencies appear in the final class path when you execute your code. In your case, I would "exclude" overlapping libraries in your dependency structure.
Look here for the Maven exclusion docs.
Given the complexity of library version matching I would suggest you start off with one of the Hibernate Maven examples, and morph it into your project.
I hope this helps.
Related
My pom.xml has this dependency:
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
</dependency>
When I use the XMLSerializer it throws an exception: java.lang.NoClassDefFoundError: nu/xom/Node
If I run the class locally and add the JAR to my classpath, everything works as expected. I'm running this class as a Jenkins plugin so I don't expect to be manually defining classpath - I figured that's what Maven should be handling.
It's important to note that Jenkins plugins require me uploading an hpi file that is created from Maven. It is not running based on the output jar. If I go on Jenkins box and manually put the xom JAR into WEB-INF/libs, it works. But obviously that means this plugin wouldn't for other people, which is self-defeating.
Here is minimal code causing error: https://github.com/DaveStein/parser-sample
The Readme has exact repro steps.
Note on chosen answer
The PR to my sample repo got me most of the way to where I needed to be. I did have a few other issues that had to get resolved, but the JSONObject conflict was the core problem. I took out all GlobalConfiguration as Jesse's PR suggested. The only other issue that might concern a future viewer was some glitch when using xom as explicit dependency while also using a higher version than 1.626 for org.jenkins-ci.plugins at the time of this post.
Jenkins core bundles json-lib. (A forked copy, not that it matters for purposes of this question.) It does not bundle the optional dependency¹ XOM, whatever that is. When your plugin loads XmlSerializer.class, it gets defined by the class loader for Jenkins core, which then attempts to link against classes such as nu.xom.Node. Since this is not available in the defining loader of XmlSerializer—the Jenkins core class loader (more or less jenkins.war!/WEB-INF/lib/*.jar)—you get an error. The fact that a class by that name is accessible in your plugin class loader is of no import, excuse the pun.
If your plugin needs to use its own versions of classes which are normally bundled in Jenkins core and exposed to plugins implicitly, then it needs to not only bundle those JARs (a regular compile-scoped Maven dependency suffices for that purpose), but to also use the pluginFirstClassLoader option. Before attempting to do so, you had better understand Java class loading semantics thoroughly, or you will be lost in a maze of cryptic² ClassCastExceptions and LinkageErrors.
By the way the mvn hpi:run command normally used to test plugin code iteratively does not simulate a realistic class loading regime. So if you are using pluginFirstClassLoader or any other tricks in this space, always double-check the resulting class loading behavior by (re-)installing an *.hpi in a sample Jenkins instance, for example using /pluginManager/advanced, or the install-plugin CLI command. Judging by your description, you were already doing that (and perhaps unaware of hpi:run).
¹The original sin here is use of optional dependencies. json-lib should rather have defined a distinct artifact json-lib-xom with hard dependencies on json-lib and xom. That would ensure that any given class loader can either see XmlSerializer and its dependencies, or neither.
²No progress on JDK-6273389, alas. Marked as a duplicate, but what it is a duplicate of, I am not sure. Theoretically Java 9 modules make questions like this obsolete—by imposing such onerous restrictions that applications like Jenkins could not use that module system to begin with.
please google "noclassdeffounderror vs class not found" , this error means the class dependency is in fact found but is not available in run time.
Try these steps:
Run mvn clean package and mvn clean install
Check if your maven environment is correct and has latest jars
Check if the installed target project contains the required jars
Check if dependency type is selected as runtime and not only as
compile time in pom.xml
Here is an example of using runtime dependency:
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
My guess is that the local version of the XOM jar is not the same as the one that is used in your Maven version. To verify use the dependency:list Maven command to list out all your dependencies. Verify if the XOM dependency listed is the same version as the local jar.
Probably error on jenkins occurred while this dependency has been loaded for the first time and now it's considered as complete. Try to remove dependency from jenkins' maven local repository and re-run. That might help you
We have a case in our dependency tree where we have two version of the same jar coming in from different sources, the version we want to use is lower in the tree, so maven is picking the other version using the nearest wins method.
To resolve this, We could either exclude this incorrect version from its source dependency, or directly add that version as another dependency in our pom.
I preferred the latter since it is quicker. But I am not sure if that is the best way of doing it, or are their any drawbacks of adding a dependency. So, is adding an exclusion better than what I did? In what cases and how?
I would suggest to explicitly define your dependency in order to make it clear which version you are expecting through transitive dependencies.
Although you would normally declare only dependencies directly referenced by your code (i.e. you use import statements in Java to include classes from these dependencies), it is also recommended to have control over your dependencies resolution via explicit declaration. Explicit declaration will have priority over Maven dependencies mediation.
Exclusions make your build harder to maintain and potentially you would need to replicate the same exclusion over and over if, for instance, the same dependency would be required transitively via other dependencies and every time with a different version (not the one you want). Moreover, exclusions can have undesired effects as it may take precedence when it is not expected.
Declaring it as part of your dependencies makes it clear, centralized and easier to update/maintain in the future.
Update: An even better approach is to use the dependenciesManagement section, which also takes priority over Maven dependencies mediation, as stated in the official documentation, here
dependency management takes precedence over dependency mediation for transitive dependencies
What is the best way to declare a Maven dependency as only being used for the test runtime (but not test compilation) class path?
Specifically, I want slf4j-api (a logging facade) as a typical, compile-scope dependency, but I want slf4j-simple (the barebones implementation suitable for unit tests) only on the test runtime class path (it's not needed for test compilation). I've been doing this:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<scope>test</scope>
</dependency>
However, the downside of this is that dependency:analyze reports slf4j-simple as unused, presumably because it's not needed for compilation:
[WARNING] Unused declared dependencies found:
[WARNING] org.slf4j:slf4j-simple:jar:1.7.7:test
I can't use a runtime dependency because I don't want that dependency transitively inherited (e.g. so downstream dependencies can use log4j, etc. instead). I tried runtime with optional=true, but that results in the same warning.
(Note that I could also set ignoreNonCompile for the dependency plugin, but that seems like a very blunt instrument that would hide other potential problems.)
There is no scope that does exactly what you want here; test is the best available option.
A test-runtime scope has been requested before (Re: Need for a test-runtime scope?) and the suggested workaround is exactly the ignoreNonCompile configuration you've already discovered.
dependency:analyze already has some limitations ("some cases are not detected (constants, annotations with source-only retention, links in javadoc)"). You may have to accept that any test-scope dependencies that it warns against are false positives.
(You could split the definition of your tests into a separate module, which would have no slf4j implementation dependencies, then run them in another module. I don't think that would be worth it.)
There is no concept of test-runtime in maven. The only real downside is the dependency analysis identifying these runtime test dependencies as unused. Since they are only test dependencies, however, this is pretty benign and cannot cause issues to other projects transitively dependent on this project.
Since maven-dependency-plugin 2.10 (revision 1649454, Jan 2015), you can also add to the configuration a list of ignoredDependencies, ignoredUnusedDeclaredDependencies and ignoredUsedUndeclaredDependencies.
As a workaround i would suggest to have separate maven project with test cases that depend on main project
I just produced my first parent-module project with maven, and successfully installed it. Can I add this project as a dependency in another project, only by referring to the parent? My Eclipse IDE complains that it can't find the parent.jar, but that is not a surprise, as it is packaged as parent.pom.
Question:
So is it possible to add a parent (.pom) dependency, and get all transitive dependencies for free, or do I have to add .jar's.
Bonus Question:
Is it possible to add dependencies to other packaging formats as well, like a war? I can't really figure out how that would work, or why I would need that at this point though. Just curious.
Disclaimer:
I'm still learning maven, and find the philosophy and theory of it to be great. However, there are so many pits and reefs that seems to pop out, and more than once, I struggle to see if I'm trying to do something impossible, or if there is another mistake in configurations I.E. Right now Eclipse says it can't find any of my .m2 referenced dependencies in this one particular project. I have no idea why, as other projects works fine. I am in other words trying to find the error, by checking one area at the time...
Answer: Yes, you can add different types such as pom, test-jar and so on. Jar is just the default
Bonus Answer: Yes, you can specify type war as well
The Maven-Guide defines the following types: "The current core packaging values are: pom, jar, maven-plugin, ejb, war, ear, rar, par."
Here is a example on how a POM is included:
<dependencies>
<dependency>
<groupId>com.my</groupId>
<artifactId>comm-group</artifactId>
<type>pom</type>
</dependency>
</dependencies>
This (the pom of comm-group) is oftenly used to group certain dependencies and include all of them using the type-pom.
Here is additional information on grouping: http://blog.sonatype.com/2009/10/maven-tips-and-tricks-grouping-dependencies/#.VFC7LR_JY8c Note that there are similar behaviours you could create using polymorphism.
I had my issues with maven when we migrated from Ant and i still have certain concernes on it (like were is the advantage of maven if 80% of our SWEs apply wrong scopes, types and so on leading to a massive drawback if they just 'need to add a fcking jar' as well as to refactorings lead by "maven gurus").
BUT: I can guarantee you that if you go throught http://maven.apache.org/pom.html completely you will aquire statisfieing results compared to ANT over time.
Update: I just ran into the case where my pom could not be included on the remote build server while it worked building it from inside Intellij Idea/ Eclipse. Type definition in my case had to be lowercase (e.g. 'pom' instead of 'POM').
I have lately become a big fan of Maven for controlling the build cycle for my application. However I've encountered some rough edges with Maven's dependency management. I'm wondering if these are limitations of the tool and paradigm, necessary evils of dependancy management, or if I"m just using the tool incorrectly.
First is the matter of transitive dependencies. As I understand it, if you provide a dependency, Maven will in turn find any dependencies of that dependency. That is great, but for many of my dependencies, this has not worked. For example, including Hibernate in my project:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.3.2.GA</version>
</dependency>
Results in a missing dependency of slf4j. I need to manually add this dependency which I assumed would be Maven's job. The same goes for Spring. If I add Spring-MVC as a dependency, shouldn't all of the basic servlet dependencies be added for me (because Spring-MVC would need this stuff)? I'm referring to the servlet, jsp, jstl libraries.
Second is the management of repositories. Maven comes shipped with a default main repository, but I've found that in many cases this repository is not up to date. For example, ifyou want spring3, you have to manually add the springsource repository, and if you want hibernate 3.5+ you have to add the jboss repository. It seems to defeat the point of automatic dependency management when you have to hunt down the correct repositories yourself. This hunting soon gets complicated. For example to add Spring3, you may want the spring release repo, the spring externals repo and the spring milestone repo.
Closely related to number 2 is ensuring you have the correct version of an artifact. I have been burned several times by including the wrong versions of dependent artifacts for a given artifact. For example the wrong version of the servlet/jsp/jstl apis for spring3, or the wrong version of persistence / annotation apis for hibernate. The repositories are filled with many versions, some with confusing names like productx-3.ga, productx-3-rc1, productx-3-SNAPSHOT, productx-3-cr, product-3-beta, etc. Some of these are obvious (rc= release candidate), but it can be confusing trying to determine the order of these versions.
Finally, the issue of the type a dependency. I probably just don't understand this well enough, but many repo artifacts are of type "pom" not "jar". Several times i have added a dependency jar to my project only to find out at build time that the repo jar does not actually exist (example is org.hibernate ejb3-persistence in the jboss repo).
With some experimenting, I can usually get a build to work, but is dependency management in general this complicated? I still prefer this approach to manually adding jar files to my project, but I would be interested to learn how to improve my maven dependency management skills.
Can't answer all parts of the question, but about some of them:
Some transitive dependecies are marked optional, so people who don't need these features wouldn't download them, but people, who need, have to set them explicitly in their poms.
Maven Central repository contains only releases. Therefore, it doesn't contain Hibernate 3.5 (which is beta) as well as it hadn't contained Spring 3 until it was released (by the way, you don't need to specify special Spring repository for Spring 3 any more - release is already in Maven Central)
slf4j is a very special kind of dependency - its runtime behavior depends on which implementation of slf4j you use. Therefore, to control its behavior you have to specify slf4j implementation explicitly
About management skills: to get useful information for maintaining your pom.xml you can use mvn dependency:tree (especially with -Dverbose=true) and mvn dependency:analyze. It can be also useful to check pom file of your dependency to look for optional dependencies.
First is the matter of transitive dependencies. As I understand it, if you provide a dependency, Maven will in turn find any dependencies of that dependency. That is great, but for many of my dependencies, this has not worked. (...)
As already pointed out, some dependencies may be marked as optional (and are not pulled transitively). The idea is that some dependencies are only used for certain features and will not be needed if that feature isn't used. If a user wants to use functionality related to an optional dependency, they will have to redeclare that optional dependency in their own project. So this just works as designed :)
Second is the management of repositories. Maven comes shipped with a default main repository, but I've found that in many cases this repository is not up to date. (...)
Even if the idea behind the concept of a central repo is noble, you can't objectively expect it to contain all jars in the world. One of the most obvious reason is that uploading artifacts to the Central Repository just takes time and resources are not infinite. And because companies like RedHat JBoss or SpringSource or Sun or even me need flexibility, reactivity (in one word, control), it's not surprising that they use their own repository. And, actually, I'm pretty happy that they expose them. But indeed, projects need to document where to find their artifacts if they are not available in central. Just in case, you may find this How to find dependencies on public Maven repositories? helpful. In a corporate environment, the best way to handle this would be to setup a centralized (corporate) proxying repository. See this page for such solutions.
Closely related to number 2 is ensuring you have the correct version of an artifact. (...)
Sorry but you need a bit to know what you're are doing. A project can't guess for you what JSTL version you are going to use. Then, regarding the various versions of artifacts, the naming convention used by projects has nothing to do with maven, this is a project/vendor choice (except for SNAPSHOT that maven handles specially). FWIW, common used schemes include: M1 = Milestone 1, RC1 = Release Candidate 1, GA = General Availability (final release), CR = Customer Release (often a bug-fix release). You may also see alpha, beta. This really depends on the project lifecycle and convention (nothing really unusual here though).
Finally, the issue of the type a dependency. I probably just don't understand this well enough, but many repo artifacts are of type "pom" not "jar". (...)
I think that you're indeed lacking of experience. You seem to be fighting with dependencies while things just go smoothly for me :) Maybe using a repository search engine will help.
You can also exclude some transitive dependencies, like the following example:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
<exclusions>
<exclusion>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
</exclusion>
<exclusion>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.jdmk</groupId>
<artifactId>jmxtools</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.jmx</groupId>
<artifactId>jmxri</artifactId>
</exclusion>
</exclusions>
</dependency>
I don't remember the details, but apparently some other dependencies were being discovered when we wanted to use log4j, and we had no interest (or need) in them in our case, so my cow orker just said "no thanks to these" and it works.
Transitive dependencies are only there if they have been encoded explicitly in your direct dependencies' POM's. Sometimes you actually do not want them, either because there are alternative implementations or you're using only part of a library and you don't want to drag in dependencies for things you're actually not using.
You are using a repository manager such as Nexus, aren't you? I advise you to setup one even if you code alone.
I find that Maven actually helps with this problem. I would hate having to perform this trial-and-error from ftp sites and download pages.
Yes, I hate that too :-)
Read the book! I actually learned most of what I know from this other book, but given it comes from the same people, I expect them to be rather interchangeable.