Setup gradle build #140

Merged
merged 14 commits into from May 4, 2016

Projects

None yet

4 participants

@aalmiray
Contributor
aalmiray commented Apr 28, 2016 edited

The gradle build provides the same behavior as the Maven build, plus:

  • attach LICENSE file to JARs
  • generate javadoc jar
  • additional build metadata in JAR manifest
  • aggregate JaCoCo coverage report
  • Bintray publishing

It also paves the way to integrate the fork of OpenDolphin


This change is Reviewable

@coveralls

Coverage Status

Coverage remained the same at 24.159% when pulling 2ce5f56 on gradle-build into f659aaf on master.

@blackdrag

Reviewed 36 of 43 files at r1.
Review status: 34 of 41 files reviewed at latest revision, 2 unresolved discussions.


gradle.properties, line 3 [r1] (raw file):
do we really compile one part for 1.7 and another for 1.8?


settings.gradle, line 16 [r1] (raw file):
are you doing this because of the naming of the jars?


Comments from Reviewable

@aalmiray
Contributor

Review status: 34 of 41 files reviewed at latest revision, 2 unresolved discussions.


gradle.properties, line 3 [r1] (raw file):
yes. The majority of the code has to be compiled with JDK7 compatibility. Only the client code can be JDK8 (JavaFX)


settings.gradle, line 16 [r1] (raw file):
this was doe by invoking gradle init on the original maven setup. I prefer a different a different convention but that would have forced the move of all source code


Comments from Reviewable

@blackdrag

Reviewed 1 of 43 files at r1.
Review status: 35 of 55 files reviewed at latest revision, all discussions resolved, some commit checks failed.


Comments from Reviewable

@blackdrag

Reviewed 6 of 43 files at r1, 14 of 14 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.


Comments from Reviewable

@hendrikebbers hendrikebbers added this to the 0.8.5 milestone May 2, 2016
@hendrikebbers
Member

We should merge this request once 0.8.4 is released and directly after this request we should add the OD sources.

@blackdrag

Reviewed 7 of 7 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.


Comments from Reviewable

aalmiray added some commits Apr 28, 2016
@aalmiray aalmiray Setup gradle build 6901aba
@aalmiray aalmiray Attach license file to JARs 42162bd
@aalmiray aalmiray Remove pom files 8a7226b
@aalmiray aalmiray Update travis settings eadbd3a
@aalmiray aalmiray Update license headers and license configuration ba9332a
@aalmiray aalmiray Aggregate all JaCoCo reports 999bef4
@aalmiray aalmiray Delete pom files 63435f3
@aalmiray aalmiray Update server settings
deb3cf4
@aalmiray aalmiray Fix build brackage
a665793
@aalmiray aalmiray Check if JFX exists on CI
0bdb1a8
@aalmiray aalmiray Force install of latest OracleJDK8 on Travis (we need 8u40 as a minimum)
b214bb2
@coveralls

Coverage Status

Changes Unknown when pulling b214bb2 on gradle-build into * on master*.

@hendrikebbers
Member

the server-kumuluzee module in the sample has no gradle files

@blackdrag

Reviewed 7 of 11 files at r5.
Review status: 59 of 63 files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

@hendrikebbers
Member

yes... I checked out the branch to test it and this file is not on my disc...


Review status: 59 of 63 files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

@hendrikebbers
Member

I think it's a git problem at my local machine


Review status: 59 of 63 files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
build.gradle
+/*
+ configurations.all {
+ resolutionStrategy.force "org.slf4j:slf4j-api:$slf4jVersion",
+ "org.slf4j:jcl-over-slf4j:$slf4jVersion",
+ 'org.aspectj:aspectjweaver:1.8.8',
+ "org.springframework:spring-aop:$springVersion",
+ "org.springframework:spring-beans:$springVersion",
+ "org.springframework:spring-core:$springVersion",
+ "org.springframework:spring-context:$springVersion",
+ "org.springframework:spring-jdbc:$springVersion",
+ "org.springframework:spring-orm:$springVersion",
+ "org.springframework:spring-tx:$springVersion"
+
+ resolutionStrategy.failOnVersionConflict()
+ }
+*/
@hendrikebbers
hendrikebbers May 4, 2016 Member

Can this be removed?

@aalmiray
aalmiray May 4, 2016 Contributor

