I'm new to Gradle. I see that Gradle lib already has a file 'groovy-all-2.4.12.jar' in lib folder and I don't seem to have any issues with tasks and or dependencies. Still, is it necessary in any scenario to install Groovy on my system on top of it?
Reason why I ask is that, when I do 'gradle -v' in command prompt, I see few warnings. Please see attached screenshot.
With gradle it is strongly recommended to use the Gradle wrapper committed into the project you are building instead of a system-wide gradle distribution (that is gradlew and not gralde). This guarantees the matching version of Gradle your project has been tested with.
With the Gradle wrapper you do not need to care about any dependencies that Grade itself needs, such as groovy and you really do not need to install anything of Gradle at all as the wrapper in your project will download all it needs on the first run.
The minimum setup for the Gradle wrapper is:
/gradlew - unix shell script
/gradlew.bat - windows batch script
/gradle/wrapper/gradle-wrapper.properties -- the properties file defining the version
/gradle/wrapper/gradle-wrapper.jar -- the minimal jar (50Kb) that takes care about the rest
The above files must be committed into your project and this is what 99% of all gradle projects do. You will find further details here https://docs.gradle.org/current/userguide/gradle_wrapper.html
Related
I have a project in which I am using maven-release-plugin to make periodic releases. I also have some script files like start.sh and stop.sh which helps in starting up the project with multiple steps using just one command. The script contains commands like, (but not limited to)
java -jar module-0.0.1-SNAPSHOT.jar
My problem is, when I run release plugin it updates all the POM files but does nothing to this script file. I want to update these script files as well along with POM files. These script files contain the version number exactly the same as pom file and the way I mentioned.
Currently, I am updating these files manually after each release.
Any help will be greatly appreciated.
Maven release plugin is indeed all about releasing the maven version. Maven as a build tool, builds the artifact and releases it.
It has nothing to do with various script files. So you should decide first of all:
Whether its a maven responsibility at all to deal with these scripts.
If so, you can create your own plugin that will do the changes. Or alternatively you can use filtering feature, Maven build helper plugin to get the access to the versioning information and assembly plugin to prepare the distribution.
Otherwise, I see 2 possible options:
Alternative 1
Rename the versioned artifact with something generic that doesn't really include any maven related versioning information.
In this case the script will always be the same and will run: java -jar my-module.jar
Alternative 2
Complicate the script so that it will find the file and resolve the version dynamically. Then it will memorize the path to the file in some variable and will run java -jar $here_is_the_resolved_file_with_version.jar
I'm currently trying to migrate a project from Gradle 3.5 to the latest Gradle version 4.9. and I'm running into the problem, that Gradle doesn't find the resources that it needs to execute the junit tests. These resources are generated upfront and contain some configuration files and referential data.
The project uses a combination of npm and Gradle to compile. Usually we run a npm script which executes a couple of tasks sequentially using run-s, e.g. webpack builds to generate some static resources. At the end we compile everything together using Gradle. The last Gradle task also executes the junit tests. This step fails and makes the whole build fail. The Gradle runner complains that some resources are not found, although the get properly copied to the right places.
When I execute ./gradlew test --rerun-tasks (Yes, we use the wrapper, which has been properly upgraded, too) right after the last Gradle build step failed, it executed the junit tests successfully.
I know, that the directory structure changed in Gradle 4.x, but this doesn't seem to be the problem.
My suspicion is, that it has something to do with how we normally run the whole build process. Something in the combination with npm.
I apologize if this sounds to simple (or the fact that there are other links that define this problem) - but I'm a complete beginner to Maven and even Java.
All that I'm trying to do is to run this code to see what it does:
https://github.com/semanticvectors/semanticvectors/wiki/GettingStarted
The Wiki says that uses can either download the .jar file or use the maven repo. I downloaded their .jar file and tried to run it but failed. I use this code:
java -jar /home/user/semanticvectors-5.6.jar
That .jar file didn't work for me and from other stackoverflow links, it seems that either the .jar file is not setup properly or I have a non-compatitble java version.
In any case, I've decided to try using Maven to get this running. I've installed Maven using:
sudo apt-get install maven
It seems to be working as everything was successful in setup. But now I'm not too sure what to do after. This Wiki (linked above) as go to this Maven repo site (https://oss.sonatype.org/#nexus-search;quick%7Esemanticvectors). To my understanding (and correct me if I'm wrong) I thought Maven is a super repository for developers and testers to work from the same code, so I thought I could use Maven as an alternative to running to program. Anyways, I'm open to any suggestions to get the program running to see what it does, thanks.
If you're interested in knowing more about me: I'm running a 16.04 Ubuntu system with Java 8.
The idea is that you can either build the JAR yourself - get the source from SVN and build it (using maven commands, as maven is a build tool), or you can use the existing JAR that is already "prepared" and ready for use in the maven-repository (nexus, in this case).
The result should be the same - if you use the JAR as a dependency in your code (add it to your pom.xml) or if you build it yourself.
You can learn more about Maven and things will be much clearer...
I just converted my Maven project to a gradle project. It was a multi project structure:
master-project
pom.xml
---->project1
-------->pom.xml
---->project2
-------->pom.xml
---->project3
-------->pom.xml
I ran a gradle init on it and have this structure now:
master-project
build.gradle
---->project1
-------->build.gradle
---->project2
-------->build.gradle
---->project3
-------->build.gradle
Everything builds fine, and I have been able to get some things done with that I couldn't figure out how to do with Maven, so that's great. Next step was to integrate that into the IDE since the Maven Dependencies are gone since I have removed the pom.xml files.
However the project isn't recognized as a gradle project - and I am not sure how to change that?
In Eclipse Mars it's still recognized as a Maven build, not gradle....
Thanks in advance.
EDIT: I reimported the projects which enabled the plugin for Eclipse. Now I am having weird behavior.
The build works from the command line, however when attempting the same execution from within Eclipse, it fails trying to copy the file dependencies.
For example:
Couldn't copy dependency jakarta-regexp-1.4.jar
java.nio.file.NoSuchFileException: C:\Users\user.m2\repository\jakarta-regexp\jakarta-regexp\1.4\jakarta-regexp-1.4.jar -> build\jfx\app\lib\jakarta-regexp-1.4.jar
I haven't changed the repo from maven yet - just changed the build scripts. This is running from the master project. So I am confused as to why the script would work from the commandline but not from within eclipse.
EDIT 2: Turns out this behavior is also present when running from the command line when the --daemon flag is set. Is there anyway to run the tasks without the daemon in Buildship? Or perhaps a way to fix this issue when the --daemon flag is enabled?
Thanks.
The issue with the build was that there is a leak in the JDK when bundling the JRE with the native app. This only happens when running with the --daemon flag (which all IDEs user). Therefore until this is fixed you will need to run gradle --stop and then run the clean.
The plug in I am using is no longer running the native task when running with --daemon.
Yay, my thesis is done! Now that the pressure is off and I've had my fill of playing Skyrim, I'm converting the code I wrote for my thesis from a chaotic directory built with ant to a nice maven project.
I originally had a bin directory with about 20 bash scripts that ran the various java and ruby programs used in my thesis, including the final jruby/sinatra-based web server. I am planning on moving my scripts to src/main/scripts, but I need to figure out how to handle the classpath.
I had previously just hardcoded paths in my scripts to the manually-downloaded dependencies. However, now that maven is downloading and storing all the jars I need, what's the best way to reference them from my scripts:
Should I just get the scripts to reference the full paths of various jars in the local repository like before?
Should I make the local repository directory a configuration option for my scripts and use relative paths to this directory?
Should I build a big hairy jar with all the dependencies using the maven assembly plugin and access this via the script-relative path ../../../target/*-jar-with-dependencies.jar?
Is there some better option I haven't thought of?
In your script, use the exec:java plugin to run Java classes. It will sort out the classpath based on the defined dependencies. Then you don't need to worry about it.
Relook at all the scripts that you have. Potentially you could achieve the functionality of some of them using maven exec plugin.
Besides assembly and shade plugins, you may want to look at the functionalities provided by maven dependency plugin as well.
In my project (Soluvas fb-tools/fbcli), because I use Java 6 and later (which supports wildcard classpaths), here's what I do:
#!/bin/bash
# Must run first: mvn package dependency:copy-dependencies
java -cp 'target/dependency/*:target/fbcli-1.0.0-SNAPSHOT.jar' org.jboss.weld.environment.se.StartMain "$#"
No need for manual generation of classpaths. :)
There are quite some plugin doing similar things you mentioned. Assembly plugin you mentioned is doubtless one of them (and the way you suggested is also a neat working solution).
You may want to take a look in AppAssembler and Shade. They all provide some mechanism to bundle the dependencies and produce a directly executable package.
Here is CLI example using Maven plugin exec:java as mentionned by #artbristol in another comment:
mvn exec:java -Dexec.mainClass="mypackage.MyClassWithMain" -Dexec.args="arg1 arg2"