Implement build system with Gradle

[eshepelyuk]

Hello @gbrail
A you mentioned in mailing list - it would be good to migrate build system to either Maven or Gradle.
I'd like to tackle the task of implementing project build with Gradle.
Although not promising that it could be really fast but if you see agree I'd like to start it now.
It also could solve Issue #168

I am also interested to know your opinion about directory structure. Can I change it to be Maven / Gradle compatible, i.e. looking like src/main/java, src/main/resources etc.

What do you think ?

[gbrail]

@eshepelyuk is working on this.

[gbrail]

Done -- thanks!

With this change, it is possible to build the product using "./gradlew".

The "ant" scripts are still around. We still use them for CI until we figure out how to get the right test coverage out of Gradle on Jenkins, although now that Gradle is in we should remove them.

[eshepelyuk]

Hello @gbrail ! Thanks for approving 1st PR about Gradle adoption.

I am planning to start working on complete migration to Gradle and removing Ant.
I am planning to create new PR for this. Also, I have a number of pending questions, some of them I've put to PR but for better tracking I will copy them here.

1. Clarifications of the purpose of ZIP archive

   About zip archive, what is the purpose of distributing it ?
   Should it be published to Maven repo as artifact ? What should be the content of that file ?
   I just see no good reasons now to copy old ant behaviour since we could just zip jars produced for publishing to maven.
   Please give me some clues about this archive purpose

2. Test Coverage

   We still use them for CI until we figure out how to get the right test coverage out of Gradle on Jenkins
   Could you describe what exactly does it mean ? If this about old Emma test coverage - I could propose to introduce usage of JaCoCo instead, that is continuation of Emma project.

3. I am planning to rebuild directory structure a little bit to be more Maven / Gradle standard oriented, i.e.

   • separate source code from resource (like JS tests, properties)
   • merge all source code into one folder
   • remove CVS trails
   • completely remove Ant scripts

4. Do you mind including support for Spock testing framework to the project together with Gradle adoption ? Apparently with another PR, not current one.

I would like to know your opinion about all the point before I start implementing changes.

P.S.

I am interested of the reason why you do not use GitHub button to merge PR ?
I am asking this because PR #179 contains references to the three issues: #178 #168 and #57 with fixes and closes keywords that allow GitHub automatically close referenced issues as soon as PR is merged as explained HERE.
When managing PR manually - this feature doesn't work, so referenced issues are keup open and must be reviewed and closed manually.

[gbrail]

Yes, thanks for all this work.

Let me see what I can help with:

1 -- ZIP archive. I don't want to take away absolutely everything that was
in Rhino before ;-) For a long time, you could download it from the Mozilla
page:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Download_Rhino

The "zip" task in build.xml creates the ZIPs that are there. I don't know
if everyone uses them, but again, I didn't want to break it. So if it's not
a lot of work I think that we should keep it.

2 -- I set up a CI server for Rhino (link below) using Jenkins. It's OK if
we change test coverage systems, but I think it's important that we have
one, and that it be usable from Jenkins. There are tons of Jenkins plugins
and I can diagnose the setup. If you can create a Gradle build that
generates coverage information, then I can figure out how to make it work
with Jenkins, or at least try.

http://ci.apigee.io/job/Mozilla%20Rhino/

3 -- So now that we have gradle and in theory people can automatically set
up their IDE, is it important that we do this? I am pretty sure that git
will preserve the file history, but this project has a very long history
and it'd be a shame to lose that. Is there a way to restructure that keeps
most of the changes to the minimum?

