I would like to build the play framework with Gradle in a multiproject build.
The play application would be one of my gradle subprojects. The controllers in play, will call methods in my other gradle projects.
Gradle uses sbt by default. Should I just use sbt command line calls in the gradle build file? And if I do that, would I be able to package it as an application (e.g. a jar file)?
Native support for play is currently in the works for Gradle. This is still in development, but you can take a look at some sample projects in the samples/play directory of the 'all' distribution of Gradle 2.3.
Related
The documentation at https://docs.wildfly.org/bootablejar/ describes the usage of the maven plugin wildfly-jar-maven-plugin only. Is there a way to build something similar with gradle? What comes close is the hollow bootable jar: build it with maven and use it as a dependency in my gradle project to start my war.
I am really confused about how gradle works with android subproject and simple server-java subproject tied to Project.
Android is using not the latest version of gradle, but my server app can use it.
Should I use the minimum version that supports all modules, or can I somehow edit the build file for each module?
I found gradle tasks shown below in my Eclipse Java Spring project:
application
bootRun
build
assemble
bootBuildImage
...
build setup
documentation
help
ide
verification
What these tasks are coming from? Is it part of Gradle or Spring?
(1) You ask
What these tasks are coming from?
Gradle task come from 2 area: by Gradle itself and by Gradle plug-ins.
For example, at folder where has file build.gradle , (1a) when you run command
gradle bootRun
Spring Boot application when run, it usually run and return result at http://localhost:8080 (default). gradle bootRun run success by an plugin called Spring-boot-gradle-plugin declared inside build.gradle .
(1b) When you run
gradle wrapper
your project will add some folder and files, make your source code become portable, no need install Gradle at local PC when you share for your colleagues. gradle wrapper come from Gradle itself, not from third-party one.
(2) You ask
Is it part of Gradle or Spring?
(1b) from Gradle itself, (1a) is a plug-in made by Spring team.
Reference: https://github.com/spring-projects/spring-boot/tree/master/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin
They look to be gradle as assemble, build, buildDependencies are all standard irrespective of what you are building.
I'm learning how to use gradle to build my java applications. Currently I'm using eclipse with buildship plugin. I have it building my JARs and WARs, and also have gradle running my JUnit and Selenium tests. I like that it pulls in the dependencies I need as I need them during development.
It seems like it would make sense if my build.gradle files define my dependencies to build and run my application in dev then I should be able to use them for deployment. Otherwise I have to retrieve all my dependencies by some other means and deploy to my production environment, and managing 2 different methods of retrieving and deploying dependencies seems to be a risk for problems.
Can I use gradle or at least my build.gradle files in some way for my deployment?
Take a look at the gradle distribution plugin. This plugin adds tasks to create an "install folder" or an archive file (zip or tar) containing all the dependencies you'll need to execute/deploy your application.
Gradle application plugin also generates shell/bat scripts to invoke your application.
I'm developing an java application. I'm using eclipse Luna and Gradle as my build-system. I can define dependencies in my build script and they get downloaded on a build. That's no problem... But how can I tell eclipse, that it should automatically download and add the dependency to my build path?
I wan't to use auto completion and so on, without manually downloading an jar and copy it to the project.
Is it possible?
Regards
Marc
You need the Eclipse Gradle tooling, which adds lots of Gradle-related functionality. Most importantly, it manages your Eclipse project build path to match the build.gradle dependencies.