I would like to execute uncompiled groovy scripts with the java jre. I would like to provide just one jar file to do this. I think in older groovy versions this was possible with a groovy-all jar.
e.g. java -cp lib/groovy-all-2.4.6.jar;. groovy.ui.Main myscript.groovy
But this groovy all jar does not exist for new groovy versions. Is there another jar to do that?
I found the gradle-groovy-all project in this thread. This works fine for me. With the newest commit on the master branch the dependency org.apache.ivy is incuded in the built jar.
There are many groovy-$something artifacts (sql, json, ...) and
all was just the combined jar with all of them in it in the 2.4 days.
Now the "-all" is only deployed as Bill Of Materials, that itself no longer
is/contains a jar, but points to all other groovy-$something artifacts itself as transitive deps.
So using "groovy.jar" and "groovy-(a|b|c).jar" might be a way out for you and this all boils down to one jar, if you don't need anything else but groovy.jar.
Or you could roll your own "all" jar (e.g. build a uber-/fat/shadow-jar
in a project with all deps you need (e.g. groovy-all and whatnot).
Related
I'm curious to know how Intellij can resolve the dependency conflicts? Let me explain my situation. I should work on the spring boot application. It uses Maven. IntelliJ can build and run the application without any problem, but when I make a jar file,
mvn clean package
and run the jar file
java -jar xxx.jar
I faced a java.lang.NoSuchMethodError. Some conflicts on dependencies caused it, and my application uses the wrong version of a jar file.
I want to know how IntelliJ can find the correct jar file which contains the method, while it uses the same pom.xml, which I face error while using with the mvn command.
And is it possible to find that which version of every jar file used by IntelliJ? (I want to use this for correcting the pom file)
Thanks
There is a big difference between runtime and compile time when it comes down to such things.
compiling code (such as mvn package), and writing code (as in, what IntelliJ is doing to ensure that your editing experience is nice; auto-complete dialogs for all the libraries you use, errors if you try to invoke non-existent methods, etcetera) are one thing (let's call it 'write time').
Running your code, as with java -jar xxx.jar is something completely different.
maven and your dependency list is a write time thing. Thus, maven and intellij know where to look for your dependencies, but when you run java -jar xxx.jar, that does not know where to look, and thus, your dependencies aren't found, and thus, NoClassDefFoundError occurs.
That's because that jar file that maven makes just contains your code, it is completely disconnected from your maven file (your maven stuff is not looked up when you run your code at all), and it does not contain your dependencies.
You'd have to ship them separately. There are 3 solutions to this problem:
Preferred solution: jar files contain a so-called manifest, which tells the JVM for example what the name of the main class is within that jar file. It can also contain the class-path (this is in fact the only class-path checked when using java -jar to run jar files; you can't specify a -classpath parameter). This lets you deploy your app such that your app installation looks like:
/usr/local/projects/YourApp/main-app.jar
/usr/local/projects/YourApp/dep/guava.jar
/usr/local/projects/YourApp/dep/mysql-jdbc-connector.jar
/usr/local/projects/YourApp/dep/jdbi.jar
etcetera, and to run this application, just run main-app.jar. This requires the manifest of main-app.jar to contain the entry:
Class-Path: dep/guava.jar dep/mysql-jdbc-connector.jar dep/jdbi.jar
When running the jar, the Class-Path entry is split on spaces, and then each entry is looked up relative to the directory that contains main-app.jar. By shipping the jars separately, it's easy to separately update them or replace them, and deploying a new version is much faster (you just ship the jar(s) that were changed, not all of them. Many apps have hundreds of MBs of deps, whereas their own jar is a few MB at most, makes a big difference for example when pushing deps from your dev machine to the test server!)
This leads to the question: How do you make maven put that Class-Path entry in the output jar file's manifest? The maven-jar-plugin can do the job - see this answer for more details.
Shade in your deps (also called striping, or fatjar, or bigjar)
This is the notion of taking all your deps, rewriting their name to avoid version conflicts, and then making one humongous jar file that contains everything. It has the considerable downside of being a much slower process, especially if you need to push this out to another system for testing. Use the shade plugin to do so.
Don't use java -jar.
java -jar x.jar cannot work unless the jar file either has a Class-Path entry in its manifest, or contains every dep it needs. However, you can also run your java code like so: java -cp main-app.jar:dep/guava.jar:dep/jdbi.jar:/dep/other-deps-here com.foo.YourMainApp. This is.. not convenient, but you could presumably write a shell script or some such. This isn't a very java-like solution, I don't recommend it.
What is the difference between Jar and Plugin in Java? Both looks the same by achieving the same purpose and when do use Jar and when do we use Plugin.
A plugin is an extension to Maven, something used to produce your artifact. Plugins are used only to make maven process successful. They are not directly connected to your application. plugins do not include in your last war/jar file for the service or client.
A dependency is a library that is needed by the application you are building, at compile and/or test and/or runtime time. the classes you used from jars will include in your final war/jar.
This will be helpful for you,
What is the difference in maven between dependency and plugin tags in pom xml?
Difference between plugin and external jar file
plug-in is a software component that adds a specific feature to any computer program.It specially use to customize any computer program.But .jar file is a java executable file which can only run on an environment which Java installed.
Today at work I came across something interesting. Say i have an old java project that were compiled with an ant build file and we have converted this project into a maven project. So now to build this project, we only need to do a mvn install.
When i do call
mvn install
I get a myproject.jar under the target folder, along with all the dependencies under a lib folder inside the target folder.
To run the executable of this jar I need to do something like :
java -classpath $classpath com.myproject.Mainclass $myArgs
Where $classpath is the path to all of my external libs and where $myArgs is the arguments that is passed to the main function.
I came across this website and I'm really considering to use the spring boot maven plugin to package my executable jar.
Wouldn't it be easier to execute it if all the dependencies are packaged in a single jar file ?
Why would I use the manual configuration vs the Spring Boot Maven Plugin for the executable jar ?
What are the pro and the cons of doing this ?
As the article you had linked covers with pros and cons how to do such single jar file packaging, I'll write out things that you need to consider if you want to use this approach.
Pros:
1. Simplicity of deployment
Users don't have to maintain any dependencies. All they need to do to run the app is get the jar file and execute java -jar file.jar.
2. No easy way to update dependencies by user
If your app uses some external dependencies, you can be sure they are in version that you have chosen. Using "classic" approach user can easily update it by himself to the version that may require some migration steps in your app.
Cons:
1. Size of final package
If your app has large dependencies, every update will require users to download the whole package,
even if dependencies haven't changed.
2. No easy way to update dependencies by user
To change a version of any dependency you will need to update the whole package, where using the old way you could update only the dependency jar.
Summarizing, if your app doesn't have any heavy (in sense of file size) dependencies, I'll personally use single jar file approach. Even if your dependencies changes frequently. It's a lot easier to change a single file, no matter if your app has to be updated or some of its dependency.
Is there a plugin or framework that converts a java web application (war) into a maven project (pom.xml and mvn install command jar)? Thanks
EDIT An alpha java program that converts a jar's list into a maven project (pom.xml and mvn install command jar) is:
https://github.com/sunrelax/jar2mvn
The groupId for the artifacts is not even in the manifests within the jars in the lib folder so the research to fit version+groupId is quite complex.
Also, the way the package is generated (war-plugin) and the specific folders the original files are located can't be deducted.
ONLY in the case you decide to pass all the standards, and keep your own repository (with your own groupIds), maybe will be possible to auto-assign from jars version own-generated-groupId... but it's not worth it, later it would be difficult to maintain.
Better, and talking about third part libraries, take the jars one by one and hopefully you will have the version in the manifest and locate them in public repositories.
I work on a big Java application and I'm having problem compiling it under Eclipse Kepler:
the application is based on Maven 3.1.0 and successfully compiles there
I generate Eclipse configuration (project files) using mvn eclipse:eclipse
The problem is that certain classes present in more than one JAR (e.g. imagine a class Http and two versions of this class where newer has more methods) and Eclipse makes a wrong choice of the depending class (older one) for particular project which makes it not compilable.
I tried to move Jars up/down in the project dependencies and it helps in certain situations, however, it means that I'm changing configuration changed by Maven.
Is it possible to configure Eclipse so that is "smarter"? Is it caused by Maven (POM files, a bug in Maven's eclipse plugin, ...) although maven compiles the project without any problems? Any other suggestion?
You should not use mvn eclipse:eclipse. The official way today is to use the m2e plugin (which is much smarter) with File->Import->Existing Maven projects.
When you open a pom.xml file you can see the dependency hierarchy and why a given jar was chosen.
(Note that most but not all standard distributions of the latest Eclipse contains m2e. If your do not you can download it from the marketplace, but it may be easier to download a distribution that has it).