This is my first time really playing around with Java development using Eclipse. I am trying to use EclipseLink's implementation of the JPA. I moved all of my entities into a separate package "entities". I have the persistence.xml in a separate JPA project called "dataModeling".
Everything builds and runs fine.
Just about every project depends on my entities. However, I'm seeing a warning Class javax.persistence.Entity not found - continuing with a stub., etc. showing up because the dependent projects don't reference EclipseLink.
The solution is to go into each dependent project's properties and under Java Build Path > Libraries, click Add Library, then User Library and then select EclipseLink.
However, to me, it doesn't make sense to reference EclipseLink in every project! That's an implementation detail I don't want to burden other projects with. It looks like this is happening because the other projects see the annotations and don't recognize them.
So the real question is: how can I use JPA (via annotations) without every other project needing to reference my JPA implementation?
Your pom.xml should contain:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.5.1</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.0.0</version>
<scope>compile</scope>
</dependency>
the first one is Eclipse-Link (which you already have), the second one is Persistence API which is lacking.
If you are not using maven - make sure that javax.persistence-2.0.0.jar is on your classpath.
Note that this is version 2.0.0, the newest is 2.1.0
update
The project which makes use of EntityManager should have these dependences. Putting entities and persistence.xml in separate jar file still requires the other project that uses it to fulfill above dependencies.
Thanks to #neil-stockton and #chris, I was able to figure out what was going on. Most JPA implementations have a copy of the javax.persistence JAR floating around somewhere. Most of them are bundled with everything else, leading to my dependency nightmare. There doesn't appear to be a de facto implementation floating around.
In my case, I used the copy that showed up under my Eclipse plugins directory. These annotations were truly empty in that did not have any unwanted dependencies. The JAR file (javax.persistence._<version>.jar) only showed up after I added the Dali and EclipseLink plugins (one or the other).
Related
I have a scenario as follows:
I am using maven as a build process. I am creating a web project in which I want to use a specific version of spring. This project also depends on a third party library which internally depends on different version of spring. I have a doubt that this will result two different versions of spring n class-path and unexpected behavior will be observed. I have few information which I wanted to get more clarification on.
Can I use maven BOM concept for this?
Can somebody explain with example how to achieve this?
Can somebody explain how do we make sure that third party wont behave abnormally if overall project depicts using a specific version using BOM?
If somebody can throw light on it and give a detailing reference, that would help me a lot.
Maven should know how to evict one or more of conflicting versions of an artifact.
However, you can influence that by simply excluding one of the transitively included dependency.
Example: the following code excludes the io.netty (transitive) dependency. In this way, you'd leave maven with the only other version as you decide/prefer.
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>${hbase.version}</version>
<!-- The exclusion below makes sure that this specific version imported by hbase does not end up deployed -->
<exclusions>
<exclusion>
<artifactId>netty</artifactId>
<groupId>io.netty</groupId>
</exclusion>
</exclusions>
</dependency>
Regarding runtime behavior, you have to test and decide for yourself (that is if you aren't lucky to have your direct artifact that documents versions of its own dependency)
You can use the concept of BOM but this won't avoid the conflicting issue of libraries by itself. It's very common that projects have one or more library which depends on the same other with different versions. In this case, when you want to force some specific library version for that third party library you must explicit it in your POM by using < exclusion > markups. This is not an easy task, once that projects usually have many libraries. So you need a tool to provide you an easy way to visualize a dependency hierarchy of your project libraries. There are some IDE plugins for this. Some versions of Eclipse, for example, have the maven plugin included in it, which provide a Dependency Hierarchy view ( a kind of dashborad of libraries and their dependencies ). Once you detected a library which should not using other library dependency ( wrong version for example ), you go at the this dependency in the pom and use the exclusion markup adjust the dependency version. Using the tool will make this task very simple.
I have just started to learn Spring using Maven. Can somebody clearly explain?
In your codebase, you will have a multitude of packages. Each of those packages will have a pom.xml file which have maven dependencies in there. Those are the dependencies that get pulled in when doing an 'mvn install' on that particular package. E.g. one of your packages which uses spring will probably have this :
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.1.4.RELEASE</version>
</dependency>
Further, your package will also depend on other packages, and so will have dependencies on those packages. Each package gets a .jar file of its own when built (which contains .class files). A certain package doesn't rely on all other packages in the codebase, so it just pulls in the ones needed. These packages can be published and pulled in from a locally hosted Artifactory, and in the case of spring it probably gets pulled in from an online maven repo.
The fetched artifacts (.jar files) get put into a hidden repository folder (mine's called .m2/repository) which you can configure in your IDE, and the fetching is done smartly. If it exists already, it won't do the effort to pull in a new one. If you however do want to override the currently fetched artifact, look at this question I asked when I was struggling to understand maven myself.
Notice the < version > tag. This tells maven the version to fetch, and if it sees that version already exists (I'm not sure how it checks, it probably looks at the folder name or some file inside like MANIFEST.MF) it doesn't bother fetching it. In case you have a dependency which has frequent updates, changing this version field all the time can be bothersome, you can make it such that it fetches the latest all the time.
Hope that helps.
Part of the project I've been working on requires serializing objects to JSON and passing them to the user. We will be using the Jackson library to do this. Previously I was using version 2.2.3, which was simple enough, but my manager wants to switch back to version 1.9.12. Shouldn't be a problem, 1.9.12 supports everything that we need, but just adding the dependency to the project causes it to basically implode.
The dependency we add:
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
<version>1.9.12</version>
</dependency>
The project builds just fine. However, running the server causes it to throw this:
java.lang.ClassNotFoundException: org.codehaus.jackson.JsonGenerationException
followed by about a page of information which I can provide if needed. Trying to load up a web page (which was working previously) causes it to generate a 5MB log file full of errors, and while the page itself loads some of the page entities come out wrong.
A quick check of the compiled .war file shows that the jackson-mapper-asl.jar doesn't contain JsonGenerationException.class, but jackson-core-asl.jar (which I believe is added as part of the jackson-mapper-asl dependency, as it is not listed in the dependencies) does.
I have commented out all of the code relying on Jackson, so the libraries are not used in any way in my code. My suspicion is that Spring is trying to create a JSON mapper for one of the servlets and is somehow crashing. However, I'm not sure why it can't find the dependency.
I think you should migrate towards "com.fasterxml.jackson.core" Jackson.
see packages on Maven cetral:
http://search.maven.org/#search|ga|1|com.fasterxml.jackson.core
It looks like Jackson project changed base package. I have Spring Boot (1.1.8) project in my workspace and it's using Jackson with this new base package.
I am planning to user Jackrabbit for developing an online document library.
To develop simple POCs, i have put the jackrabbit-standalone.jar inside my class path and everything works fine.
But on opening the jackrabbit-standalone.jar, i found out that it's a web project in itself.
I copied all the jars from jackrabbit-standalone.jar/WEB-INF/lib and kept in my class path and my project again works fine.
My concern here is that I don't want to keep any extra jars in my project. So my question is :
What are the minimal jars which are required to interact with
Jackrabbit repository?
What is the best way of using jackrabbit in a web project, as per enterprise standards. Is it using standalone jar in the class path or using only the required jars?
I won't ask why you want cut out unnecessary jars for a POC.
Do you use maven? If so, you just add jackrabbit-core and it will pull down dependencies.
If you require the JCR API you'll also need jackrabbit-spi2jcr.
Otherwise, this is what we end up with (version 2.6.4):
commons-collections-3.2.1.jar
commons-dbcp-1.3.jar
commons-pool-1.5.4.jar
concurrent-1.3.4.jar
jackrabbit-api-2.6.4.jar
jackrabbit-core-2.6.4.jar
jackrabbit-jcr-commons-2.6.4.jar
jackrabbit-spi-2.6.4.jar
jackrabbit-spi-commons-2.6.4.jar
jackrabbit-spi2jcr-2.6.4.jar
jcl-over-slf4j-1.6.4.jar
jcr-2.0.jar
log4j-1.2.16.jar
lucene-core-3.6.0.jar
slf4j-api-1.6.4.jar
slf4j-log4j12-1.6.4.jar
tika-core-1.3.jar
You can dispense with the logging jars if not needed. Not sure if you can get rid of lucene-core as I believe it's used internally.
Regarding how to use jackrabbit, that's entirely up to you. You can use it as standalone server or, like us, as your persistence layer. We use the JCR api.
you can use maven or gradle to manage dependencies for you.
If you are using maven, you can find out the dependency tree with command :
mvn dependency:tree
and review the relations between artifacts.
And you can exclude parts you don't want with exclude expressions:
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
I have a requirement where i have two develop two projects, one with EJB2.1 and one with EJB3.x.
The EJB2.1 will be an extension to an existing project hence the reason it is v2.1 and cannot be migrated to 3.x just yet.
Both projects have to be built using Maven and this is where i am struggling. Believe it or not, i have spent the last 3 days trying to find a simple example of a stateless EJB project built using Maven but have had no luck.
Here are a couple of pointers i found through googling but none of them work.
Create project using Eclipse
Eclipse allows you to create an EJB3 project. Latest versions dont allow you to create EJB2 projects. Also, you cant create a Maven EJB project.
Use the maven archetypes.
I have tried the following archetypes in Maven but none of them work
ejb2-j2ee13
ejb2-j2ee14
ejb-javaee6
ejb-jee5
ear-jee5
ejb-jee5
The above archetypes are only for EJB3 or for those that are for v2.x there will be some dependencies missing.
Jboss sample projects
I also found the following tutorials on the Jboss documentation http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/docs/tutorial/reference21_30/. I intend to use the EJBs on Jboss v5.1. The projects on this URL are Maven projects but they also complain about missing dependencies (The ant build does work).
If anyone can point me to where i can download a vanilla "Hello world" maven project for both EJB2.x and EJB3.x (That would run on Jboss 5.1.x) i would really appreciate it.
I have spent so much time on google and have finally decided to ask here as i am not getting anywhere. I suspect that maybe they are making it difficult to find these dependencies as they dont want people to use EJB2.x anymore. The problem is some people have no other option.
you really dont need the archetype for Java EE5, or JEE6 there is so little boilerplate code, that all you need is a regular java archetype and add the dependency for
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
or
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>5.0</version>
<scope>provided</scope>
</dependency>
add your beans.xml and you are done. Avoiding any JBoss depdencies is actually a good practice, as this ensures your application remains portable.
Note: If you want to mock or use any classes from the respective javax.XXX packages, you will need to include your application server specific dependencies into your maven test scope. This is because Sun/Oracle altered the bytecode of the API jars, to guarantee nobody accidently uses these classes, instead of the ones provided by the server.