Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle support #519

Merged
merged 3 commits into from May 23, 2020
Merged

Gradle support #519

merged 3 commits into from May 23, 2020

Conversation

stleary
Copy link
Owner

@stleary stleary commented May 22, 2020

What problem does this code solve?

  • Gradle build support for the unit tests was omitted in the merge. This PR restores it.
  • In order to init Gradle from the maven pom.xml file, a newer version of Gradle was needed (6.4).
  • Using the new Gradle version caused some JavaDoc errors.
  • Some unit tests failed using the new Gradle version. In most cases, the test assumed ordering of JSONObject items.
  • Unit tests need the same license as the source code. This was not needed previously since they belonged to different projects.

Risks
Low, no changes to existing lib functionality

Changes to the API?
No

Will this require a new release?
No

Should the documentation be updated?
NO

Does it break the unit tests?
NO

Was any code refactored in this commit?
NO

Review status
APPROVED (by me)
Comment window will be reduced to 1 day since other changes are pending

Copy link
Contributor

@johnjaylward johnjaylward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gradle build looks like it will compile to java1.7. If we want to maintain 1.6 releases, I think this can't be used for deployment.

@stleary
Copy link
Owner Author

stleary commented May 22, 2020

Agreed. The next PR will remove/modify selected unit tests so the suite can run under Java 1.6. Deployment to Maven Central can happen after this. I understand there is a substantial sentiment to update the Java version, but one of the primary goals of this project is to avoid breaking applications when new code is released.

@johnjaylward
Copy link
Contributor

I think going forward it may make sense for us to just say something like this in the README:

This library supports Java 8+ (or 9+ or whatever LTS version is+)
If you are running Java 1.6 or Java 1.7, please use {{link to last released build for supported java version}}

I personally haven't used anything but Java8+ in the last 5 years, and before that was using Java 7 for a year and I feel that I was a slow adopter, so I haven't used java1.6 or older in around 6-7 years.

I think if anyone needs to work with code that old, it may be best for them to either fork the project or just use an older release.

We can have that discussion outside of this PR, but with the new way that Oracle is maintaining LTS releases and the support for Modules in 9+, it may be time to make a choice for dropping support for older versions.

@stleary stleary merged commit 956bdfa into master May 23, 2020
This was referenced Mar 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants