I'm having trouble deploying a JAR I created from a groovy script, and I think it's because in the script I'm using Grape's Grab functionality to pull in a few libraries, and then when I build the JAR those libraries aren't included in the class path or anything.
How can I go about converting these #Grab statements to "import" statements?
Grape should work if you include all groovy libraries into your application.
OR
use gradle to build your library with dependencies, put dependencies (grabs) into build.gradle and exclude them from your groovy. in this case you need to put into your application groovy-all-XXX.jar with your library and other graped dependencies.
FYI
you can collect all dependencies in a strange way like this:
by default artifacts stored in ~/.groovy/grapes directory
for windows it's %USERPROFILE%\.groovy\grapes
see here how to customize it
the simple way to take all jars:
to specify custom empty directory for cache
and after Grape command list all jars in this directory and include them into deploy with your library.
but this like creating custom gradle )
Related
I have a Java application that uses Maven, so the Maven POM file (pom.xml) lists all of the dependencies needed to compile and run the application.
I'd like to use groovy during my development and testing and then plug in the code into the Java files when I'm done. I haven't done this yet so it might not be feasible but if it is, that is what I'd like to try and do.
I would like to know if there is a function I can call that will read my pom.xml file and add all of the dependencies to my classpath so I can just import the packages that I need and goovy will already have them loaded (or at least know where to load them).
The groovy script might look like this:
addAllPomDependenciesToMyClasspath();
import my.code.pkg1;
import my.more.code.pkg2;
(new ClassInMyCode()).doCoolStuff();
Without this, I need to specify all my jars on the CLASSPATH and it would look something like this (I haven't yet done this because there are too many dependencies).
#!/bin/sh
groovy -cp "../lib1/target/MyJar1.jar:../lib2/target/MyJar2.jar:$HOME/.m2/repository/com/google/guava/guava/30.1.1-jre/guava-30.1.1-jre.jar: KEEP LISTING THESE UNTIL ALL DEPENDENCIES ARE INCLUDED"
Perhaps a better solution would be just to create a gradle file. Let me know if that is the preferred way (if there is no way to autoload all of the maven dependencies).
What have I tried
I've tried searching for solutions and found several ways to add your dependencies to the class path but they don't answer my question.
Some results were:
How to add multiple jars to the classpath of groovyConole/groovysh?
How do I auto load a database jar in Groovy without using the -cp switch?
Dynamically load jar in groovy
Including all the jars in a directory within the Java classpath
I'm guessing there is a "groovy" way to do this that approaches the problem differently and that is why I haven't found an answer to this question.
Misc Notes
(Q) How can I add multiple jar files to my groovy classpath? (A) Use "-cp jar1;jar2" (in Windows use semi-colons to separate the names of the jar files, and in Unix use colons to separate the filenames. See https://stackoverflow.com/a/219801/3281336
I am trying to use loaded jar files of my class path into my module. I
know requires will accept only modules names.
my jar files are present inside the Spring Jar Files folder.
I tried to use #Configuration annotation inside my appConfig.java file and IDE could not recognize it.
Your help is much appreciated as I am new to the programming world.
Normally, I use Maven or Gradle to handle all the jars.
It seems you have just started with Spring.
I suggest you try Spring Boot with Maven or Gradle to manage the library and the code lifecycle (compile, build, test).
This is one tutorial for example: https://spring.io/guides/gs/spring-boot/
You can add a jar in Eclipse by right-clicking on the Project → Build Path → Configure Build Path. Under Libraries tab, click Add Jars or Add External JARs and give the Jar.
Example link
The above solution is obviously a "Quick" one. However, if you are working on a project where you need to commit files to the source control repository, I would recommend adding Jar files to a dedicated library folder within your source control repository and referencing few or all of them as mentioned above.
I'd suggest go for the second one if you are planning to build this as a proper project and put it in a source control repo.
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.
I have a Netbeans Java Project under Subversion (svn). This is shared with another guy working on the project.
The project requires an external library that we have as a jar file. Now, when either of us makes a change and commits it, the project's library dependencies fail as we have different paths for the library ( as we are working on different machines the location of the jar file is different ).
This means that every time I update my repository, I have to resolve library dependencies.
Is there a way I can prevent this?
1st way: You can use NetBeans Library support.
Go to Tools->Libraries, and new Library with your jar. Name it the same way on both machines and include to your NB project as Library rather then direct path to jar.
2nd way: use relative path.
Agree on having jar located at ../lib/foo.jar and use this path in NB project
3rd way: use property file.
Add file named, for example, build.properties but don't commit it to svn. So both of you will have different local version of that file.
Content should be something like next:
myproject.library.foojar=C:/foopath/foo.jar
In your build.xml include this file:
<property file="../build.properties"/>
In your nbproject/project.properties find a reference to the jar -- it will look like:
file.reference.foo.jar=C:/foopath/foo.jar
change it to
file.reference.foo.jar=${myproject.library.foojar}
Also you may want to add build.properties into ignore list for svn to avoid commiting it.
I recommend you to use Maven to control library dependencies(jars). It is easy to use and NetBeans has a module to use it easily.
Maven download all the dependencies you declared into a local repertory so you don't need to worried about managing libraries, Maven do it for you.
Also with this module you can search libraries in the Maven repertory(Has a lot of java librarys) only you need to type the name and maven download it for you.
Here there are some links for how to use Maven With NetBeans:
http://platform.netbeans.org/tutorials/nbm-maven-quickstart.html
http://today.java.net/article/2009/10/14/working-maven-netbeans-671
I have a java project which is previously developed by another developer, in this application there are a lot of unnecessary libraries. I was able to delete some of those libraries. But, as there are a lot of them I want to know whether there is a technique to scan the project and detect unrelated libraries to the project.
I recommend Tattletale from JBoss.
Depending on the build method, it should be easy to remove unnecessary libraries without deleting/adding them by simply recompiling the application modifying the classpath at compile time, or rather modifying the build files by one-by-one deletion of lib dependencies. Either one of these methods will require no manual deletion of jars.
1) If you set the jars using the classpath manually, you can play with classpath wild cards to remove / add different jars when running : Setting multiple jars in java classpath classpaths . This does not require manual deletion / adding of jars.
2) Find the dependencies definition (pom.xml in maven, ivy.xml for some ant projects).
and One by one delete the (maven)
<dependency>..</dependency>
or (ivy)
<dependency .... />
entries in your build file.
If you have the correct build plugins installed - then your IDE will immediately rebuild the project using your new definitions (no error prone removal/deletion of jars or classpath entries).