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 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
I am using the latest version of the cxf-xjc-plugin (https://cxf.apache.org/cxf-xjc-plugin.html) plugin, 3.1.0. This plugin generates Java classes for the given xsd files successfully. When I run a clean on the project, the target/generated-sources/java folder is left in place. I've simplified my POM to only use this plugin and the problem persists.
Older versions of the plugin do not do this as don't other similar plugins like jaxb2-maven-plugin.
I have looked at the projects POM and I don't see the clean plugin being configured to protect these files. What else could be going on to cause this?
What OS are you using? Could it be a permission issue where you built as root outside the ide once? I also saw this
Why doesn't Maven's mvn clean ever work the first time?
Is it possible to use Gradle to produce a tree of what depends on what?
I have a project and would like to find out all the dependencies so I may be able to prune it a little with forward declarations etc.
Without modules:
gradle dependencies
For Android:
gradle app:dependencies
Using gradle wrapper:
./gradlew app:dependencies
Note: Replace app with the project module name.
Additionally, if you want to check if something is compile vs. testCompile vs androidTestCompile dependency as well as what is pulling it in:
./gradlew :app:dependencyInsight --configuration compile --dependency <name>
./gradlew :app:dependencyInsight --configuration testCompile --dependency <name>
./gradlew :app:dependencyInsight --configuration androidTestCompile --dependency <name>
You can render the dependency tree with the command gradle dependencies. For more information check the section Listing dependencies in a project in the online user guide.
If you find it hard to navigate console output of gradle dependencies, you can add the Project reports plugin:
apply plugin: 'project-report'
And generate a HTML report using:
$ ./gradlew htmlDependencyReport
Report can normally be found in build/reports/project/dependencies/index.html
It looks like this:
In Android Studio (at least since v2.3.3) you can run the command directly from the UI:
Click on the Gradle tab and then double click on :yourmodule -> Tasks -> android -> androidDependencies
The tree will be displayed in the Gradle Console tab
Often the complete testImplementation, implementation, and androidTestImplementation dependency graph is too much to examine together. If you merely want the implementation dependency graph you can use:
./gradlew app:dependencies --configuration implementation
Source: Listing dependencies in a project
Note: compile has been deprecated in more recent versions of Gradle and in more recent versions you are advised to shift all of your compile dependencies to implementation. Please see this answer here
If you want to visualize your dependencies in a graph you can use gradle-dependency-graph-generator plugin.
Generally the output of this plugin can be found in build/reports/dependency-graph directory and it contains three files (.dot|.png|.svg) if you are using the 0.5.0 version of the plugin.
Example of dependences graph in a real app (Chess Clock):
For me, it was simply one command
in build.gradle add plugin
apply plugin: 'project-report'
and then go to cmd and run following command
./gradlew htmlDependencyReport
This gives me an HTML report WOW Html report 💕
Or if you want the report in a text file, to make search easy use following command
gradlew dependencyReport
That's all my lord.
Things have moved forward in Gradle so I believe this question merits another answer.
Since Gradle 4.3, "build scans" were introduced. All relevant info is available in the Gradle docs (1, 2). For me, this seems to now be the easiest way to check your dependencies (and generally your build) in a clear, organized way.
They are very easy to create, just execute:
gradle build --scan
(or ./gradlew build --scan if you use a wrapper)
This produces a randomly generated link where you can see your scan. When opening that link, you enter your email and gain full control of the link: eg. share it or delete it. It has got a lot of info about your build, not just dependencies. You can see your dependencies, their hierarchies, the repository used to obtain them but also a lot of other stuff about your build, namely, its performance (which is of interest in big complex builds), your tests, even your console output and your system configuration, which JDK and JVM was used, max heap size etc.
This is a printscreen from a mock project:
A build scan is a shareable record of a build that provides insights into what happened and why. You can create a build scan at scans.gradle.com for free.
Note however, that info for your build process will be sent to the Gradle servers. You have full control to delete it when you are finished with your inspection.
Finally, you can use build scans with Gradle versions earlier than 4.3 too, you just have to manually add the scans plugin in your buildscript.
Edit:
Incorporating some feedback from the comments some extra notes:
1) It is very difficult to do this by mistake or without understanding that some info for your build will be online (private to you, with the ability to delete it, but still online).
When executing gradle build --scan the following message appears:
Publishing a build scan to scans.gradle.com requires accepting the Gradle
Terms of Service defined at https://gradle.com/terms-of-service. Do you
accept these terms? [yes, no]
You have to explicitly write yes and then the message continues:
Publishing build scan...
https://gradle.com/s/a12en0dasdu
2) In Gradle Enterprise you can host gradle build scans in your own servers. However I have no experience in this and my proposed approach was about the standard Gradle distribution, using Gradle's servers for your build scans.
3) Gradle itself promotes the build scans as the way to deal with most your build problems.
For Android, type this in terminal
gradlew app:dependencies
It will list all the dependencies and the ones with newer versions for you to upgrade like
com.android.support:customtabs:26.1.0 -> 27.1.1 (*)
For recent versions of Gradle (I tested with the 6.4.1 version):
gradle dependencies --configuration compileClasspath
or if you're using the Gradle Wrapper:
gradlew dependencies --configuration compileClasspath
When building for Android with the 'debug' and 'release' compilation profiles, the debugCompileClasspath and releaseCompileClasspath configurations can be used instead of compileClasspath.
I also found useful to run this:
./gradlew dI --dependency <your library>
This shows how are being dependencies resolved (dependencyInsight) and help you debugging into where do you need to force or exclude libraries in your build.gradle
See: https://docs.gradle.org/current/userguide/tutorial_gradle_command_line.html
In Android Studio
1) Open terminal and ensure you are at project's root folder.
2) Run ./gradlew app:dependencies (if not using gradle wrapper, try gradle app:dependencies)
Note that running ./gradle dependencies will only give you dependency tree of project's root folder, so mentioning app in above manner, i.e. ./gradlew app:dependencies is important.
Note that you may need to do something like ./gradlew <module_directory>:<module_name>:dependencies if the module has extra directory before reach its build.gradle. When in doubt, do ./gradlew tasks --all to check the name.
If you want all the dependencies in a single file at the end within two steps.
Add this to your build.gradle.kts in the root of your project:
project.rootProject.allprojects {
apply(plugin="project-report")
this.task("allDependencies", DependencyReportTask::class) {
evaluationDependsOnChildren()
this.setRenderer(AsciiDependencyReportRenderer())
}
}
Then apply:
./gradlew allDependencies | grep '\-\-\-' | grep -Po '\w+.*$' | awk -F ' ' '{ print $1 }' | sort | grep -v '\{' | grep -v '\[' | uniq | grep '.\+:.\+:.\+'
This will give you all the dependencies in your project and sub-projects along with all the 3rd party dependencies.
If you want to get this done in a programmatic way, then you'll need a custom renderer of the dependencies - you can start by extending the AsciiDependencyReportRenderer that prints an ascii graph of the dependencies by default.
double click and run dependency under help in gradle view
Try either this
./gradlew dependencies > ~/dependencies.txt
or
gradle dependencies > ~/dependencies.txt`
which should write the dependencies in text file under user's home directory.
I am learning to use git and gradle to build Spring 3.2 on my local system.
I cloned the git repo and used the gradlew command to start the build like so:
gradlew build
I also have the GRADLE_HOME set up and added GRADLE_HOME/bin to my PATH variable.
Every time I start up the build I see a .gradle directory being created in my directory C:\Users\Ayusman and it seems to download gradle binaries.
My questions:
Since I already have gradle installed on my system; why does it have to download gradle?
Can I force gradle to put my dependencies in a specific directory instead of the users folder (like I can specify in maven)?
Can gradle be pointed to pull from a local repo instead of internet?
ad 1. In order to build with your locally installed Gradle, you have to invoke gradle rather than gradlew. The purpose of gradlew (called the Gradle Wrapper) is for everybody to use the same Gradle version and not having to install Gradle manually.
ad 2. To change where Gradle puts dependencies (and other global information), you can set the GRADLE_USER_HOME environment variable.
ad 3. You just need to add another repository declaration to build.gradle. Something like:
allprojects {
repositories {
maven {
url "http://..."
}
}
}
If you want to use this repository for all your builds, you can put the same declaration into ~/.gradle/init.gradle.
Because gradlew invokes the gradle wrapper, which downloads the version of gradle that the build script has been written for, instead of using your version, which might not be compatible. It does that only once, and then reuses the downloaed version. If you want to use your version of gradle, use the gradle command rather than gradlew, but it might not work if you don't have the appropriate version.
AFAIK, this is done by defining the GRADLE_USER_HOME environment variable.
See http://www.gradle.org/docs/current/userguide/userguide_single.html#sec:repositories