Not really. This code is currently commented out until we figure out which versions must be used. Jochen knows the history of this code; it's used to assert dependency convergence

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
build.gradle
@@ -0,0 +1,172 @@
+import java.text.SimpleDateFormat
+
+buildscript {
+ repositories {
+ jcenter()
+ }
+
+ dependencies {
+ classpath 'org.kt3k.gradle.plugin:coveralls-gradle-plugin:2.6.3'
+ classpath 'nl.javadude.gradle.plugins:license-gradle-plugin:0.11.0'
@hendrikebbers
hendrikebbers May 4, 2016 Member

We still have the license-header.txt file in the root folder? Does this plugin use this file?

@hendrikebbers
hendrikebbers May 4, 2016 Member

Ok, found it :)

@aalmiray
aalmiray May 4, 2016 Contributor

no, it does not. license-header.txt can be removed

@hendrikebbers
hendrikebbers May 4, 2016 Member

I think code-quality.grade still uses the license-header.txt
Can we move it into the gradle folder in that case?

@aalmiray
aalmiray May 4, 2016 Contributor

yup, just did with the latest commit

@hendrikebbers
Member

I think we can remove the "release" folder in the root with this pull request, right?

@hendrikebbers
Member

Sorry, looks like reviewable is currently not working for me. Need to do the review directly in github

@hendrikebbers hendrikebbers and 1 other commented on an outdated diff May 4, 2016
todo-example/server-javaee/build.gradle
@@ -0,0 +1,11 @@
+apply plugin: 'jetty'
+
+dependencies {
+ compile project(':todo-example-server')
+ compile project(':dolphin-platform-server-javaee')
+ compileOnly 'javax:javaee-api:6.0'
+}
+
+jettyRunWar {
+ contextPath = 'todo-app'
@hendrikebbers
hendrikebbers May 4, 2016 Member

I don't think that this will work since Jetty don't support CDI, right? The project must be deployed on a JavaEE 6 / 7 container like JBOSS

@aalmiray
aalmiray May 4, 2016 Contributor

OK. The jetty plugin also applies war. I can change the build so that it only applies the war plugin for now.

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
build.gradle
+ toolVersion = jacocoVersion
+}
+
+subprojects { subprj ->
+ apply plugin: 'java'
+ apply plugin: 'org.kordamp.gradle.stats'
+ apply from: rootProject.file('gradle/code-quality.gradle')
+
+ subprj.tasks.withType(JavaCompile) {
+ sourceCompatibility = subprj.sourceCompatibility
+ targetCompatibility = subprj.targetCompatibility
+ }
+
+ repositories {
+ mavenLocal()
+ jcenter()
@hendrikebbers
hendrikebbers May 4, 2016 Member

For the Maven release we created a Canoo group at Bintray and deployed all released to bintray. With the new build we will loose the binary information, right? If yes, that's not a problem :) I just want to know it

@aalmiray
aalmiray May 4, 2016 Contributor

No, we don't loose it 😄

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
build.gradle
+ test.useTestNG()
+ }
+}
+
+evaluationDependsOnChildren()
+
+/*
+subprojects {
+ configurations {
+ all*.exclude group: 'commons-lang', module: 'commons-lang'
+ all*.exclude group: 'ch.qos.logback', module: 'logback-classic'
+ all*.exclude group: 'commons-logging', module: 'commons-logging'
+ all*.exclude group: 'org.slf4j', module: 'log4j-over-slf4j'
+ }
+}
+*/
@hendrikebbers
hendrikebbers May 4, 2016 Member

Can this be removed?

@aalmiray
aalmiray May 4, 2016 Contributor

Not yet, we have a mess of logging frameworks. We must make sure everything is routed through Slf4j. This code will be important once the remoting layer is added to the build

@hendrikebbers hendrikebbers and 1 other commented on an outdated diff May 4, 2016
gradle/javafx.gradle
@@ -0,0 +1,15 @@
+ext.jfxrtLocation = new File("${System.properties['java.home']}/jre/lib/jfxrt.jar").absolutePath
+
+for (location in ['lib/jfxrt.jar', 'jre/lib/jfxrt.jar', 'jre/lib/ext/jfxrt.jar']) {
+ File javaHome = new File(System.properties['java.home'])
+ javaHome = javaHome.name == 'jre' ? javaHome.parentFile : javaHome
+ File file = new File(javaHome, location)
+ if (file.exists()) {
+ ext.jfxrtLocation = file.absolutePath
+ break
+ }
+}
+
+println('#' * 80)
+println(jfxrtLocation + ' exists? ' + new File(jfxrtLocation).exists())
+println('#' * 80)
@hendrikebbers
hendrikebbers May 4, 2016 Member

I have 2 JFX dependencies now in IntelliJ: 1 that comes with the regular Java dependency and a second one that is defined as "jfxrt" Gradle dependendency. I think this is based on this skript. Since the JavaFX client module depends on Java 8 you will always have JFX as a dependency by default. Can't we remove this script in that case?

@aalmiray
aalmiray May 4, 2016 Contributor

I think it's possible to remove this file. let me check again

@hendrikebbers hendrikebbers commented on an outdated diff May 4, 2016
gradle/publishing.gradle
+ url project.project_website
+ inceptionYear '2015'
+ licenses {
+ license([:]) {
+ name 'The Apache Software License, Version 2.0'
+ url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
+ distribution 'repo'
+ }
+ }
+ scm {
+ url project.project_scm
+ }
+ developers {
+ [
+ 'Hendrik Ebbers': 'hendrik.ebbers@canoo.com',
+ 'Michael Heinrichs': 'michael.heinrichs@canoo.com'
@hendrikebbers
hendrikebbers May 4, 2016 Member

Andres is missing

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
gradle/publishing.gradle
+ 'Build-Revision': versioning.info.commit,
+ 'Specification-Title': project.name,
+ 'Specification-Version': project.version,
+ 'Implementation-Title': project.name,
+ 'Implementation-Version': project.version,
+ )
+ }
+ metaInf {
+ from(rootProject.files('.')) {
+ include 'LICENSE'
+ }
+ }
+}
+
+if (!project.hasProperty('bintrayUsername')) ext.bintrayUsername = ''
+if (!project.hasProperty('bintrayApiKey')) ext.bintrayApiKey = ''
@hendrikebbers
hendrikebbers May 4, 2016 Member

