Vavr: [modules] Move the build from `Maven` to `Gradle`

Created on 15 Apr 2016  路  7Comments  路  Source: vavr-io/vavr

Maven is configuration based, isn't really meant for non-standard project structures.
Having one really complicates things as the conventions over configurations breaks down to configurations.
It's also extremely verbose and forced in non-trivial cases.

E.g. mixing Java and Scala in Gradle is as simple as

apply plugin: 'scala'

I don't know all the requirements this build should provide, let's investigate the pros and cons.

builinfrastructuride 芦non-public禄

Most helpful comment

  1. Make it releasable. Currently we use OSS Sonatype. I don't know if there is a better alternative?

You should take a look at Bintray: I think it's easier than OSS Sonatype. The artifacts are published on JCenter and synced to MavenCentral

Here's a gradle-plugin to work with Bintray: gradle-bintray-plugin

All 7 comments

We need to publish the jars to Maven central, see http://central.sonatype.org/pages/gradle.html

Additionally we have

  • a self-written code generator written in Scala that is executed before Java compile. With Maven we use the scala maven plugin but we are able to execute only scripts. With a Gradle build maybe it is possible to remove the code duplications of the Scala code generators in each Maven module.

Some minor things:

  • we check interface changes between github tags with a maven plugin
  • we check for version updates of dependencies and Maven plugins
  • ...

The code generator could simply be run before the compile (should integrate nicely with Idea).
In that case generated code shouldn't even be committed (probably solving https://github.com/javaslang/javaslang/issues/1265 also)

We need to commit them to see changes on code reviews (one line in the generator might change thousands of lines in code).

I decided to commit them once because. Users should be able to browse the actual code online.

Are you open to public contributions for migrating to Gradle?

@Conorrr yes, I would really appreciate it!

Maybe it should be done in smaller steps:

  1. Early open a PR for discussion
  2. Make a multi module Gradle project and focus on the Java build
  3. Change the .travis.yml for CI builds accordingly
  4. Add the existing Scala generator if possible
  5. Make it releasable. Currently we use OSS Sonatype. I don't know if there is a better alternative?

Finally we are able to merge the PR.

  1. Make it releasable. Currently we use OSS Sonatype. I don't know if there is a better alternative?

You should take a look at Bintray: I think it's easier than OSS Sonatype. The artifacts are published on JCenter and synced to MavenCentral

Here's a gradle-plugin to work with Bintray: gradle-bintray-plugin

Done in master (for one module). Others will _have to_ follow now :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

liviamoroianu picture liviamoroianu  路  3Comments

santiagopoli picture santiagopoli  路  6Comments

Pyeroh picture Pyeroh  路  3Comments

ashrwin picture ashrwin  路  6Comments

paplorinc picture paplorinc  路  6Comments