You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2017/11/30 21:59:54 UTC
RE switching surefire to the standard build
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
Re: RE switching surefire to the standard build
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 2 Dec 2017 at 10:42, Tibor Digana <ti...@apache.org> 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 <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Sat 2 Dec 2017 at 10:03, Tibor Digana <ti...@apache.org> 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 <
> > > stephen.alan.connolly@gmail.com> 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
Re: RE switching surefire to the standard build
Posted by Tibor Digana <ti...@apache.org>.
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.
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 <
stephen.alan.connolly@gmail.com> wrote:
> On Sat 2 Dec 2017 at 10:03, Tibor Digana <ti...@apache.org> 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 <
> > stephen.alan.connolly@gmail.com> 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
>
Re: RE switching surefire to the standard build
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 2 Dec 2017 at 10:03, Tibor Digana <ti...@apache.org> 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 <
> stephen.alan.connolly@gmail.com> 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
Re: RE switching surefire to the standard build
Posted by Tibor Digana <ti...@apache.org>.
Pls do not do it!
I want to have it under control in Jenkinsfile and not to share the code
with other projects.
Surefire project is different and it must be still different.
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.
T
On Thu, Nov 30, 2017 at 10:59 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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
>
Re: RE switching surefire to the standard build
Posted by Stephen Connolly <st...@gmail.com>.
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion
failed with message:
Detected JDK Version: 9.0.1 is not in the allowed range [1.8,1.9).
Ok finding some bugs then
On 30 November 2017 at 21:59, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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
>