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.
We need to publish the jars to Maven central, see http://central.sonatype.org/pages/gradle.html
Additionally we have
Some minor things:
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:
Finally we are able to merge the PR.
- 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 :)
Most helpful comment
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