We have been trying to create JAR files from the LanguageTool (LT) Desktop version we downloaded that contains various JAR files. LT at this link made the statement that we needed all the files in these folders libs org and META-INF in our project. LT has repied they have no experience with Netbeans or JavaFX.
LT Directions
The app was built on Windows 7 with Netbeans 8.2 as a JavaFX 8 and Maven JDK 1.8
We tried following this tutorial the author was not much for proper code formatting and failed to mention that LT is not thread safe. We seldom work with threads but think our code is correct?
TUTORIAL
To install the Class AmericanEnglish.class which is in the LT Desktop zip file we extracted we used this process
cd C:\Users\Me\Documents\A A A A A LT UnZip\LanguageTool-4.7\LanguageTool-4.7
jar cf languagesLIBS.jar libs/*
jar cf languagesORG.jar org/*
jar cf languagesMETA.jar META-INF/*
Here is where it gets odd to our limited knowledge of adding Dependencies to Netbeans
1. Open the Projects tab.
2. Right-click on Dependencies.
3. Select Add dependency.
4. Set groupId to: language(can be anything)
5. Set artifactId to: en (can be anything)
6. Set version to: 4.7(can be anything)
7. Click Add to continue.
Dependency is added to pom.xml and appears under the Libraries node of Maven project. Continue:
1. Expand Dependencies.
2. Right-click on library (e.g., group.id).
3. Select Manually install artifact.
4. Set Artifact to install with the Java Archive (.jar) file path.
5. Click Install locally.
This process did place the AmericanEnglish.class in a JAR and it is found by Netbeans
import org.languagetool.JLanguageTool;
import org.languagetool.language.AmericanEnglish;
import org.languagetool.rules.RuleMatch;
Here is the error when we try to populate the JLanguageTool with AmericanEnglish
While the error NoClassDefFoundError would seem to indicate that the app can not find the
AmericanEnglish.class and that is the cause of the error ClassNotFoundException
Our question obviously is how do we fix this ?
And are we crating the external JAR files correctly?
Exception in thread "Thread-4" java.lang.NoClassDefFoundError: com/google/common/cache/CacheLoader
at com.mycompany.maventest.CheckSpellController.lambda$ini$0(CheckSpellController.java:43)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: com.google.common.cache.CacheLoader
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
We also see these warnings when we Clean and Build the project
The POM for languagetool:LIBS:jar:4.7 is missing, no dependency information available
The POM for languagetool:ORG:jar:4.7 is missing, no dependency information available
The POM for languagetool:META:jar:4.7 is missing, no dependency information available
exec-maven-plugin:1.2.1:exec (unpack-dependencies) # mavenTEST
When the Clean and Build is run we see the dependencies unpack
Here is the few lines of code that cause the error
static JLanguageTool langTool;
public void ini(){
new Thread(() -> {
langTool = new JLanguageTool(new AmericanEnglish());
}).start();
}
The ini() method is called from the initialize method
The necessary JAR files are in the Dependencies folder
The project imports these files
You need to use the actual JAR and the process where you thought it was a bit ODD
Is not the correct way to add JAR files. The extracted ZIP folder has all the gold or should we say JAR's. Here are a few screen shots and directions. That said we are still getting the NoClassDefFoundError so we will work on fixing that part of the question
Delete the three JAR's you added LIBS-4.7.jar META-4.7.jar and ORG-4.7.jar
We would also suggest opening the .m2 folder and under /repository/org/languagetool delete the languagetool folder. Do NOT worry everything will get recreated.
Right Click Dependencies folder and select Add Dependency
In the Query text field enter "org.languagetool"
Here is a comment we did not find languagetool 4.7 JAR's as central only local ? ?
You might like to try and use the central 4.6 JAR's
Expand the org.languagetool:languagetool-core folder and select the 4.7.jar
Once that JAR is in the Dependency folder Right Click ad select Copy Location
Now Right Click the same JAR once more and select Manually Install Artifact
In the Artifact To Install text box paste with a Ctrl + V
This will take you to the location of the JAR select it and presto magic the Artifact is added
Notice the language-en-4.7 we created this JAR file because we could not find AmericanEnglish.class in any of the downloaded files. See Last screen shot
Here are the screen shots in the order to match the above direction
I am not holding my breath that using the downloaded 4.7 JAR,s is the best idea
You might try reaching out to Maven and Language Tool and ask why LT 4.7 is not in the repository!
Best of Luck
When I open my cordapp-example in intellj. I can see 2 build.gradle files.
One under java-source and another in the cordapp-example directory i.e main director. What is the difference between both of them?
This is a result of the way gradle works for managing multiple separate modules within one top level project. In this case, the cordapp-example has a java version and kotlin version - both have their own build settings and dependencies. The top level build.gradle has configuration and dependencies which are applied to both projects.
You can see that settings.gradle contains the following:
include 'kotlin-source'
include 'java-source'
This defines the submodules included in the project.
I have a project that is using spring boot and when is build it generates a jar containing all dependencies jars.
I want to obfuscate this jar, but after obfuscation when I try to run the jar I get:
java.lang.IllegalStateException: Unable to open nested entry 'lib/h2-1.4.185.jar'. It has been compressed and nested jar files must be stored without compression. Please check the mechanism used to create your executable jar file
at org.springframework.boot.loader.jar.JarFile.createJarFileFromFileEntry(JarFile.java:378)
at org.springframework.boot.loader.jar.JarFile.createJarFileFromEntry(JarFile.java:355)
at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:341)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:108)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:92)
at org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:74)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:60)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:45)
I tried to find what is the issue and for that I create a config file only with:
-injars MyJar-orig.jar
-outjars MyJar.jar
-libraryjars <java.home>/lib/jce.jar
-libraryjars <java.home>/lib/rt.jar(java/**,javax/**)
-libraryjars '..\..\resources\proguard5.0\references\log4j-1.2.17.jar'
-dontobfuscate
-dontshrink
-dontoptimize
I was expected to get the original jar, but I am getting a jar that is smaller and all the classes have different size (smaller in general).
What is proguard doing in this case?
Any idea how I can solve my issue?
please have a look at the '-keepattributes' parameter. When using the Proguard GUI, under the 'Obfuscation' tab there is an option for this. Clicking this solved my problem which was similar/ the same as yours.
I am using sbt-osgi to repackage some library dependencies into OSGi packages, and that works well, until I started using scalajs as well. The library dependencies are defined as normal projects something like this:
lazy val bonecp = OsgiProject("com.jolbox.bonecp", buddyPolicy = Some("global")) settings
(libraryDependencies += "com.jolbox" % "bonecp" % "0.8.0-rc1")
The OsgiProject function has default OSGi settings plus some implicits for determining what path the project has. When the bundle task is run on these projects, a new jar with OSGi stuff is created based on the OSGiProject settings. This project just rebundles the bonecp library as an OSGi jar and has no sources. The problem here is that since there's no source, theres no files in target/scala-2.11. This causes sbt-osgi to spit out a ton of ignorable errors, but scalajs is not as forgiving and refuses to do anything with these projects. Is there any good way to unpack the downloaded libraryDependency jars into target/scala-<scalaVersion>?
I was a heavy Maven user and now I'm gradually using SBT for some of my projects.
I'd like to know how could I use SBT to create a standalone Java project? This project should be packaged as a JAR file and this JAR file would be used as a dependency in another SBT project.
In Maven, I could tell in my pom.xml what type of artifact it should produce when I build it. Is there something similar that I can do in SBT?
There is a difference between standalone and making a project useable as a dependency or another project. In the first case, you would use a plugin such as sbt-assembly. What it will do is create one jar file containing the project class files along with all of its dependencies. If you write an application, what you get is a double-clickable jar that you can execute from anywhere.
If you want to use your project A as a dependency for another project B, you have different options. You could just package the class files of A, using sbt package (answer of #Channing Walton). Then you could drop the resulting .jar file in the lib directory of project B. However, if A also requires libraries, you must make sure that they also end up in project B's libraries.
A better approach is to publish your project. You can do that purely on your local machine, using sbt publish-local. That will store the jar as produced by package in a special local directory which can be accessed from sbt in another project, along with a POM file that contains the dependencies of A. It will use a group-ID (organization) and artifact-ID (name) and a version of your project A. For example, in build.sbt:
name := "projecta"
version := "0.1.0-SNAPSHOT"
organization := "com.github.myname"
scalaVersion := "2.10.3"
publishMavenStyle := true
After publishing with sbt publish-local, you can add the following dependency to your project B:
libraryDependencies += "com.github.myname" %% "projecta" % "0.1.0-SNAPSHOT"
If you have a pure Java project, you can omit the Scala version suffix, i.e. in Project A:
crossPaths := false
autoScalaLibrary := false
And then in Project B:
libraryDependencies += "com.github.myname" % "projecta" % "0.1.0-SNAPSHOT"
(using only one % character between group and artifact ID).
More on publishing in the sbt documentation.
'sbt package' will produce a jar file.
If you want it to be executable you need to add the following to your .sbt config:
mainClass in Compile := Some("your.main.Class")
Sure, you can use 'sbt package' command, it creates a jar file but this jar will be without any dependencies. To run it necessary to specify 'classpath' arg to the libraries.
In your case you wish a standalone runnable file. And you need to add the dependencies.
To do this you can use 'assembly' plugin for SBT, see https://github.com/sbt/sbt-assembly/
Afterward you can just run 'sbt assembly' command, it provides a fat jar file with all dependencies that you can deploy and run anywhere and at any time.
For details see this article
publishLocal
builds the artifact and publish in the local Ivy repository making it available for your local project dependencies.
publishM2
same as above, but the artifact is published in local Maven repo instead of Ivy repo.
I think the easiest way to produce a stand-alone jar with your project in it,
is sadly not lying inside sbt.
I personally use my IDE: Intellij to make the jar (through the 'build artifact' feature).
Thanks to Intellij I can easily choose which library I want to include in the jar or not, (for instance the scala stl).
IMHO, this is by far the simplest method to get an executable jar for your project.
If you put the scala stl you can run your jar with the "java -jar" command, if you don't you have to run it somewhere with the correct version of scala installed with "scala".