All:
I try to build app using Apache Tika to parse PDF, but I wonder where can I get those libraries like tika-core/target/tika-core-.jar and tika-parsers/target/tika-parsers-.jar
I only find tika-app but there is no such jar like above.
http://tika.apache.org/1.11/gettingstarted.html
Apache Tika has a large number of dependencies it needs to run. Without those present, it will do very little!
You therefore need do use a dependency management tool to not only get Apache Tika, but also the other libraries it needs. If you're using Apache Maven to do that, you can follow the instructions on the Tika website to add it as a dependency to your project with a section in your pom like:
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.11</version>
</dependency>
The Apache Tika quickstart page also lists instructions on adding a dependency to Tika, along with all required dependencies, for both Gradle and Ivy builds too. You really ought to be using one of Maven, Gradle or Ivy to be handling the dependencies for you
If you really do want to handle all the dependencies yourself, you can find the Tika Core and Tika Parsers binary jars on Maven central, in the usual place. For Tika 1.11, that's here for the tika-core jar and here for the tika-parsers jar. But, as previously mentioned, you almost certainly don't want to be doing that by hand!
Related
How to use RatingStars Vaadin addon?
I want to use RatingStars addon on all our vaadin pages so that we can get quick feedback from user.
Is there any example available which shows how to use that?
Using widgets with Vaadin (with or without Maven) usually means you have to do 3 things before starting your application:
adding the widget dependency to your classpath
compiling the widgetst
specifying your widgetset
From your description you've already done the first but you had some trouble, so let's take them separately and since you're already using Maven we'll just continue down this road:
1: Adding widgets
I used dependency in project but maven couldn't find this jar so it's failing
<dependency>
<groupId>org.vaadin.addons</groupId>
<artifactId>ratingstars</artifactId>
<version>2.1</version>
</dependency>
Some of the widgets, also known as add-ons, may not be available in the central maven repo, so make sure you add the Vaadin dedicated repo in your POM:
<repositories>
<repository>
<id>vaadin-addons</id>
<url>http://maven.vaadin.com/vaadin-addons</url>
</repository>
...
</repositories>
Now it should resolve and download your dependency, adding it to the classpath.
2: Compiling the widgetset
Then I manually downloaded that jar, unzipped it and kept that my source location. But it's still failing for
Failed to execute goal com.vaadin:vaadin-maven-plugin:7.6.1:compile (default) on project vaadin-widgetset: GWT Module org.vaadin.teemu.ratingstars.RatingStars not found in project sources or resources
Now, before you can run your app, you also need to compile the widgetset. If you've generated your project skeleton using the vaadin-archetype-application everything should be already configured and you simply need to run mvn package (or mvn vaadin:compile for just the compilation process).
Otherwise take a look at this sample project for a standard vaadin-maven-plugin configuration.
P.S. Depending on you IDE, you can also use dedicated IDE plugins for these tasks, but that's up to you.
3: Specifying the widgetset
Finally, depending on your servlet version and app setup you can define your widgetset location by:
using the web.xml file:
<init-param>
<description>Application widgetset</description>
<param-name>widgetset</param-name>
<param-value>com.example.MyWidgetSet</param-value>
</init-param>
annotating your UI with #Widgetset("com.example.MyWidgetSet")
Now you should be able to run your application and see the widget on your screen :-)
I'm trying to re-write our build to Gradle, but we want to keep the dependency management in Ivy, for internal reasons.
So while trying to do that, I'm having several questions regarding the way gradle handles its dependencies:
When does gradle resolve dependencies (without Ivy or anything)?
When adding IvySettings and ivy.xml, do I need to call something similar to ant's ivy:resolve or ivy:configure, or does Gradle take care of that? If so, when and how?
Gradle resolves dependencies (more precisely configurations) on first use (typically by a task). Gradle doesn't read ivysettings or ivy.xml. (It does read ivy.xml files in the repository.) All information about dependency resolution is configured in Gradle build script(s).
In regards to (2), I managed to get gradle to read an ivy.xml file, and resolve the dependencies from there.
Gradle doesn't take care of that naturally, but using code from this issue, with a few tweaks, managed to get dependencies with gradle.
further more, there is a IvyXML plugin for gradle, with claims it can take care of most of this stuff.
I'm trying to diagnose a failure in my ant file when it runs a Worklight task. I have a small ant file containing a simple reference to a Worklight task. This works correctly.
<target name="rawBuildApplication" >
<app-builder
applicationFolder="${applicationSource}"
environments="mobilewebapp"
nativeProjectPrefix="xxx"
outputFolder="${outputFolder}"/>
</target>
However when I invoke this ant file from a build control ant file (actually from the RTC build system) I get a failure (below), showing worklight failing to find an apache Java class. I assume there's some simple environmental difference, perhaps a classpath. It might help to figure it out if I knew where Worklight loaded the apache commons from. Right now I can't see anything in my environment in the case that works that points any apache Jar.
myAntFile.xml:146: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.deleteQuietly(Ljava/io/File;)Z
at com.worklight.builder.util.BuilderUtils.<clinit>(BuilderUtils.java:672)
at com.worklight.builder.config.UserBuildConfiguration$Builder.<init>(UserBuildConfiguration.java:203)
at com.worklight.ant.builders.ApplicationBuilderTask.createBuildConfiguration(ApplicationBuilderTask.java:149)
at com.worklight.ant.builders.ApplicationBuilderTask.execute(ApplicationBuilderTask.java:80)
Edited: the cause is the use of -lib to add the RTC toolkit directory, exactly why this clashes and how to work around yet to be determined
Usually means you have version of the commons jar in your classpath, and its overriding the one packaged in the worklight-ant.jar. the apache commons files are inside the worklight-ant.jar file
Additional info from djna: I can confirm that when adding the Rational Team Concert (RTC) 3.0 toolkit to the ant classpath, either explicitly with -lib, or when selecting that option in the RTC Build definition some conflicting commons jars are added to the classpath. Worklight packages the classes it needs in its jar, but the -lib folder seems to take precedence.
My workaround is to replace the conflicting jars with later ones. I used these jars
commons-io-2.4.jar
commons-codec-1.8.jar
httpclient-4.2.5.jar
httpcore-4.2.4.jar
httpmime-4.2.5.jar
I guess the other alternative is to upgrade to a newer RTC, but in our environment that's not currently possible.
I was trying to add some Java Libraries (AWS SDK for Java, Apache Commons Math, etc.) to my Grails project since some of my Java source code (placed in src/java) had dependencies. By following this answer, I was able to resolve compile errors by adding the jar files to the /lib folder and add it to the build path, as answered here: Add Java Libraries to a Netbeans Grails Project
However, when I call my Java source code from my controller during runtime, it is unable to find the Java libraries that I added, showing a NoClassDefFoundError. Should I be adding something to the BuildConfig.groovy file? I'm not sure what the name convention for the jar files to be added to the dependencies.
The question you refer to is 5 years old. You should use newer resources :)
The preferred approach now is to use dependencies in BuildConfig.groovy, and let Grails (via Ivy or Maven) download the jars for you once and reuse them for various projects.
It's not always obvious what the syntax is, and I find that http://mvnrepository.com/ is a great resource. For example if you search for "commons math" and click through to http://mvnrepository.com/artifact/org.apache.commons/commons-math you'll see a few versions. Click on version 2.2 and you'll see the Maven dependency XML but you can click on the Gradle tab and it's going to be similar to what you need for Grails. So I'd add
dependencies {
compile 'org.apache.commons:commons-math:2.2'
}
and if necessary change compile to runtime, build, etc. depending on what you need the jar in the build process.
In the rare case that you do have a jar that isn't available in a Maven repo (e.g. a shared library at your company) then you can put the jar file in the lib directory. As you've seen, Grails doesn't auto-detect it (this is as of version 2.0). But you can run grails compile --refresh-dependencies to get your jar added to the classpath.
My issue turns out to be the fact that AWS Java SDK had dependencies (Apache HTTP Client) that were not installed yet and that I was unaware of.
This is what I had to configure this for my BuildConfig.groovy file
dependencies {
runtime 'org.apache.httpcomponents:httpclient:4.2.5'
runtime 'com.amazonaws:aws-java-sdk:1.4.7'
}
All the dependencies for AWS Java SDK 1.4.7 can be found here: http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.4.7. All the dependencies outside of HTTP client were already installed for me, but may not be for your Grails setup.
What approach has worked well for you combining IVY + msbuild?
Our goal is to integrate IVY into the C#/C++ build process for dependency resolution and publishing. We have tried adding it to custom tasks at the beginning and end of the build and we have tried wrapping the msbuild calls with ant+ apache-ant-dotnet.
Other options might be gradle, buildr, rake.
What do you use?
Thanks
Peter
Most build technologies can use libraries found in a local directory. I'd suggest using the command-line ivy program to populate this, at the start of your build:
java -jar ivy.jar -ivy ivy.xml -settings ivysettings.xml -retrieve "lib/[conf]/[artifact].[ext]"
Your dependencies are listed in a standard ivy file called ivy.xml. The protocol, location and layout of your remote repository is described in ivysettings.xml
The advantage of this approach (as opposed to switching to Gradle, etc) is that you're not trying to replace your existing build tool. Ivy is solely concerned with managing dependencies.
My team has been using Ivy for .NET for a couple of years very successfully. I know several more that give it a vote of confidence.
Use it standalone. Wrap calls into msbuild tasks. No need to use Ant integration.