Closed laurelmay closed 5 years ago
I have no fundamental objection to this, although I'm not sure what the general "etiquette" is for Gradle projects (e.g., whether it's preferable to use the native program even if the wrapper is present). Doing this means that users will have a noticeable delay the first time they run the scripts after the change if they hadn't already used the wrapper, but that's a minor issue. I can't tell if there is any general performance difference between the native program and the wrapper.
FWIW, I'm really not terribly happy with the whole gradle/compile/test/run interface right now. It's clumsy and will be nearly impossible for beginners to use. This is why #23 exists; IIRC we wanted to re-engineer the whole thing to make it a single provided wrapper script (and a very beginner-oriented tutorial about how to get to that point). I think a patch like @kylelaker is suggesting could be an incremental step towards closing that issue but ultimately I think we need some larger work on system usability.
@Zamua thoughts?
Also, perhaps @jennahorrall has some thoughts here because the folks in her user study will end up having to use the result of a script reorganization.
I think we should definitely use the gradle wrapper, so if you're willing to contribute that piece @kylelaker please do as long as it's not a huge time commitment.
@lam2mo is right though and we should really consider changing how building and compiling and all that is done right now. I agree it's clumsy and not user friendly. If there are any ideas on that front please add them to #23
Currently the scripts use the
gradle
command which causes them to expect Gradle to be installed; however, the project is configured to use the Gradle wrapper. It would be nice if the scripts used./gradlew
in place ofgradle
.I am happy to work on a patch for this, but I want to make sure that this is desirable.