I haven't yet found an answer to this question which is bugging me for long. I am trying to integrate Hibernate (3.6.7) with Spring (1.2.8). In order to do so i have to get a bunch of jars just to get it running. Isn't there a more cleaner of way of getting this done. The jars i am using rather forced to use are as below:
spring-1.2.8.jar
commons-logging-1.0.4.jar
hibernate-3.6.7.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
dom4j-1.6.1.jar
slf4j-api-1.6.1.jar
javassist-3.12.0.GA.jar
Is there no leaner way? The big list of dependent jars could potentially cause conflict during deployment to my appserver in the future. So its making me rethink about spring-hibernate integration. Is there a way to reduce this dependency list. My issue is not related to management of jars as maven is already being used, it more to do with the usage.
This answer was posted before the OP mentioned that he was using Maven. The question seems to be asking how he can use code without including it in his project. Given that there is no answer to that question I'll answer assuming he wants a better way of managing the dependencies that he needs.
The leaner way to do this is to use a dependency management tool such as maven. This allows you to define your project's dependencies in an xml file.
The dependencies you specify will also have dependencies and so on. These are transient dependencies and are very hard to manage without an automated tool.
This is also the best way to ensure that you only have the jars you require.
The dependencies you require are:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.1.RELEASE</version>
</dependency>
and:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.6.10.Final</version>
</dependency>
Related
I found two way of adding dependencies for spring boot rest service application.
Method 1 :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</dependency>
Method 2:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
Both method given above does the same job? Any difference in performance?
Thanks in advance
The difference between these methods is that spring-boot-starter-web contains more dependencies than just spring-boot-starter and spring-web.
For the version 1.5.8.RELEASE it will be:
spring-boot-starter
spring-boot-starter-tomcat
hibernate-validator
jackson-databind
spring-web
spring-webmvc
All other stuff depends on your requirements. For instance, if you're developing commercial product you must check all included transitive dependencies for their licenses.
The general advice is to use only features you need. Don't forget that you still can depend on top level artifact excluding not required parts using Maven feature.
At for the performance boost, basically it should not be that much. The difference is only if the Spring (with top-level artifact dependency) will load and auto configure some features which are not practically used in your code (during the classpath scanning). The startup time could be slightly increased by the same reason.
Hope it helps!
Obviously second approach is better i.e. using springboot starter pom.
Reasons I say that for are as follows:-
It allows zero configuration or auto configuration i.e. most of the web related settings would be given to you by default. e.g. by default tomcat server would be integrated, springboot dependencies would be added for you, automatic registration of converter and other web related dependencies etc. See this link.
You could take advantage of easy override i.e. if tomorrow you want to use jetty in place of tomcat just add the jetty dependency and it's configurations and now you could use jetty.
Your pom.xml would be neater and more readable as less no. of dependencies are put inside it and picked from starter poms.
Easy compatibility management. By default spring-boot picks up the version of starter parent. Hence, you could rest assured that all compatible dependencies would be downloaded as part of mvn dependencies and if you specifically want to upgrade any of those you could. But this gives advantage of upgrading to compatible dependencies by just changing the version of springboot starter parent(Note: You could use dependency management as well in place of starter parent pom. See this link).
Performance wise there would be a trade-off as springboot by default downloads more dependencies than minimum required initially. But over the time as application starts becoming mature most of these dependencies are used anyways.
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 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'm fairly new to the Eclipse and Maven2 worlds. I'm struggling to comprehend how to add a Maven project dependency on Apache Jena in a simple way. Specifically, I'd like to add a dependency such as
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena</artifactId>
<version>${jena.version}</version>
</dependency>
And this would automatically pull in the modules(eg. jena-arq, jena-core, etc). However, adding this dependency results in a Missing artifact org.apache.jena:jena:jar:2.11.1 error. If I add <type>pom</type> to the dependency the error is gone but I do not get the jars in my project.
In any event, as I understand it, POM is more suited to project <--modules dependencies and what I'm really looking for is project --> lib archive dependencies.
How do I establish such a relationship? I considered simply replicating the dependency for each module in Jena since it's using a property anyway. However, it is possible, and Jena is a prime example, that not all modules in a project share the same version. For example jena-core is on 2.11.1 where jena-tdb is on 1.0.1 however jena-2.11.1 encompasses jena-tdb.
Thanks
See http://jena.apache.org/download/maven.html for details.
In brief:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId>
<type>pom</type>
<version>2.11.1</version> <!-- Set version -->
</dependency>
Note that it is type pom.
there is not a easy way do this.
you must define every dependency jar with special version.
I am using Spring 3 and Hibernate 4 JPA. I am confused regarding javax.persistence JAR. I found below two Maven dependencies on Google. Please tell me which one is required in below two dependencies?
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0.2</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.0.0</version>
</dependency>
The first of those javax.persistence.persistence-api is the API Jar, which defines vendor-neutral interfaces which your application should be working with.
The second is the EclipseLink implementation of that API.
It is possible to remove references to the first javax.persistence dependency and just use the EclipseLink jar. However there is a good reason not to.
Writing and compiling your code against the vendor-neutral javax.persistence API ensures that your application code is portable to different persistence providers. For instance if you wished to switch to Hibernate, then you could put that in your pom.xml and remove the org.eclipse dependency, without changing any of your application code.
However, there's an extra little detail you should change. To ensure that your application can switch between persistence providers, the 'implementation' dependency should only be used at runtime. Otherwise, vendor-specific code could easily make its way into your codebase. Add the following to your org.eclipse dependency and see whether your application compiles.
<scope>runtime</scope>
As a result of that, you may find that your application has EclipseLink-specific code in it. This means that you could not change persistence provider without changing your codebase.
Whether that's a problem is up to you. ;)
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.0.0</version>
</dependency>
Which is the lastest one and compact with hibernate 4. Also latest version of hibernate support jpa 2.1.0 please check this link
You dont need to include that dependency explicitly, it is in Hibernate pom and will be added transitively