I was asked a very awesome question from someone starting to use gradle and I realize it would be extremely cool and probably already exists.
When we go to override a task like jar, many times you want to actually see the original gradle code that is used for the jar task or compileJava task. Does such a thing exist? (or did they end up writing that stuff in java). If that does exist, please give us a link? and it would be awesome to wire into the command line or documentation online(or maybe it is wired in somewhere and I missed it as the documentation online is one huge book, which is great, don't get me wrong.).
thanks,
Dean
The code is on github, as detailed on the web site, so you can easily check it out and grep for specific implementations.
For example this is the code for the Jar task.
The Gradle build language you use in your scripts is a DSL implemented in Groovy and Java. The language reference is a useful resource for mapping between the stuff you write in your project and the API docs for the underlying code.
Related
I have a question on the usage of plugins in gradle in general. What features do they provide?
For example, why should I use an Idea plugin if my IDE is intelliJ. What if I don't use that will there be any difference.
If you want to know about Gradle plugins in general, you should read the relevant part of the user guide. It does a good job of explaining the concept.
As for the IntelliJ plugin in particular: no you should generally not add it. IntelliJ can import Gradle projects just fine without it. The only time it makes sense to add it is if you need to customize the import process in a way that differs from the default. But even that is often better done through adding the specific IntelliJ configuration files to your VCS repository. If you like to know more about best practices for this, the Gradle forums are a better match for discussing the different approaches.
So I have been struggling all afternoon with getting some Gradle build to work for a Kotlin multiplatform project that involves an ANTLR grammar. What I'm trying to do is to have a parser generated by ANTLR from a shared grammar for both a Kotlin (or Java if that doesn't work) and JavaScript target. Based on this I'd like to write some library around the parser that can be used from the JVM and JavaScript.
So I have set up a Kotlin multi-platform project because that seemed like a nice way of killing two birds with one stone (here is a repo https://github.com/derkork/project.txt). I created a source set commonAntlr where I placed the grammar file under commonAntlr/antlr/project_txt.g4. According to the documentation of the ANTLR plugin this is how stuff should be set up. I also apply the antlr plugin at the top (here is the build.gradle.kts - https://github.com/derkork/project.txt/blob/master/build.gradle.kts).
Now I run gradle build in the hopes that the ANTLR plugin will at least try to generate some nice Java code for me from the grammar using the default settings. Alas, it does not. The ANTLR plugin does not even get started, which is what I can tell from the output. The build later fails with some obscure JavaScript problem, but that looks unrelated and I'd like to skip over it for now.
Now my Gradle-foo isn't exactly strong (I have only used it in extremely simple projects, most of my experience is in Maven), and I have the distinct feeling I'm missing something here. However the documentation of the plugin just says
To use the ANTLR plugin, include the following in your build script:
plugins {
antlr
}
Which I did. Since I get zero output, I have a feeling that I need to do a bit more for this to work. I have read a lot of the Gradle documentation up and down to find out how plugins work in general and I found that they add tasks to the build and also add some dependencies so that tasks are invoked when you try to build certain things. However I don't really understand how plugins work together with source sets and how you can tell Gradle "would you please run the generateGrammarSource task for this source set" (or if it even works like this).
So if some of the Gradle gods could enlighten me on this, this would be much appreciated :)
I have met a similar issue: https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin/tree/feature/parser
My solution -- which is still a work in progress -- consists in decomposing the problem.
I reasonable solution in my opinion is to create a Kotlin/JVM project (say parser-jvm) where to put the generated Java code + any JVM specific facility, and a Kotlin/JS project where to put the generated JS code + any JS specific facility (say parser-js). The next step is to create a Kotlin/MPP (say parser-common) project whose JVM implementation depends on parser-jvm and whose JS implementation depends on parser-js.
My approach is actually working for JVM while I'm experiencing some issues for JS, which are mostly caused by this issue.
The main drawback of this approach is that some Gradle coding is required to setup ANTLR with Kotlin/JS. I already faced this problem in my build.gradle and I'm quite satisfied with the result and the overall architecture of the project. However, I believe that my proposal is far less troublesome than configuring a Kotlin/MPP project to work with ANTLR.
So, I've been trying to avoid build tools for a while, but started to use Gradle for some time now. I'm able to use it for simple things like letting it download dependencies, like it's intended, but I've seen people use it to do really advanced staff like manage large projects with different modules, native dependencies, publish to Github when building, etc.
I feel like I still need to copy-paste a lot when trying to do anything more complicated, because even after finding some documentation to read, I'm still not sure where language syntax like {, }, :, (, ), are meant to be used.
So, my question is: Does it make sense to learn Groovy to understand Gradle better? Should reading the docs be enough? I'm not even asking because I would not be interested in Groovy, I'm just wondering how people got used to using Gradle and whether it makes sense to use it for more advanced tasks then fetching dependencies from repositories.
Gradle uses DSL (domain specific language) that is currently based on top of Groovy. That means, that you should be able to work with Gradle to some extend by learning the DSL only. It, of course, inherits some of the syntax from Groovy (like the parentheses etc) but the syntax pretty far away from a normal Groovy code.
If you want to start writing your own closures, tasks and plugins then you need some Groovy skills, yes. Groovy in Action 2nd edition is a great book, or if you are a Java developer, take a look at Making Java Groovy.
Saying that, please keep in mind that Gradle Inc announced that they are going to support Kotlin as another language to base the DSL on. It means that you will be able to write the "custom" parts of your build in Kotlin or Groovy. So, keep an eye on Kotlin as well, here's the best way to do it – Kotlin in Action.
To just use Gradle, you can go without understanding Groovy.
To understand how a Gradle file syntax works, you definitely need to understand Groovy. People generally struggle with Gradle when scripts become complex.
Gradle uses mostly vanilla Groovy as it's language, but the documentation and most examples use a specific style, that is different from the most conventional style when writing other Groovy code.
But except for a single compiler plugin (for turning some names without quotes into strings), all Gradle code is also valid Groovy code, and you could write any gradle file in the same style as you write any other Groovy file.
I am pretty new to Java and Maven and today was studying about maven, how to Mavenize a java app, how to make it good for EClipse, etc... so now I have a question: when we want to write a Java and we know that we want to use Maven too, then we start writing application and creating out directory structure with the layout that Maven likes it? or we just write our app and at the end we mavenize it? Where do we start from when we want to create a java app from beginning and we want it to be mavenized too.
Use Maven from the beginning. Why write in a different structure and convert it again at the end, while you can do it in correct way from start? If you don't use Maven from the start, what build tools you will use then? Ant? I don't see any gain in productivity in such approach.
As Adrian said, you should definitely use Maven since the beggining.
One of its main value is to guide you on "the right way". I should say "The right Maven way". It's sometimes very restrictive, but it's the main advantage : if you do like Maven is waiting for, you are probably on the way that every community or big project do.
If you start your project "by yourself", you may forgot or miss something that will trouble you. For instance, main java sources are expected to be in src/main/java. Most of the plugin use the variable sourceDirectory to bind it ... but you may have to redefine this variable many times for plugins.
Another instance, and quite often confusing, is the multi module project. If you have 2 or more project that are binded (in their life cycle), you should set up a multi module project. If you don't, you will face of code or action duplication (2 tags, 2 build, 2 deployement, etc...).
So, in order to give you a straight answer :
read http://www.sonatype.com/books/mvnref-book/reference/
use the more appropriate archetype to build your project
if you create it under command line (not with an IDE), import it
then work :)
What I'm saying will appear you more and more clear using Maven :).
See Why does Maven have such a bad rep? to better understand why :)
What happened to the Maven Polyglot project that used to be at http://polyglot.sonatype.org/?
As described in this article,
One exciting new feature in Maven 3 is it's ability to work with pom files written in non-XML notations. The Maven core now provides an underlying DSL to access the Maven internals, and write POM files in the language of your choice. This currently includes scripting languages like Groovy, Ruby, and others. In short, you will be able to write a DSL for virtually any scripting language you like that can hook into the Maven internals and pilot the Maven build process.
There are several additional articles on the web that I've found referencing the feature.
http://www.thinkplexx.com/learn/article/maven-learn-material/maven3/maven3-pom-using-groovy-ruby-scala-yaml-sonatype-polyglot
http://mattgivney.blogspot.com/2011/05/maven-3-polyglot-support.html
But the polyglot site now redirects to sonatype.org and I can find no mention of this feature in the Maven 3 release notes.
So what happened? Was it cut or is it in there and just not documented in the release notes? If it did make the cut for Maven 3 could you point to some documentation. I am also interested in the translator tool mentioned by the first article I linked to.
This project is now named tesla-polyglot. I've just completed the Scala DSL for it, and tesla-polyglot should be released very soon now. We're just waiting on Maven 3.1.1 to roll out of the door.
There has been an update on the maven users list from Jason van Zyl: http://maven.40175.n5.nabble.com/What-happened-to-Polyglot-Maven-td5715529.html
I'm still working on it along with a few others. Dhanji has the Atom markup working, Kristian has implemented a Ruby DSL, and Jason Dillon has implemented a Groovy DSL which creates synthetic plugins to bind arbitrary scripting to Maven's lifecycle. My original was to see how Maven's infrastructure could be leveraged by other markups and DSLs. These examples do render to an interoperable format insofar as consumers go. Maven itself obviously cannot run a Ruby DSL but if you like the Ruby DSL you can use it to build an not affect consumers: you can build and deploy to a Maven repository and someone else can consume the dependency with stock Maven.
I have all the early adopters I can deal with one-on-one right now, because I can't deal with many really, but if you have more than a passing interest feel free to email me privately.
looks like it is still alive :-)
You won't believe it, but it's released (if you can call a 0.1 version a release).
As of April 2016,
the home page is https://github.com/takari/polyglot-maven ,
the latest release is 0.1.15
There is Polyglot Maven IDE Pack for Eclipse, that includes some plugins.
There is also maven-tiles project https://github.com/repaint-io/maven-tiles ,
and quick trying out what Maven flavor works well shows that Groovy does better than others.
Be aware of Babylon Tower problem, so it is actually better when most of developers use the same flavor.
The latest info comes from here
"Polyglot for Maven is still moving along and we've seen a lot of activity recently on the Ruby DSL by Cristian Meier from the JRuby team, and the Scala DSL by Chris Hunt from Typesafe. We hope that this initial work can serve as inspiration for helping the POM evolve. For those interested in what the XML alternatives can look like you can take a look at the existing implementations:
Ruby DSL
Groovy DSL
Scala DSL
YAML
Atom"