(And actually, if we wanted to restructure, then we should restructure into
multiple Maven modules, with "core" being separate from the "tools."

4 -- I don't know much about Spock. Does it make writing tests in both Java
and JS a lot easier? Can its output be merged with the output from JUnit? I
think it's important that we have only one set of test results that
includes all the tests.

On Thu, May 7, 2015 at 1:21 AM, Evgeny Shepelyuk notifications@github.com
wrote:

Hello @gbrail https://github.com/gbrail ! Thanks for approving 1st PR
about Gradle adoption.

I am planning to start working on complete migration to Gradle and
removing Ant.
I am planning to create new PR for this. Also, I have a number of pending
questions, some of them I've put to PR but for better tracking I will copy
them here.

Clarifications of the purpose of ZIP archive

About zip archive, what is the purpose of distributing it ?
Should it be published to Maven repo as artifact ? What should be the
content of that file ?
I just see no good reasons now to copy old ant behaviour since we
could just zip jars produced for publishing to maven.
Please give me some clues about this archive purpose

2.

Test Coverage

We still use them for CI until we figure out how to get the right test
coverage out of Gradle on Jenkins
Could you describe what exactly does it mean ? If this about old Emma
test coverage - I could propose to introduce usage of JaCoCo
http://www.eclemma.org/jacoco/ instead, that is continuation of Emma
project.

3.

I am planning to rebuild directory structure a little bit to be more
Maven / Gradle standard oriented, i.e.
- separate source code from resource (like JS tests, properties)
- merge all source code into one folder
- remove CVS trails
- completely remove Ant scripts
4.

Do you mind including support for Spock testing framework
http://spockframework.github.io/spock/docs/1.0/index.html to the
project together with Gradle adoption ? Apparently with another PR,
not current one.

I would like to know your opinion about all the point before I start
implementing changes.
P.S.

I am interested of the reason why you do not use GitHub button to merge
PR ?
I am asking this because PR #179
#179 contains references to the
three issues: #178 #178 #168
#168 and #57
#57 with fixes and closes keywords
that allow GitHub automatically close referenced issues as soon as PR is
merged as explained HERE
https://github.com/blog/1506-closing-issues-via-pull-requests.
When managing PR manually - this feature doesn't work, so referenced
issues are keup open and must be reviewed and closed manually.

—
Reply to this email directly or view it on GitHub
#178 (comment).

greg brail | apigee https://apigee.com/ | twitter @gbrail
http://twitter.com/gbrail

[gbrail]

Also, before we can move CI to Gradle, we have to either disable the flaky
tests, or adjust the parameters, or figure out what part of the Java
configuration is causing different results.

Since the tests are pretty superficial anyway, I think it's OK to just
change the parameters to make them more robust.

On Thu, May 7, 2015 at 1:21 AM, Evgeny Shepelyuk notifications@github.com
wrote:

Hello @gbrail https://github.com/gbrail ! Thanks for approving 1st PR
about Gradle adoption.

I am planning to start working on complete migration to Gradle and
removing Ant.
I am planning to create new PR for this. Also, I have a number of pending
questions, some of them I've put to PR but for better tracking I will copy
them here.

Clarifications of the purpose of ZIP archive

About zip archive, what is the purpose of distributing it ?
Should it be published to Maven repo as artifact ? What should be the
content of that file ?
I just see no good reasons now to copy old ant behaviour since we
could just zip jars produced for publishing to maven.
Please give me some clues about this archive purpose

2.

Test Coverage

We still use them for CI until we figure out how to get the right test
coverage out of Gradle on Jenkins
Could you describe what exactly does it mean ? If this about old Emma
test coverage - I could propose to introduce usage of JaCoCo
http://www.eclemma.org/jacoco/ instead, that is continuation of Emma
project.

3.

I am planning to rebuild directory structure a little bit to be more
Maven / Gradle standard oriented, i.e.
- separate source code from resource (like JS tests, properties)
- merge all source code into one folder
- remove CVS trails
- completely remove Ant scripts
4.

Do you mind including support for Spock testing framework
http://spockframework.github.io/spock/docs/1.0/index.html to the
project together with Gradle adoption ? Apparently with another PR,
not current one.

I would like to know your opinion about all the point before I start
implementing changes.
P.S.

I am interested of the reason why you do not use GitHub button to merge
PR ?
I am asking this because PR #179
#179 contains references to the
three issues: #178 #178 #168
#168 and #57
#57 with fixes and closes keywords
that allow GitHub automatically close referenced issues as soon as PR is
merged as explained HERE
https://github.com/blog/1506-closing-issues-via-pull-requests.
When managing PR manually - this feature doesn't work, so referenced
issues are keup open and must be reviewed and closed manually.

—
Reply to this email directly or view it on GitHub
#178 (comment).

greg brail | apigee https://apigee.com/ | twitter @gbrail
http://twitter.com/gbrail

[eshepelyuk]

ZIP archive

Do we need to duplicate one produced by Ant ? I'd propose to just include 3 jars into ZIP (code, javadoc and sources)

Test Coveratge

JaCoCo is integrated, although Code Coverage is just absolutely useless on its own. Just check out gradleNext branch.
You could generate reports by executing.

./gradlew clean test jacocoTestReport 

Directory structure

Just check Just check out gradleNext branch.
Code structure is completely rebuild according to Maven / Gradle standards.

CI with Gradle

Excuse me, but I'm just confused. As far as I understood from your comments - unit tests are randomly failing even with Ant, so there are not problem with Gradle itself, there are problems with tests.
How did you solve it before ? I think we can use the same approach.

[gbrail]

One more thought on this:

By having gradle support, even if we continue to use ant for CI for a while
longer, we've made it easier for a lot more people to get started with
Rhino, which is the most important thing.

There are a lot of other important things to do, especially to continue to
add ES6 features.

So if you have time to complete the Gradle work, then it certainly helps,
but there's a lot of other work to do as well!

On Thu, May 7, 2015 at 2:21 PM, Evgeny Shepelyuk notifications@github.com
wrote:

ZIP archive

Do we need to duplicate one produced by Ant ? I'd propose to just include
3 jars into ZIP (code, javadoc and sources)
Test Coveratge

JaCoCo is integrated, although Code Coverage is just absolutely useless
on its own. Just check out gradleNext
https://github.com/eshepelyuk/rhino/tree/gradleNext branch.
You could generate reports by executing.

./gradlew clean test jacocoTestReport

Directory structure

Just check Just check out gradleNext
https://github.com/eshepelyuk/rhino/tree/gradleNext branch.
Code structure is completely rebuild according to Maven / Gradle standards.
CI with Gradle

Excuse me, but I'm just confused. As far as I understood from your
comments - unit tests are randomly failing even with Ant, so there are
not problem with Gradle itself, there are problems with tests.
How did you solve it before ? I think we can use the same approach.

—
Reply to this email directly or view it on GitHub
#178 (comment).

greg brail | apigee https://apigee.com/ | twitter @gbrail
http://twitter.com/gbrail