Change all the things

[paulerickson]

My goal was to add a few integration tests to the standalone microservice, but I ran into some issues and basically now I've replaced Maven with Gradle, Java with Groovy, and Grails with Spring Boot.

This PR actually addresses a few issues, though:

• The Grails "web-micro" profile is just too stripped-down to be useful
  • No built-in integration test support, and even unit tests seem broken in latest version
  • Only reads .groovy files, not .java, so no possibility of using the actual source from this repo
• Spring Boot would be easier to write integration tests against, and still allows you to generate a convenient 'fat jar'
• The component dependency and standalone service are co-versioned under the same parent, as part of the same build.
• Gradle is concise, fast, and basically better in every way
• Groovy obviates most boilerplate code, while still supporting static compilation where performance is important.

There are a couple of (known) TODOs, but I thought I should open a PR for feedback before continuing, since maybe all these changes are not desired, but I wouldn't want to revert something that people find valuable either. Thoughts?

[paulerickson]

To-do:

• Fix ignored test case in RestProxyDaoImplTest
• Configure release to Nexus
• Add @StaticCompile annotation to classes
• Write integration tests
• Make servlet-api a provided dependency
• Rename project
• Update README.md

[timlevett]

probably an accident. Is it needed?

[paulerickson]

It's a weird and uncharacteristic blind spot that gradle does not have a build in 'provided' scope. Apparently everyone just defines it themselves until gradle comes around, so I updated with that change.

FYI / for reference, 'provided' means a dependency is needed for compilation, but is not meant to be packaged into the final artifact, because that artifact is expected to wind up in a container (e.g. tomcat, jetty) that already has the dependency. Compile often works just as well, but can lead to weird conflicts at runtime.

[nblair]

Now this I like, however I want to block it slightly.

At the MUM developers meeting, we talked about a few initiatives:

• Adopting Semantic Versioning. Changes like this, even though they are API compatible for downstream, are internally incompatible and should be part of a major version increment.
• Renaming the project. The json- prefix isn't really a thing, since we just pass the stream; and the -service suffix is a bit confusing. The new name voted was simply "rest-proxy". This too should be part of a major increment.
• With the major version increment, drop the @Deprecated original interface/implementation.

So, I'm going to open some issues for these tasks. We should coordinate a way to order this contribution and the others efficiently.

[nblair]

See issues #23, #24, #25, and #26.

[paulerickson]

Good call, @nblair!

Should the library be rest-proxy and the service be rest-proxy-service? Or the service called rest-proxy and the library rest-proxy-core? Or something else?

I see the '-core' convention in Maven, esp. Spring projects, although maybe this would be inconsistent - it usually seems to refer to a main submodule of an aggregator pom including other plugin submodules.

[paulerickson]

I merged up, renaming the modules to rest-proxy-core and rest-proxy-boot, and ticked up the minor version.

[timlevett]

👍

[paulerickson]

Okay, I added configuration for the release to nexus and verified by publishing the snapshot:
https://oss.sonatype.org/content/repositories/snapshots/edu/wisc/my/restproxy/

The build cranks out a well-formed pomfile, sources, test, and javadoc artifacts.

I'm going to leave it at that and merge if I get another thumb, unless there's more feedback to address.

[apetro]

\t? 😦

[paulerickson]

Fixed in c1472ee; crisis averted

[apetro]

👍