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>
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.
In NetBeans 8, in a Maven-based project, how does one use a jar while programming but omit from build?
I need to access some specific classes in a specific JDBC driver in my Vaadin web app. But in web apps, we normally do not bundle JDBC drivers within our build (the .war file). Instead, the JDBC drivers belong in a folder controlled by the Servlet container (the runtime environment).
So, I need the JDBC driver (a jar file) to be on the classpath while I am editing my code and compiling. But that jar file must be omitted from the build.
exclusions Tag
I tried adding the exclusions and exclusion tags to my dependency element. But this did not work – The postgresql-9.4-1201.jdbc41.jar appeared in WEB-INF/lib folder.
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>9.4-1201-jdbc41</version>
<exclusions>
<exclusion>
<groupId>org.postgresql</groupId> Exclude from build
<artifactId>postgresql</artifactId>
</exclusion>
</exclusions>
</dependency>
New Profile?
This Answer by ZNK - M on the Question, Setting custom runtime classpath for a maven project in netbeans, may be what I need.
But creating a new project profile seems like overkill what seems like small little task to me. And, I always want to exclude this jar from my build output, not just when testing or in other limited scenarios.
You should add a new profile run-with-netbeans in your pom that declares the additional dependencies (use the provided scope to not include them in the release).
Then you'll have to add the new profile to your IDE to run the pom with the -P run-with-netbeans option in the command line.
But I am familiar only with the basics of editing a POM file. If that approach is the way to go, it would be helpful if someone could expand on the details and steps needed.
<scope>provided</scope>
Use <scope> tag in POM file, with a value of provided.
Excerpt from the Dependency Scope section of the page, Introduction to the Dependency Mechanism :
compileThis is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
providedThis is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
runtime[…]
test[…]
system[…]
import[…]
Like this:
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>9.4-1201-jdbc41</version>
<scope>provided</scope>
</dependency>
Use the provided scope instead of the default compile scope for this dependency. That's exactly what it's for.
<dependency>
<scope>provided</scope>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
</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 want to use Log4J into my application. I have a limited resources and I want to use just the basic part of Log4J. Can you tell which package I need to use just for basic logging.
P.S In order to use just basic Log4J which packages I can remove?
You need the first two, and if it's Maven-based build then only the second, Log4j Core and the first will be added as a transitive dependency.
You could also use this entry in pom.xml if you're using Maven or similar:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.0-beta9</version>
</dependency>
Agree with Andrey, you need the core and the api jars. Note that the OSGi stuff is still a work in progress. About wich packages could be removed from the core jar: I see you also posted your question to the log4j mailing list. I'll answer there so that the whole log4j team can chip in.
Be aware though the the core jar contains config files in addition to .class files. If you rebuild a jar with a custom subset you must include those config files or the api will not recognize your jar as an implementation.
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>