Andrey Hihlovskiy

Professional blog on groovy, gradle, Java, Javascript and other stuff.

Tag Archives: gradle

Gretty Plugin 0.0.5 is out

Gretty Plugin 0.0.5 is out and soon will be in maven central.

Gretty Plugin home: https://github.com/akhikhl/gretty

Advertisements

Gretty Plugin is now on Maven Central

I published Gretty Plugin to maven central, coordinates: org.akhikhl.gretty:gretty-plugin:0.0.4.
Project home: https://github.com/akhikhl/gretty
scm: https://github.com/akhikhl/gretty.git, git@github.com:akhikhl/gretty.git

Gretty Plugin is actually gradle plugin for running web-applications under jetty 8.1.8 and servlet API 3.0.1.

Memory leaks in GradleDaemon?

Just observation: GradleDaemon eats tremendous amout of operating memory (1.5 to 2 GB) after 2 hour uptime and repeated compilation of a large project set (approx. 200 gradle projects). I’m just wondering if it a sign of memory leaks.

gradle snippet: sources and javadoc jar for every subproject of given project

gradle snippet: sources and javadoc jar for every subproject of given project

Add this to the parent “build.gradle” to enable xyz-sources.jar and xyz-javadoc.jar generation for every java and groovy subproject of the given parent project. The script tolerates non-java subprojects.

Meet Gretty: advanced gradle plugin for running web-applications under Jetty and Tomcat

I created little gradle plugin for running web-applications under Jetty 8.1.8.

The main advantage for a programmer is that now it’s possible to use servlet-api 3.0 and higher (under standard gradle-jetty plugin it was not possible, because jetty was too old).

Full sources, documentation and examples here:

https://github.com/akhikhl/gretty

Update 24.02.2014:

Now gretty supports jetty 7, 8 and 9 and servlet API 2.5, 3.0.1 and 3.1.0, as well as it brings many new interesting features!

Update 07.10.2014

Now Gretty supports Tomcat 7 and 8, as well as SpringBoot, spring-reloaded and jacoco!

Gradle script: multiproject git-gradle management

Suppose you build your software project from many open-source components, most of which are already available via git. How to automate clone/pull/build/install cycle, especially across projects from different git-repositories? How to establish high-level inter-project dependencies?

For that I wrote gradle script, which implements multiproject git-gradle management. It works as follows: you write configuration file, name it “config.gradle”, put it to the same folder as “build.gradle” (of multiproject git-gradle) and then run “gradle build”.

Full documentation and sources are available at:

https://github.com/akhikhl/multiproject-git-gradle

Automated git-pull

Suppose you have 20 git-repositories, which you actively pull and push from/to central location (e.g. github). Don’t you think pulling them by hand is too mechanical? And what if you forget to pull some?

I wrote little gradle script capable of automated git-pull:

You drink morning coffee and the machine does the job for you.

Credits come to the creators of excellent gradle-git plugin:

https://github.com/ajoberstar/gradle-git

Script for batch installation of maven artifacts

I created gradle script that delivers batch installation of maven artifacts to local maven repository (source code here: https://github.com/akhikhl/contribs).

The script supports two tasks – installContribs and cleanContribs – but can be extended with additional tasks (for example, implementing deployment to corporate repo).

how it works:

1. you call it with the command-line:

gradle -b contribs.gradle

(or you rename script to “build.gradle” and just put it somewhere in the multi-project tree, it will be called by gradle automatically).

2. installContribs task iterates the current folder (where the script resides) and all it’s subfolders

3. in each folder it iterates files with extension “pom”

4. for each found pom-file it looks for “.jar”, “-sources.jar” and “-javadoc.jar” and install all found files (together with pom) to the local maven repository.

5. pom-file without jars will be installed as an artifact on it’s own. Typical use-case: installation of parent-poms and aggregator-poms.

The script accurately calculates inputs/outputs. If all files were not changed since the last installation, it does not install anything and shows “UP-TO-DATE” in the console.

cleanContribs task makes script “forget” about the time of the last artifact installation. As the result, running script with installContribs task will install all artifacts anew.

Script for mass checksum (MD5 and SHA1) calculation in the file system.

I developed little gradle script, that delivers mass checksum (MD5 and SHA1) calculation for files in the specified folder (recursive to subfolders):

https://github.com/akhikhl/checksums

At the beginning that was more like exercise in using gradle for non-compilation tasks and in integrating apache-commons into gradle script.

Now, I think, I will do more gradle than bash, because gradle scripts are: a) portable b) have access to limitless power of all java libraries.