Migrate build system away from Ant

[michaelklishin]

Ant has taken us quite far but it's showing its age. I feel we should follow what most modern (and very likely future) JVM-based projects at Pivotal use: Gradle. We'll be able to piggyback on the existing Spring team infrastructure and have nightly snapshots published to Bintray, Spring repositories. Releases also can then easily be published to the two mentioned above plus Maven Central.

Finally, Gradle is just a nicer and more widely used tool. Good idea for making it easier to contribute.

[PatrickSauts]

The amqp-client already has a maven pom.xml file.
Gradle integration in eclipse is still not efficient even in GGTS.
Maven is still the most widely used.

My point is you might want to do both at least for dependency management for now.

What do you think ?

[michaelklishin]

Maven is fine but most Java projects at Pivotal use Gradle.

I also find Maven to be a real pain when you need to do
something non-standard, as our test tasks do. Gradle is OK in this regard.

On 10 dic 2015, at 22:16, Patrick Sauts notifications@github.com wrote:

The amqp-client already has a maven pom.xml file.
Gradle integration in eclipse is still not efficient even in GGTS.
Maven is still the most widely used.

My point is you might want to do both at least for dependency management for now.

What do you think ?

—
Reply to this email directly or view it on GitHub.

[michaelklishin]

@PatrickSauts lets put it this way: we have ant targets that shell out (start external processes). If you can help us find a suitable and sane Maven plugin for that, I'd consider Maven (after consulting with the Spring team). Maven would be a significant step in the right direction for us.

[PatrickSauts]

There is an https://maven.apache.org/plugins/maven-antrun-plugin/. I used in the past that might fulfill the need. At least at the beginning.
I'm looking into it right now.
The deployment I believe should also be handled by maven instead of a sh script, right ? Any other concerns ?

[michaelklishin]

@PatrickSauts it depends what exactly we mean by "deployment" :) I see no problem with having a shell script that uses Maven and basic *nix tools as appropriate.

Starting nodes in our test suite and standard JAR packaging/Bundlor are the hardest parts. @dumbbell may be able to suggest something else.

Just to set some expectations: this will be merged after 3.6.0 ships, and thus #114 will have to wait until 3.7. Better late than never, of course, and you can safely run a JAR from master with a released server version, the protocol has been very stable for the last 5 years.

[michaelklishin]

@PatrickSauts thank you for stepping up to help, by the way!

[PatrickSauts]

@michaelklishin My pleasure

[PatrickSauts]

@michaelklishin
I pushed some changes to my fork, can anyone validate them? Cause on my mac I can't make all the tests run, I'm getting erlang crash dumps with ant and maven, same.

The tests can be run with mvn clean test
or with ant, I kept it compatible.

I'm working on adding a few more things to the pom.xml for the jars to be standard.

And also with the right settings.xml in your ~/.m2 directory like

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
<servers>
    <server>
      <id>sonatype-nexus-staging</id>
      <username>my_login</username>
      <password>my_password</password>
    </server>
  </servers>
</settings>

you can run mvn clean deploy that would compile, run the tests, and deploy to the repository if the tests pass.

I'll also add maven version plugin, so to set a version you can run it this way
mvn versions:set -DnewVersion=<new.version> && mvn versions:commit

That's a better alternative than the release plugin.
So basically to release a new version the maven commands would be:
mvn versions:set -DnewVersion=<new.version> && mvn versions:commit && mvn clean deploy

Does this match your expectations, anything else ?
Should I add a command to generate the code before compiling ?

[michaelklishin]

@PatrickSauts can you submit a pull request for this repo and assign it to me? Now that we are (almost) done with 3.6.0 I'd be happy to look into this soon. Pull requests is the primary review tool team RabbitMQ uses. Thank you!

[PatrickSauts]

@michaelklishin I can't assign the pull request
#119

[PatrickSauts]

By the way you can also run the perf tests like this
mvn -q exec:java -Dexec.classpathScope=test -Dexec.mainClass="com.rabbitmq.examples.PerfTest"

or with arguments

mvn -q exec:java -Dexec.classpathScope=test -Dexec.mainClass="com.rabbitmq.examples.PerfTest" -Dexec.args="arg0 arg1 arg2" 

Basically any class with a main inside package com.rabbitmq.examples without the need to moving any jar around, the classpath is defined by maven.

I added a runperftestMaven.sh and stresspersisterMaven.sh inside the script folder.