[ https://issues.apache.org/jira/browse/TAP5-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18017173#comment-18017173 ]
Hudson commented on TAP5-2809: ------------------------------ SUCCESS: Integrated in Jenkins build Tapestry » TAP5-2809 #13 (See [https://ci-builds.apache.org/job/Tapestry/job/TAP5-2809/13/]) TAP5-2809: minor code styling, removin unecessary deps and code (benw: rev faa95783599a8ab1586f02526fca56dc935822ca) * (edit) tapestry-runner/build.gradle * (edit) tapestry-jpa/build.gradle * (edit) tapestry-cdi/build.gradle * (edit) buildSrc/build.gradle * (edit) tapestry-ioc-jcache/build.gradle > Improve/Fix Gradle Setup > ------------------------ > > Key: TAP5-2809 > URL: https://issues.apache.org/jira/browse/TAP5-2809 > Project: Tapestry 5 > Issue Type: Task > Affects Versions: 5.9.1 > Reporter: Ben Weidig > Assignee: Ben Weidig > Priority: Major > > The current Gradle setup has multiple issues: > * Pre-Java 8 remnants > * Incomplete upgrade to JUnit 5 > * Incorrect testng.xml > * Misaligned dependency version between projects > > To improve the situation, I suggest: > * Remove all pre-Java 8 options > * Create Gradle conventions for > ** Subproject setup > ** JUnit 5 (+Spock) > ** TestNG (and move testng.xml to default locations) > ** JUnit 4 for legacy reasons > * Introducing version catalogs for shared dependencies and a consistent > declaration of module-specific dependencies. > > In a second step, more tasks, like Javadoc-related tasks or publishing, could > be done with conventions or build plugins, to make them easier to use and > maintain. > The overall risk is breaking the build and breaking changes for Tapestry > users if a dependency is no longer exposed. > However, choosing the right configuration so as not to accidentally export > dependencies is more critical, and the error messages should clearly state > why a build is no longer working. -- This message was sent by Atlassian Jira (v8.20.10#820010)