On Sat 2 Dec 2017 at 10:42, Tibor Digana <[email protected]> wrote:
> One function in Jenkinsfile is sick. > It is pure bureaucracy where the Jenkinsfile becomes a beton. > There is no freedom for developers in Jenkinsfile in that case. If you don’t want Java 9 then you can turn off Java 9 using the parameters. Now the larger question is why we cannot build with Java 9... Any snowflake build is a code smell Any build needing complex Jenkinsfile logic is a code smell Now if you are in the position where surefire cannot build with Java 9 but you need to run tests with Java 9... that would be an acceptable reason... but ultimately we will need to solve the Java 9 issues so that surefire is able to use the standard build. TL;DR if you cannot use the standard build, then there is a barrier on new contributors as they cannot “just build”, instead they need to understand how to build. > > The build does not need to have Java 9. It's not the reason to invest > effort. I invest effort to Jigsaw support, JUnit5 and 3.0. > It is quite a lot of work. > Do not try to see it from one direction only. > > On Sat, Dec 2, 2017 at 11:23 AM, Stephen Connolly < > [email protected]> wrote: > > > On Sat 2 Dec 2017 at 10:03, Tibor Digana <[email protected]> wrote: > > > > > Pls do not do it! > > > I want to have it under control in Jenkinsfile and not to share the > code > > > with other projects. > > > > > > I do not see that you actually have anything that needs a custom build. > > > > We can add code coverage to the template. > > > > The only repo I see with reasonable excuses for a custom Jenkinsfile is > the > > core Maven itself... and that’s only because of the core integration > tests. > > > > > > > Surefire project is different and it must be still different. > > > > > > Certainly you have moved the build that way... i’d Like to see explicit > > reasons why surefire cannot use the standard build. Snowflake builds do > not > > help grow community. > > > > > > > I see Groovy libraries useful only in situations when I call Hudson API > > > functions and I need to avoid security issue on these calls after using > > > shared Groovy library for Jenkins, but not in here like one function > > > substituting entire content of Jenkinsfile. > > > > > > There are many use cases for shared libraries. Do not limit yourself to > one > > small (and in my view antipattern) use case > > > > > > > > > > T > > > > > > On Thu, Nov 30, 2017 at 10:59 PM, Stephen Connolly < > > > [email protected]> wrote: > > > > > > > https://builds.apache.org/job/maven-wip/job/maven-surefire/ > > > > job/new-jenkinsfile/ > > > > to see what it's like. > > > > > > > > We can look into adding jacoco reporting to the standard build if it > is > > > > seen as important > > > > > > > > > -- > > Sent from my phone > > > -- Sent from my phone