We need a readme that describes how to build / test / deploy the project. This is not needed for this pull request but should be done in near future.

@aalmiray
aalmiray May 4, 2016 Contributor

👍

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
todo-example/server-kumuluzee/build.gradle
@@ -0,0 +1,12 @@
+apply plugin: 'application'
+
+mainClassName = 'com.canoo.dolphin.todo.server.ServerStart'
@hendrikebbers
hendrikebbers May 4, 2016 Member

Question: The default Java version is defined as 7 but we maybe need 8 to run this sample. Can this be configured?

@aalmiray
aalmiray May 4, 2016 Contributor

Yes. I'll add it to the gradle.properties file belonging to this module

@hendrikebbers
hendrikebbers May 4, 2016 Member

Ok, will check it agains once you did the change. Currently I can't start any server / client in IntelliJ

@hendrikebbers hendrikebbers commented on the diff May 4, 2016
todo-example/server-spring/build.gradle
@@ -0,0 +1,8 @@
+apply plugin: 'application'
+
+mainClassName = 'com.canoo.dolphin.todo.server.ToDoServer'
@hendrikebbers
hendrikebbers May 4, 2016 Member

Question: The default Java version is defined as 7 but we maybe need 8 to run this sample. Can this be configured?

@hendrikebbers
hendrikebbers May 4, 2016 Member

I can't start the serve in IntelliJ:

Error:(84, 41) java: multi-catch statement is not supported in -source 1.6
(use -source 7 or higher to enable multi-catch statement)

In IntelliJ the project settings contains "SDK default (8)" as language level.

@hendrikebbers
Member

When building the documentation there is a placeholder at the bottom of the space that isn't replaced:

Version {revision-number}

@aalmiray aalmiray Update according to reviews
e403c98
@coveralls

Coverage Status

Changes Unknown when pulling e403c98 on gradle-build into * on master*.

@aalmiray aalmiray change the name of the todo javaee war
c1b45c0
@coveralls

Coverage Status

Changes Unknown when pulling c1b45c0 on gradle-build into * on master*.

@hendrikebbers hendrikebbers Licence headers
4c91758
@hendrikebbers hendrikebbers merged commit 40a8819 into master May 4, 2016

0 of 3 checks passed

code-review/reviewable Review in progress: 52 of 71 files reviewed, 10 unresolved discussions
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
@aalmiray aalmiray removed the in progress label May 4, 2016
@coveralls

Coverage Status

Changes Unknown when pulling 4c91758 on gradle-build into * on master*.

@aalmiray aalmiray deleted the gradle-build branch May 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment