Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

Hi Baptiste,

The exclusions where introduced in this PR:
https://github.com/jenkinsci/jenkins/pull/1816

I'll try to get more context to include in the POM comments.

Thanks!

On Sat, Jan 30, 2016 at 9:52 PM, Baptiste Mathus  wrote:

> Hi,
>
> Trying to build on an old version (1.447.2), I get the following error:
> Found Banned Dependency: org.sonatype.sisu:sisu-guice:jar:3.1.0
>
> Before/while excluding the dependency I'd like to understand, could
> someone provide some context about that?
> IIUC, this may be because we already use guice, and sisu-guice is a
> patched one, so it would indeed conflict.
> The question is: does it mean a whole bunch of plugins potentially would
> still be embedding currently sisu-guice?
>
> I think that it would be good to document why those dependencies are
> banned as a comment in
> https://github.com/jenkinsci/plugin-pom/blob/master/pom.xml#L510L514
>
> Thanks for the feedback
>
>
> 2016-01-22 19:58 GMT+01:00 Jesse Glick :
>
>> Update: we are up to 2.2, and 1.645 will have been the last release of
>> the old POM.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1ZCqu8FAz7M254cFPWb4KPw9uXZx7aPjtdkOT2fe_EUA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6oZkExqbd%3DxzmTKVL-W%3DrX5LW_-5tHCHoqEceoQBOHug%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B4HrviHDTLaiitYPjBoM2dWYE75%3Dws%3DEc232ba5xangKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Baptiste Mathus]

Hi,

Trying to build on an old version (1.447.2), I get the following error:
Found Banned Dependency: org.sonatype.sisu:sisu-guice:jar:3.1.0

Before/while excluding the dependency I'd like to understand, could someone
provide some context about that?
IIUC, this may be because we already use guice, and sisu-guice is a patched
one, so it would indeed conflict.
The question is: does it mean a whole bunch of plugins potentially would
still be embedding currently sisu-guice?

I think that it would be good to document why those dependencies are banned
as a comment in
https://github.com/jenkinsci/plugin-pom/blob/master/pom.xml#L510L514

Thanks for the feedback


2016-01-22 19:58 GMT+01:00 Jesse Glick :

> Update: we are up to 2.2, and 1.645 will have been the last release of
> the old POM.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1ZCqu8FAz7M254cFPWb4KPw9uXZx7aPjtdkOT2fe_EUA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6oZkExqbd%3DxzmTKVL-W%3DrX5LW_-5tHCHoqEceoQBOHug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

Update: we are up to 2.2, and 1.645 will have been the last release of
the old POM.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1ZCqu8FAz7M254cFPWb4KPw9uXZx7aPjtdkOT2fe_EUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Stephen Connolly]

Well we started our internal parent pom at 1.400 so as long as *you*
consult the older versions of that you should be able to infer the correct
versions of hpi plugin and stapler plugin to build against such a really
old core...

If *you* do that, could you record those details for the community - as
they don't have access to our repositories

On 21 January 2016 at 10:07, Robert Sandell  wrote:

> Thanks!
>
> Is there any known minimum version of core this can work with?
> E.g. can I update my plugin to this with jenkins.version=1.404 ?
>
> Or maybe is there some recommended minimum core to start using this with?
> I was thinking of the usage of npm and node settings might assume things?
>
> /B
>
> On Thu, Jan 21, 2016 at 8:45 AM, Andres Rodriguez <
> arodrig...@cloudbees.com> wrote:
>
>> Hi,
>>
>> A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0`
>> has been released.
>> The source is now at its new location
>> https://github.com/jenkinsci/plugin-pom.
>>
>> Regards,
>>
>> Andrés
>>
>>
>>
>>
>> On Wed, Jan 20, 2016 at 6:10 PM, Andres Rodriguez <
>> arodrig...@cloudbees.com> wrote:
>>
>>>
>>> On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick 
>>> wrote:
>>>
 On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
  wrote:
 >> I would suggest `javadoc:javadoc clean
 >> install`
 >
 > -1 as that may give a false fail on a clean checkout where the javadoc
 > plugin references generated classes

 Possibly. What I do in `workflow-plugin`, which has served me well, is
 to just include `javadoc:javadoc` in a profile activated when not
 `skipTests`. That ensures that all “full builds” including CI verify
 the absence of Javadoc errors, so you do not get a nasty surprise on
 release day. Routine developer builds—where you are just trying to get
 artifacts created so you can `hpi:run` etc.—do not incur the expense.


>>> That has been included, but independently of findbugs:
>>> https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827
>>>
>>>
 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Andres Rodriguez
>>> www.cloudbees.com
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Andres Rodriguez
>> www.cloudbees.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Robert Sandell
> *Software Engineer*
> *CloudBees Inc.*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS20iY1vg0nkRW8P5dBDgctCdnGP%3DC8O%2B1mYZg3u4bBJVw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw2imz9eCjw%3Dh3yBsAjcHzQiGDnBnMeRJBV9_weK4y2xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Fri, Jan 22, 2016 at 4:28 AM, Stephen Connolly
 wrote:
> Well we started our internal parent pom at 1.400 so as long as *you* consult
> the older versions of that you should be able to infer the correct versions
> of hpi plugin and stapler plugin to build against such a really old core...

FWIW I have in my `~/.m2/settings.xml` profiles such as


jenkins-565

1.565.3
1.106
6



It might be worth writing and testing a series of such profiles for
all reasonably recent LTS lines and adding them to `plugin-pom` for
everyone to benefit from. Then without any work, you could check your
plugin’s behavior against a different line very easily:

mvn -Pjenkins-642 clean verify

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr025xip7k507HHZpYrAzLYbTcJtv9xgnymHNB6NepaJMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Robert Sandell]

Thanks!

Is there any known minimum version of core this can work with?
E.g. can I update my plugin to this with jenkins.version=1.404 ?

Or maybe is there some recommended minimum core to start using this with?
I was thinking of the usage of npm and node settings might assume things?

/B

On Thu, Jan 21, 2016 at 8:45 AM, Andres Rodriguez 
wrote:

> Hi,
>
> A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0`
> has been released.
> The source is now at its new location
> https://github.com/jenkinsci/plugin-pom.
>
> Regards,
>
> Andrés
>
>
>
>
> On Wed, Jan 20, 2016 at 6:10 PM, Andres Rodriguez <
> arodrig...@cloudbees.com> wrote:
>
>>
>> On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick 
>> wrote:
>>
>>> On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
>>>  wrote:
>>> >> I would suggest `javadoc:javadoc clean
>>> >> install`
>>> >
>>> > -1 as that may give a false fail on a clean checkout where the javadoc
>>> > plugin references generated classes
>>>
>>> Possibly. What I do in `workflow-plugin`, which has served me well, is
>>> to just include `javadoc:javadoc` in a profile activated when not
>>> `skipTests`. That ensures that all “full builds” including CI verify
>>> the absence of Javadoc errors, so you do not get a nasty surprise on
>>> release day. Routine developer builds—where you are just trying to get
>>> artifacts created so you can `hpi:run` etc.—do not incur the expense.
>>>
>>>
>> That has been included, but independently of findbugs:
>> https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827
>>
>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Andres Rodriguez
>> www.cloudbees.com
>>
>>
>
>
> --
> Regards,
>
> Andres Rodriguez
> www.cloudbees.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Robert Sandell
*Software Engineer*
*CloudBees Inc.*

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS20iY1vg0nkRW8P5dBDgctCdnGP%3DC8O%2B1mYZg3u4bBJVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

Hi,

We've done tests with versions back to 1.509.4. Adjusting `jekins.version`,
`jenkins-test-harness.version` and java.level to the appropriate settings
should be no problem for previous versions.

Regarding node stuff, you have `node.version`and `npm.version`properties,
but other customization may require overriding some config in the profiles.

Thanks!

On Thu, Jan 21, 2016 at 11:07 AM, Robert Sandell 
wrote:

> Thanks!
>
> Is there any known minimum version of core this can work with?
> E.g. can I update my plugin to this with jenkins.version=1.404 ?
>
> Or maybe is there some recommended minimum core to start using this with?
> I was thinking of the usage of npm and node settings might assume things?
>
> /B
>
> On Thu, Jan 21, 2016 at 8:45 AM, Andres Rodriguez <
> arodrig...@cloudbees.com> wrote:
>
>> Hi,
>>
>> A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0`
>> has been released.
>> The source is now at its new location
>> https://github.com/jenkinsci/plugin-pom.
>>
>> Regards,
>>
>> Andrés
>>
>>
>>
>>
>> On Wed, Jan 20, 2016 at 6:10 PM, Andres Rodriguez <
>> arodrig...@cloudbees.com> wrote:
>>
>>>
>>> On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick 
>>> wrote:
>>>
 On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
  wrote:
 >> I would suggest `javadoc:javadoc clean
 >> install`
 >
 > -1 as that may give a false fail on a clean checkout where the javadoc
 > plugin references generated classes

 Possibly. What I do in `workflow-plugin`, which has served me well, is
 to just include `javadoc:javadoc` in a profile activated when not
 `skipTests`. That ensures that all “full builds” including CI verify
 the absence of Javadoc errors, so you do not get a nasty surprise on
 release day. Routine developer builds—where you are just trying to get
 artifacts created so you can `hpi:run` etc.—do not incur the expense.


>>> That has been included, but independently of findbugs:
>>> https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827
>>>
>>>
 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Andres Rodriguez
>>> www.cloudbees.com
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Andres Rodriguez
>> www.cloudbees.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Robert Sandell
> *Software Engineer*
> *CloudBees Inc.*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS20iY1vg0nkRW8P5dBDgctCdnGP%3DC8O%2B1mYZg3u4bBJVw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B5cE-MPe-KvOqs57k3JbuboP222vjUFp%2BXJ%3DJ0A88sjJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

You can set JTH to the version you need: `jenkins-test-harness.version`

Thanks!

On Thu, Jan 21, 2016 at 11:19 AM, Robert Sandell 
wrote:

> Maybe it's the test harness that is setting the lower limit of 1.580.1
>
> .B
>
> On Thu, Jan 21, 2016 at 11:07 AM, Robert Sandell 
> wrote:
>
>> Thanks!
>>
>> Is there any known minimum version of core this can work with?
>> E.g. can I update my plugin to this with jenkins.version=1.404 ?
>>
>> Or maybe is there some recommended minimum core to start using this with?
>> I was thinking of the usage of npm and node settings might assume things?
>>
>> /B
>>
>> On Thu, Jan 21, 2016 at 8:45 AM, Andres Rodriguez <
>> arodrig...@cloudbees.com> wrote:
>>
>>> Hi,
>>>
>>> A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0`
>>> has been released.
>>> The source is now at its new location
>>> https://github.com/jenkinsci/plugin-pom.
>>>
>>> Regards,
>>>
>>> Andrés
>>>
>>>
>>>
>>>
>>> On Wed, Jan 20, 2016 at 6:10 PM, Andres Rodriguez <
>>> arodrig...@cloudbees.com> wrote:
>>>

 On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick 
 wrote:

> On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
>  wrote:
> >> I would suggest `javadoc:javadoc clean
> >> install`
> >
> > -1 as that may give a false fail on a clean checkout where the
> javadoc
> > plugin references generated classes
>
> Possibly. What I do in `workflow-plugin`, which has served me well, is
> to just include `javadoc:javadoc` in a profile activated when not
> `skipTests`. That ensures that all “full builds” including CI verify
> the absence of Javadoc errors, so you do not get a nasty surprise on
> release day. Routine developer builds—where you are just trying to get
> artifacts created so you can `hpi:run` etc.—do not incur the expense.
>
>
 That has been included, but independently of findbugs:
 https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827


> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Regards,

 Andres Rodriguez
 www.cloudbees.com


>>>
>>>
>>> --
>>> Regards,
>>>
>>> Andres Rodriguez
>>> www.cloudbees.com
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Robert Sandell
>> *Software Engineer*
>> *CloudBees Inc.*
>>
>
>
>
> --
> Robert Sandell
> *Software Engineer*
> *CloudBees Inc.*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2MTGRfjBDdvBjae9hUWqVwPwGApY7cyoirzpCOw7OXNQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B4UQC1MLohcMV7h3UKhPCzTf%2B24rvnb5c8QuirqdffRJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Robert Sandell]

Maybe it's the test harness that is setting the lower limit of 1.580.1

.B

On Thu, Jan 21, 2016 at 11:07 AM, Robert Sandell 
wrote:

> Thanks!
>
> Is there any known minimum version of core this can work with?
> E.g. can I update my plugin to this with jenkins.version=1.404 ?
>
> Or maybe is there some recommended minimum core to start using this with?
> I was thinking of the usage of npm and node settings might assume things?
>
> /B
>
> On Thu, Jan 21, 2016 at 8:45 AM, Andres Rodriguez <
> arodrig...@cloudbees.com> wrote:
>
>> Hi,
>>
>> A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0`
>> has been released.
>> The source is now at its new location
>> https://github.com/jenkinsci/plugin-pom.
>>
>> Regards,
>>
>> Andrés
>>
>>
>>
>>
>> On Wed, Jan 20, 2016 at 6:10 PM, Andres Rodriguez <
>> arodrig...@cloudbees.com> wrote:
>>
>>>
>>> On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick 
>>> wrote:
>>>
 On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
  wrote:
 >> I would suggest `javadoc:javadoc clean
 >> install`
 >
 > -1 as that may give a false fail on a clean checkout where the javadoc
 > plugin references generated classes

 Possibly. What I do in `workflow-plugin`, which has served me well, is
 to just include `javadoc:javadoc` in a profile activated when not
 `skipTests`. That ensures that all “full builds” including CI verify
 the absence of Javadoc errors, so you do not get a nasty surprise on
 release day. Routine developer builds—where you are just trying to get
 artifacts created so you can `hpi:run` etc.—do not incur the expense.


>>> That has been included, but independently of findbugs:
>>> https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827
>>>
>>>
 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Andres Rodriguez
>>> www.cloudbees.com
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Andres Rodriguez
>> www.cloudbees.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Robert Sandell
> *Software Engineer*
> *CloudBees Inc.*
>



-- 
Robert Sandell
*Software Engineer*
*CloudBees Inc.*

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2MTGRfjBDdvBjae9hUWqVwPwGApY7cyoirzpCOw7OXNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

Hi,

A first version with coordinates `org.jenkins-ci.plugins:plugin:pom:2.0`
has been released.
The source is now at its new location
https://github.com/jenkinsci/plugin-pom.

Regards,

Andrés




On Wed, Jan 20, 2016 at 6:10 PM, Andres Rodriguez 
wrote:

>
> On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick  wrote:
>
>> On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
>>  wrote:
>> >> I would suggest `javadoc:javadoc clean
>> >> install`
>> >
>> > -1 as that may give a false fail on a clean checkout where the javadoc
>> > plugin references generated classes
>>
>> Possibly. What I do in `workflow-plugin`, which has served me well, is
>> to just include `javadoc:javadoc` in a profile activated when not
>> `skipTests`. That ensures that all “full builds” including CI verify
>> the absence of Javadoc errors, so you do not get a nasty surprise on
>> release day. Routine developer builds—where you are just trying to get
>> artifacts created so you can `hpi:run` etc.—do not incur the expense.
>>
>>
> That has been included, but independently of findbugs:
> https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Regards,
>
> Andres Rodriguez
> www.cloudbees.com
>
>


-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B7OJrWbhsLFkTavDqDTeZhkkM0tyYfy8hC1jKyxL1FZmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

On Wed, Jan 20, 2016 at 6:03 PM, Jesse Glick  wrote:

> On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
>  wrote:
> >> I would suggest `javadoc:javadoc clean
> >> install`
> >
> > -1 as that may give a false fail on a clean checkout where the javadoc
> > plugin references generated classes
>
> Possibly. What I do in `workflow-plugin`, which has served me well, is
> to just include `javadoc:javadoc` in a profile activated when not
> `skipTests`. That ensures that all “full builds” including CI verify
> the absence of Javadoc errors, so you do not get a nasty surprise on
> release day. Routine developer builds—where you are just trying to get
> artifacts created so you can `hpi:run` etc.—do not incur the expense.
>
>
That has been included, but independently of findbugs:
https://github.com/andresrc/plugin-pom/blob/03f2c716f68f9142d3b8fbb14fd9b8af3d154b0a/pom.xml#L804-L827


> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B70wf7TfK1j1dYvQ0p1FoYNCyXAb24d8dVvo8qC92VNjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Wed, Jan 20, 2016 at 4:22 AM, Stephen Connolly
 wrote:
>> I would suggest `javadoc:javadoc clean
>> install`
>
> -1 as that may give a false fail on a clean checkout where the javadoc
> plugin references generated classes

Possibly. What I do in `workflow-plugin`, which has served me well, is
to just include `javadoc:javadoc` in a profile activated when not
`skipTests`. That ensures that all “full builds” including CI verify
the absence of Javadoc errors, so you do not get a nasty surprise on
release day. Routine developer builds—where you are just trying to get
artifacts created so you can `hpi:run` etc.—do not incur the expense.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr05ksqCt7UJmKd4FWnZUMtNAXASO6ESShWt-3hmqAYXUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Stephen Connolly]

On Tuesday 19 January 2016, Jesse Glick  wrote:

> On Mon, Jan 18, 2016 at 4:35 AM,  >
> wrote:
> > The current proposal is being pushed to
> > https://github.com/andresrc/plugin-pom.
>
> Since there is no PR for the POM itself, I am putting comments here.
>
> `` does not seem like it belongs. The POM need not be
> used by plugins hosted under the Jenkins organization.
>
> AFAIK the test dependency on `jenkins-war` should be on
> `war-for-test`, not `war`.
>
> I would suggest `javadoc:javadoc clean
> install` rather than `clean
> install javadoc:javadoc` since Javadoc generation
> is likely a lot faster than running tests, and more likely to be
> failing without anyone knowing about it before.


-1 as that may give a false fail on a clean checkout where the javadoc
plugin references generated classes etc and Java 8 is being strict.


>
> Consider
> https://github.com/jenkinsci/workflow-plugin/blob/master/pom.xml#L201-L211
> which I have found invaluable. Could be added later of course.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ZHQrbgT1QP5G3DxgifLTO4M1g3ZkMv-H7aVK3_1g_XQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxQ5fxVpQdeKVyUc2ocJi0vBo1JoFkCfGYDiHxN0Zg_1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

On Tue, Jan 19, 2016 at 8:49 PM, Jesse Glick  wrote:

> On Mon, Jan 18, 2016 at 4:35 AM,   wrote:
> > The current proposal is being pushed to
> > https://github.com/andresrc/plugin-pom.
>
> Since there is no PR for the POM itself, I am putting comments here.
>
> `` does not seem like it belongs. The POM need not be
> used by plugins hosted under the Jenkins organization.
>

Done


>
> AFAIK the test dependency on `jenkins-war` should be on
> `war-for-test`, not `war`.
>
>
Done


> I would suggest `javadoc:javadoc clean
> install` rather than `clean
> install javadoc:javadoc` since Javadoc generation
> is likely a lot faster than running tests, and more likely to be
> failing without anyone knowing about it before.
>
> Consider
> https://github.com/jenkinsci/workflow-plugin/blob/master/pom.xml#L201-L211
> which I have found invaluable. Could be added later of course.
>
>
I've added a mix between the existing approach and workflow's, in order to
keep the exclusionFilter profile optional as well.
I've also moved running javadoc when tests are active to a profile and
removed it from the release profile.


> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ZHQrbgT1QP5G3DxgifLTO4M1g3ZkMv-H7aVK3_1g_XQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B4jTjvSFkG1dHswXSu%2BZLhRCLyquYT80hP2eJUkqj04HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Andres Rodriguez]

On Tue, Jan 19, 2016 at 8:19 PM, Jesse Glick  wrote:

> On Tue, Jan 19, 2016 at 6:27 AM,   wrote:
> > Decide the final artifact maven coordinates: following the criteria used
> in
> > jenkins-test-harness, we could keep the same groupId / artifactId than
> > before and bump version to 2.0.
>
> Yes I think making it be `org.jenkins-ci.plugins:plugin:pom:2.0` would
> be appropriate. If nothing else, this advertises it as an upgrade for
> people who use standard Maven tools or IDEs to look for new versions
> of artifacts (in this case parent POM). Of course you need to make
> certain changes to your plugin’s POM to use it (in most cases you
> would want to define `jenkins.version` at a minimum), but that seems
> OK—the bump in major version should be sufficient indication that
> something noteworthy has changed.
>

That was my thought as well. It has already been updated to to those
coordinates.


>
> > Create a repository in the jenkinsci GitHub org (by someone with
> permissions
> > forking the existing one).
>
> I can do this if there are no objections. The main question is the
> repository name. `plugin-pom`?
>
>
That was my thought as well. I checked is was available before creating the
initial repo.


> > Perform a release.
>
> And I suggest that `jenkinsci/jenkins/plugins/pom.xml` be deleted.
>

Sure, I'll prepare a PR.

Thanks


>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0A6jrobt2phksSqC9cE_qh%3D56wEnhOmurhFerj5DgRmA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Andres Rodriguez
www.cloudbees.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAM9%3DZ%2B6TKtiy3sQVf3P-f0fgxR3G4HBsk5POD0jFvzOhHGcRzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[arodriguez]

Hi all,

Thanks for your comments.

After some adaptations for the jenkins test harness split and some of the 
comments received I've deployed a first snapshot a there is already a 
plugin CI build done using the experimental POM: 
https://github.com/jenkinsci/branch-api-plugin/pull/25

As stated in the first post, the next steps include:

   - Decide the final artifact maven coordinates: following the criteria 
   used in jenkins-test-harness, we could keep the same groupId / artifactId 
   than before and bump version to 2.0.
   - Create a repository in the jenkinsci GitHub org (by someone with 
   permissions forking the existing one).
  - Adapt the pom to the final SCM coordinates.
   - Perform a release. 
   - Update the documentation: I have already identified the wiki pages to 
   modify.


Thanks,

Andrés

 

On Monday, January 18, 2016 at 10:35:44 AM UTC+1, arodr...@cloudbees.com 
wrote:
>
> Hi all,
>
> Please find below a proposal for a new parent POM for Jenkins Plugins.
>
> Motivation
>
> The main driver to propose a revision of the parent plugin POM is to 
> decouple this artifact from the Jenkins Core:
>
>- 
>
>Simplifying the mechanism to build and test a plugin against different 
>core versions.
>- 
>
>Decoupling build-related aspects, such as static analysis tools, JRE 
>signatures, etc. from the baseline core versions, as they are totally 
>independent concerns, reducing the need to include otherwise common 
>configuration in each plugin POM just because we want to support and older 
>baseline.
>
>
> One use case that would greatly benefit from this change is for example, 
> jenkins#1530 , where it 
> is necessary to propose API changes in core and matching plugin usages. The 
> current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT 
> revision. Plugin Compatibility Testing can also benefit from this change.
>
> Approach
>
> As stated above the approach is based in making the plugin parent POM 
> independent of the main Jenkins core project, and performing the following 
> actions:
>
>- 
>
>Make the Jenkins Core version to use configurable via a property, so 
>that a simple mvn -Djenkins.version= hpi:run is enough to compile 
>and run a plugin with a different core version. 
>- 
>
>Make the Jenkins Test Harness version to use also configurable (the 
>default being the same Jenkins core version), for those cases that may 
> need 
>it, such as copyartifact#76 
>.
>- 
>
>Reduce the number of Maven plugin pinned versions to those really used.
>- 
>
>Reduce the number of number of elements (versions, etc) overridable 
>via properties to those that have a specific reason, setting the values to 
>those intended to be used. There’s no reason to make everything 
> overridable 
>as the parent pom evolution is now independent of the baseline Jenkins 
> Core 
>versions.
>
>
> Other aspects included:
>
>- 
>
>Default configuration for findbugs, including the possibility of 
>automatically activating exclusions, and a property to define if findbug 
>errors should break the build (default true).
>- 
>
>JRE signature verification configured to the Java level defined for 
>the build (using a property as well).
>- 
>
>Regarding releases:
>- 
>   
>   Launching javadoc:javadoc in the prepare phase, in order to avoid 
>   the inconvenience “stricter” Java 8 javadoc breaking builds in the 
> release 
>   phase.
>   - 
>   
>   Skipping tests in the release phase, cutting release build times 
>   for plugins with a great number of tests.
>   - 
>
>General cleanup.
>
>
> Ok, show me the code
>
> The current proposal is being pushed to 
> https://github.com/andresrc/plugin-pom. It is not deployed to any 
> repository yet, so in order to test it a local install is required. The 
> artifactId is intentionally changed to avoid confusion. JIRA issue 
> [JENKINS-32493]  has 
> been filed.
>
> Some plugins have been used to verify the current proposal, including:
>
>- 
>
>Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
>- 
>
>Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
>- 
>
>Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
>- 
>
>Script Security: 
>https://github.com/jenkinsci/script-security-plugin/pull/36
>- 
>
>Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
>
>
> There is also an update on the Maven archetype at 
> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
>
> Next Steps
>
> After collecting feedback from the community and if there’s certain 
> 

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Ullrich Hafner]

Since this is targeted for 2.0: are there also plans to avoid the dependency 
hell in future Jenkins releases within this pom or is this something that needs 
to be addressed somewhere else? Currently the Jenkins war exposes all 
dependencies (and transitive…) to the plug-ins. This leads to various library 
conflicts if a plug-in also needs a dependency e.g. in a different version.

> Am 19.01.2016 um 12:27 schrieb arodrig...@cloudbees.com:
> 
> Hi all,
> 
> Thanks for your comments.
> 
> After some adaptations for the jenkins test harness split and some of the 
> comments received I've deployed a first snapshot a there is already a plugin 
> CI build done using the experimental POM: 
> https://github.com/jenkinsci/branch-api-plugin/pull/25 
> 
> 
> As stated in the first post, the next steps include:
> Decide the final artifact maven coordinates: following the criteria used in 
> jenkins-test-harness, we could keep the same groupId / artifactId than before 
> and bump version to 2.0.
> Create a repository in the jenkinsci GitHub org (by someone with permissions 
> forking the existing one).
> Adapt the pom to the final SCM coordinates.
> Perform a release.
> Update the documentation: I have already identified the wiki pages to modify.
> 
> Thanks,
> 
> Andrés
> 
> 
> 
> On Monday, January 18, 2016 at 10:35:44 AM UTC+1, arodr...@cloudbees.com 
>  wrote:
> Hi all,
> 
> Please find below a proposal for a new parent POM for Jenkins Plugins.
> 
> Motivation
> 
> The main driver to propose a revision of the parent plugin POM is to decouple 
> this artifact from the Jenkins Core:
> Simplifying the mechanism to build and test a plugin against different core 
> versions.
> Decoupling build-related aspects, such as static analysis tools, JRE 
> signatures, etc. from the baseline core versions, as they are totally 
> independent concerns, reducing the need to include otherwise common 
> configuration in each plugin POM just because we want to support and older 
> baseline.
> 
> One use case that would greatly benefit from this change is for example, 
> jenkins#1530 , where it is 
> necessary to propose API changes in core and matching plugin usages. The 
> current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT revision. 
> Plugin Compatibility Testing can also benefit from this change.
> 
> Approach
> 
> As stated above the approach is based in making the plugin parent POM 
> independent of the main Jenkins core project, and performing the following 
> actions:
> Make the Jenkins Core version to use configurable via a property, so that a 
> simple mvn -Djenkins.version= hpi:run is enough to compile and run a 
> plugin with a different core version.
> Make the Jenkins Test Harness version to use also configurable (the default 
> being the same Jenkins core version), for those cases that may need it, such 
> as copyartifact#76 .
> Reduce the number of Maven plugin pinned versions to those really used.
> Reduce the number of number of elements (versions, etc) overridable via 
> properties to those that have a specific reason, setting the values to those 
> intended to be used. There’s no reason to make everything overridable as the 
> parent pom evolution is now independent of the baseline Jenkins Core versions.
> 
> Other aspects included:
> Default configuration for findbugs, including the possibility of 
> automatically activating exclusions, and a property to define if findbug 
> errors should break the build (default true).
> JRE signature verification configured to the Java level defined for the build 
> (using a property as well).
> Regarding releases:
> Launching javadoc:javadoc in the prepare phase, in order to avoid the 
> inconvenience “stricter” Java 8 javadoc breaking builds in the release phase.
> Skipping tests in the release phase, cutting release build times for plugins 
> with a great number of tests.
> General cleanup.
> 
> Ok, show me the code
> 
> The current proposal is being pushed to 
> https://github.com/andresrc/plugin-pom 
> . It is not deployed to any 
> repository yet, so in order to test it a local install is required. The 
> artifactId is intentionally changed to avoid confusion. JIRA issue 
> [JENKINS-32493]  has been 
> filed.
> 
> Some plugins have been used to verify the current proposal, including:
> Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25 
> 
> Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78 
> 
> Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303 
> 
> Script 

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Tue, Jan 19, 2016 at 2:49 PM, Jesse Glick  wrote:
> Since there is no PR for the POM itself, I am putting comments here.

…and added further comments to the PRs for various plugins. BTW now
that you have deployed a snapshot you should close & reopen those PRs
so we can see if the result actually builds.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0HpBX8mJYnkGuhgFO0cMagcKxNZf7WSqBT64iJAsaWkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Mon, Jan 18, 2016 at 4:35 AM,   wrote:
> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom.

Since there is no PR for the POM itself, I am putting comments here.

`` does not seem like it belongs. The POM need not be
used by plugins hosted under the Jenkins organization.

AFAIK the test dependency on `jenkins-war` should be on
`war-for-test`, not `war`.

I would suggest `javadoc:javadoc clean
install` rather than `clean
install javadoc:javadoc` since Javadoc generation
is likely a lot faster than running tests, and more likely to be
failing without anyone knowing about it before.

Consider 
https://github.com/jenkinsci/workflow-plugin/blob/master/pom.xml#L201-L211
which I have found invaluable. Could be added later of course.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ZHQrbgT1QP5G3DxgifLTO4M1g3ZkMv-H7aVK3_1g_XQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Tue, Jan 19, 2016 at 6:27 AM,   wrote:
> Decide the final artifact maven coordinates: following the criteria used in
> jenkins-test-harness, we could keep the same groupId / artifactId than
> before and bump version to 2.0.

Yes I think making it be `org.jenkins-ci.plugins:plugin:pom:2.0` would
be appropriate. If nothing else, this advertises it as an upgrade for
people who use standard Maven tools or IDEs to look for new versions
of artifacts (in this case parent POM). Of course you need to make
certain changes to your plugin’s POM to use it (in most cases you
would want to define `jenkins.version` at a minimum), but that seems
OK—the bump in major version should be sufficient indication that
something noteworthy has changed.

> Create a repository in the jenkinsci GitHub org (by someone with permissions
> forking the existing one).

I can do this if there are no objections. The main question is the
repository name. `plugin-pom`?

> Perform a release.

And I suggest that `jenkinsci/jenkins/plugins/pom.xml` be deleted.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0A6jrobt2phksSqC9cE_qh%3D56wEnhOmurhFerj5DgRmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Tue, Jan 19, 2016 at 6:45 AM, Ullrich Hafner
 wrote:
> Since this is targeted for 2.0

I do not see any reason to delay this change until 2.0. We can take
advantage of it immediately.

> are there also plans to avoid the dependency
> hell in future Jenkins releases within this pom or is this something that
> needs to be addressed somewhere else? Currently the Jenkins war exposes all
> dependencies (and transitive…) to the plug-ins.

Not a POM issue. Needs to be addressed in core’s `ClassLoader`s.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0e81RLN8iK1QiBuexjHHWFV6CxQE4jir0aOs9TjQvoBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Daniel Beck]

On 19.01.2016, at 15:28, Jesse Glick  wrote:

>> 
>> are there also plans to avoid the dependency
>> hell in future Jenkins releases within this pom or is this something that
>> needs to be addressed somewhere else? Currently the Jenkins war exposes all
>> dependencies (and transitive…) to the plug-ins.
> 
> Not a POM issue. Needs to be addressed in core’s `ClassLoader`s.

FWIW we have a 2.0 labeled issue for this, but I'm not sure this is being 
planned to be implemented right now:
https://issues.jenkins-ci.org/browse/JENKINS-30685

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/AC0380A0-D024-47C1-B4EF-FA2587B97C7B%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[domi]

+100

> Am 18.01.2016 um 10:35 schrieb arodrig...@cloudbees.com:
> 
> Hi all,
> 
> Please find below a proposal for a new parent POM for Jenkins Plugins.
> 
> Motivation
> 
> The main driver to propose a revision of the parent plugin POM is to decouple 
> this artifact from the Jenkins Core:
> Simplifying the mechanism to build and test a plugin against different core 
> versions.
> Decoupling build-related aspects, such as static analysis tools, JRE 
> signatures, etc. from the baseline core versions, as they are totally 
> independent concerns, reducing the need to include otherwise common 
> configuration in each plugin POM just because we want to support and older 
> baseline.
> 
> One use case that would greatly benefit from this change is for example, 
> jenkins#1530, where it is necessary to propose API changes in core and 
> matching plugin usages. The current plugins/pom.xml does not work if you mvn 
> deploy a SNAPSHOT revision. Plugin Compatibility Testing can also benefit 
> from this change.
> 
> Approach
> 
> As stated above the approach is based in making the plugin parent POM 
> independent of the main Jenkins core project, and performing the following 
> actions:
> Make the Jenkins Core version to use configurable via a property, so that a 
> simple mvn -Djenkins.version= hpi:run is enough to compile and run a 
> plugin with a different core version. 
> Make the Jenkins Test Harness version to use also configurable (the default 
> being the same Jenkins core version), for those cases that may need it, such 
> as copyartifact#76.
> Reduce the number of Maven plugin pinned versions to those really used.
> Reduce the number of number of elements (versions, etc) overridable via 
> properties to those that have a specific reason, setting the values to those 
> intended to be used. There’s no reason to make everything overridable as the 
> parent pom evolution is now independent of the baseline Jenkins Core versions.
> 
> Other aspects included:
> Default configuration for findbugs, including the possibility of 
> automatically activating exclusions, and a property to define if findbug 
> errors should break the build (default true).
> JRE signature verification configured to the Java level defined for the build 
> (using a property as well).
> Regarding releases:
> Launching javadoc:javadoc in the prepare phase, in order to avoid the 
> inconvenience “stricter” Java 8 javadoc breaking builds in the release phase.
> Skipping tests in the release phase, cutting release build times for plugins 
> with a great number of tests.
> General cleanup.
> 
> Ok, show me the code
> 
> The current proposal is being pushed to 
> https://github.com/andresrc/plugin-pom. It is not deployed to any repository 
> yet, so in order to test it a local install is required. The artifactId is 
> intentionally changed to avoid confusion. JIRA issue [JENKINS-32493] has been 
> filed.
> 
> Some plugins have been used to verify the current proposal, including:
> Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
> Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
> Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
> Script Security: https://github.com/jenkinsci/script-security-plugin/pull/36
> Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
> 
> There is also an update on the Maven archetype at 
> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
> 
> Next Steps
> 
> After collecting feedback from the community and if there’s certain consensus 
> about going forward the next steps would be:
> Create a repository for the artifact in jenkinsci.
> Decide the final artifact maven coordinates.
> Perform a release.
> Update the documentation (wiki, etc.)
> Upgrade some plugins to use the new POM in order to drive adoption.
> Upgrade to PCT to support it.
> 
> Thanks!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/45406653-4295-4BD6-AC1B-B8624354F0A6%40fortysix.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Stephen Connolly]

+1000

We have been using the plugin parent that this is - in part - modelled on
internally in CloudBees for quite a few years now. Jesse and I have long
wanted to provide our plugin parent model to the community but we have
lacked the time to push it forward. Thanks to Andres to take the time to
convert our parent into one that can be consumed by the OSS community.

The only change I would - perhaps - make is to have the skipping of tests
in the release:perform step controllable easily for an individual plugin...
i.e. make it easy to turn on and off. Having had one or two occasions where
re-running the tests in release:perform has saved my ass... I - personally
- like to run them from release:perform and if I need to reduce the release
time I would skip the tests during release:prepare ;-)

On 18 January 2016 at 09:55, Robert Sandell  wrote:

> +100
>
> On Mon, Jan 18, 2016 at 10:35 AM,  wrote:
>
>> Hi all,
>>
>> Please find below a proposal for a new parent POM for Jenkins Plugins.
>>
>> Motivation
>>
>> The main driver to propose a revision of the parent plugin POM is to
>> decouple this artifact from the Jenkins Core:
>>
>>-
>>
>>Simplifying the mechanism to build and test a plugin against
>>different core versions.
>>-
>>
>>Decoupling build-related aspects, such as static analysis tools, JRE
>>signatures, etc. from the baseline core versions, as they are totally
>>independent concerns, reducing the need to include otherwise common
>>configuration in each plugin POM just because we want to support and older
>>baseline.
>>
>>
>> One use case that would greatly benefit from this change is for example,
>> jenkins#1530 , where it
>> is necessary to propose API changes in core and matching plugin usages. The
>> current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT
>> revision. Plugin Compatibility Testing can also benefit from this change.
>>
>> Approach
>>
>> As stated above the approach is based in making the plugin parent POM
>> independent of the main Jenkins core project, and performing the following
>> actions:
>>
>>-
>>
>>Make the Jenkins Core version to use configurable via a property, so
>>that a simple mvn -Djenkins.version= hpi:run is enough to compile
>>and run a plugin with a different core version.
>>-
>>
>>Make the Jenkins Test Harness version to use also configurable (the
>>default being the same Jenkins core version), for those cases that may 
>> need
>>it, such as copyartifact#76
>>.
>>-
>>
>>Reduce the number of Maven plugin pinned versions to those really
>>used.
>>-
>>
>>Reduce the number of number of elements (versions, etc) overridable
>>via properties to those that have a specific reason, setting the values to
>>those intended to be used. There’s no reason to make everything 
>> overridable
>>as the parent pom evolution is now independent of the baseline Jenkins 
>> Core
>>versions.
>>
>>
>> Other aspects included:
>>
>>-
>>
>>Default configuration for findbugs, including the possibility of
>>automatically activating exclusions, and a property to define if findbug
>>errors should break the build (default true).
>>-
>>
>>JRE signature verification configured to the Java level defined for
>>the build (using a property as well).
>>-
>>
>>Regarding releases:
>>-
>>
>>   Launching javadoc:javadoc in the prepare phase, in order to avoid
>>   the inconvenience “stricter” Java 8 javadoc breaking builds in the 
>> release
>>   phase.
>>   -
>>
>>   Skipping tests in the release phase, cutting release build times
>>   for plugins with a great number of tests.
>>   -
>>
>>General cleanup.
>>
>>
>> Ok, show me the code
>>
>> The current proposal is being pushed to
>> https://github.com/andresrc/plugin-pom. It is not deployed to any
>> repository yet, so in order to test it a local install is required. The
>> artifactId is intentionally changed to avoid confusion. JIRA issue
>> [JENKINS-32493]  has
>> been filed.
>>
>> Some plugins have been used to verify the current proposal, including:
>>
>>-
>>
>>Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
>>-
>>
>>Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
>>-
>>
>>Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
>>-
>>
>>Script Security:
>>https://github.com/jenkinsci/script-security-plugin/pull/36
>>-
>>
>>Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
>>
>>
>> There is also an update on the Maven archetype at
>> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
>>
>> Next Steps
>>
>> After collecting feedback from the 

[PROPOSAL] New Parent POM for Jenkins Plugins

[arodriguez]

Hi all,

Please find below a proposal for a new parent POM for Jenkins Plugins.

Motivation

The main driver to propose a revision of the parent plugin POM is to 
decouple this artifact from the Jenkins Core:

   - 
   
   Simplifying the mechanism to build and test a plugin against different 
   core versions.
   - 
   
   Decoupling build-related aspects, such as static analysis tools, JRE 
   signatures, etc. from the baseline core versions, as they are totally 
   independent concerns, reducing the need to include otherwise common 
   configuration in each plugin POM just because we want to support and older 
   baseline.
   

One use case that would greatly benefit from this change is for example, 
jenkins#1530 , where it is 
necessary to propose API changes in core and matching plugin usages. The 
current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT 
revision. Plugin Compatibility Testing can also benefit from this change.

Approach

As stated above the approach is based in making the plugin parent POM 
independent of the main Jenkins core project, and performing the following 
actions:

   - 
   
   Make the Jenkins Core version to use configurable via a property, so 
   that a simple mvn -Djenkins.version= hpi:run is enough to compile 
   and run a plugin with a different core version. 
   - 
   
   Make the Jenkins Test Harness version to use also configurable (the 
   default being the same Jenkins core version), for those cases that may need 
   it, such as copyartifact#76 
   .
   - 
   
   Reduce the number of Maven plugin pinned versions to those really used.
   - 
   
   Reduce the number of number of elements (versions, etc) overridable via 
   properties to those that have a specific reason, setting the values to 
   those intended to be used. There’s no reason to make everything overridable 
   as the parent pom evolution is now independent of the baseline Jenkins Core 
   versions.
   

Other aspects included:

   - 
   
   Default configuration for findbugs, including the possibility of 
   automatically activating exclusions, and a property to define if findbug 
   errors should break the build (default true).
   - 
   
   JRE signature verification configured to the Java level defined for the 
   build (using a property as well).
   - 
   
   Regarding releases:
   - 
  
  Launching javadoc:javadoc in the prepare phase, in order to avoid the 
  inconvenience “stricter” Java 8 javadoc breaking builds in the release 
  phase.
  - 
  
  Skipping tests in the release phase, cutting release build times for 
  plugins with a great number of tests.
  - 
   
   General cleanup.
   

Ok, show me the code

The current proposal is being pushed to 
https://github.com/andresrc/plugin-pom. It is not deployed to any 
repository yet, so in order to test it a local install is required. The 
artifactId is intentionally changed to avoid confusion. JIRA issue 
[JENKINS-32493]  has 
been filed.

Some plugins have been used to verify the current proposal, including:

   - 
   
   Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
   - 
   
   Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
   - 
   
   Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
   - 
   
   Script Security: 
   https://github.com/jenkinsci/script-security-plugin/pull/36
   - 
   
   Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
   

There is also an update on the Maven archetype at 
https://github.com/jenkinsci/maven-hpi-plugin/pull/27.

Next Steps

After collecting feedback from the community and if there’s certain 
consensus about going forward the next steps would be:

   - 
   
   Create a repository for the artifact in jenkinsci.
   - 
   
   Decide the final artifact maven coordinates.
   - 
   
   Perform a release.
   - 
   
   Update the documentation (wiki, etc.)
   - 
   
   Upgrade some plugins to use the new POM in order to drive adoption.
   - 
   
   Upgrade to PCT to support it.
   

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Robert Sandell]

+100

On Mon, Jan 18, 2016 at 10:35 AM,  wrote:

> Hi all,
>
> Please find below a proposal for a new parent POM for Jenkins Plugins.
>
> Motivation
>
> The main driver to propose a revision of the parent plugin POM is to
> decouple this artifact from the Jenkins Core:
>
>-
>
>Simplifying the mechanism to build and test a plugin against different
>core versions.
>-
>
>Decoupling build-related aspects, such as static analysis tools, JRE
>signatures, etc. from the baseline core versions, as they are totally
>independent concerns, reducing the need to include otherwise common
>configuration in each plugin POM just because we want to support and older
>baseline.
>
>
> One use case that would greatly benefit from this change is for example,
> jenkins#1530 , where it
> is necessary to propose API changes in core and matching plugin usages. The
> current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT
> revision. Plugin Compatibility Testing can also benefit from this change.
>
> Approach
>
> As stated above the approach is based in making the plugin parent POM
> independent of the main Jenkins core project, and performing the following
> actions:
>
>-
>
>Make the Jenkins Core version to use configurable via a property, so
>that a simple mvn -Djenkins.version= hpi:run is enough to compile
>and run a plugin with a different core version.
>-
>
>Make the Jenkins Test Harness version to use also configurable (the
>default being the same Jenkins core version), for those cases that may need
>it, such as copyartifact#76
>.
>-
>
>Reduce the number of Maven plugin pinned versions to those really used.
>-
>
>Reduce the number of number of elements (versions, etc) overridable
>via properties to those that have a specific reason, setting the values to
>those intended to be used. There’s no reason to make everything overridable
>as the parent pom evolution is now independent of the baseline Jenkins Core
>versions.
>
>
> Other aspects included:
>
>-
>
>Default configuration for findbugs, including the possibility of
>automatically activating exclusions, and a property to define if findbug
>errors should break the build (default true).
>-
>
>JRE signature verification configured to the Java level defined for
>the build (using a property as well).
>-
>
>Regarding releases:
>-
>
>   Launching javadoc:javadoc in the prepare phase, in order to avoid
>   the inconvenience “stricter” Java 8 javadoc breaking builds in the 
> release
>   phase.
>   -
>
>   Skipping tests in the release phase, cutting release build times
>   for plugins with a great number of tests.
>   -
>
>General cleanup.
>
>
> Ok, show me the code
>
> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom. It is not deployed to any
> repository yet, so in order to test it a local install is required. The
> artifactId is intentionally changed to avoid confusion. JIRA issue
> [JENKINS-32493]  has
> been filed.
>
> Some plugins have been used to verify the current proposal, including:
>
>-
>
>Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
>-
>
>Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
>-
>
>Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
>-
>
>Script Security:
>https://github.com/jenkinsci/script-security-plugin/pull/36
>-
>
>Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
>
>
> There is also an update on the Maven archetype at
> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
>
> Next Steps
>
> After collecting feedback from the community and if there’s certain
> consensus about going forward the next steps would be:
>
>-
>
>Create a repository for the artifact in jenkinsci.
>-
>
>Decide the final artifact maven coordinates.
>-
>
>Perform a release.
>-
>
>Update the documentation (wiki, etc.)
>-
>
>Upgrade some plugins to use the new POM in order to drive adoption.
>-
>
>Upgrade to PCT to support it.
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com
> 
> .
> For more options, visit 

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Baptiste Mathus]

+1

Interested by jenkins.version sure, but also (even more?) by the fact it
will be far easier to add things in that new parent that will be able to
propagate far far quicker than upgrading to a more recent Jenkins base a
like we have to do currently. (Example: upgrading the maven-hpi-plugin for
one, and so on).
Le 18 janv. 2016 4:34 PM, "domi"  a écrit :

> +100
>
> Am 18.01.2016 um 10:35 schrieb arodrig...@cloudbees.com:
>
> Hi all,
>
> Please find below a proposal for a new parent POM for Jenkins Plugins.
>
> Motivation
>
> The main driver to propose a revision of the parent plugin POM is to
> decouple this artifact from the Jenkins Core:
>
>-
>
>Simplifying the mechanism to build and test a plugin against different
>core versions.
>-
>
>Decoupling build-related aspects, such as static analysis tools, JRE
>signatures, etc. from the baseline core versions, as they are totally
>independent concerns, reducing the need to include otherwise common
>configuration in each plugin POM just because we want to support and older
>baseline.
>
>
> One use case that would greatly benefit from this change is for example,
> jenkins#1530 , where it
> is necessary to propose API changes in core and matching plugin usages. The
> current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT
> revision. Plugin Compatibility Testing can also benefit from this change.
>
> Approach
>
> As stated above the approach is based in making the plugin parent POM
> independent of the main Jenkins core project, and performing the following
> actions:
>
>-
>
>Make the Jenkins Core version to use configurable via a property, so
>that a simple mvn -Djenkins.version= hpi:run is enough to compile
>and run a plugin with a different core version.
>-
>
>Make the Jenkins Test Harness version to use also configurable (the
>default being the same Jenkins core version), for those cases that may need
>it, such as copyartifact#76
>.
>-
>
>Reduce the number of Maven plugin pinned versions to those really used.
>-
>
>Reduce the number of number of elements (versions, etc) overridable
>via properties to those that have a specific reason, setting the values to
>those intended to be used. There’s no reason to make everything overridable
>as the parent pom evolution is now independent of the baseline Jenkins Core
>versions.
>
>
> Other aspects included:
>
>-
>
>Default configuration for findbugs, including the possibility of
>automatically activating exclusions, and a property to define if findbug
>errors should break the build (default true).
>-
>
>JRE signature verification configured to the Java level defined for
>the build (using a property as well).
>-
>
>Regarding releases:
>-
>
>   Launching javadoc:javadoc in the prepare phase, in order to avoid
>   the inconvenience “stricter” Java 8 javadoc breaking builds in the 
> release
>   phase.
>   -
>
>   Skipping tests in the release phase, cutting release build times
>   for plugins with a great number of tests.
>   -
>
>General cleanup.
>
>
> Ok, show me the code
>
> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom. It is not deployed to any
> repository yet, so in order to test it a local install is required. The
> artifactId is intentionally changed to avoid confusion. JIRA issue
> [JENKINS-32493]  has
> been filed.
>
> Some plugins have been used to verify the current proposal, including:
>
>-
>
>Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
>-
>
>Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
>-
>
>Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
>-
>
>Script Security:
>https://github.com/jenkinsci/script-security-plugin/pull/36
>-
>
>Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
>
>
> There is also an update on the Maven archetype at
> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
>
> Next Steps
>
> After collecting feedback from the community and if there’s certain
> consensus about going forward the next steps would be:
>
>-
>
>Create a repository for the artifact in jenkinsci.
>-
>
>Decide the final artifact maven coordinates.
>-
>
>Perform a release.
>-
>
>Update the documentation (wiki, etc.)
>-
>
>Upgrade some plugins to use the new POM in order to drive adoption.
>-
>
>Upgrade to PCT to support it.
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Antonio Muñiz]

+1000 (-Djenkins.version, that single feature worth the change)

On Mon, Jan 18, 2016 at 10:35 AM,  wrote:

> Hi all,
>
> Please find below a proposal for a new parent POM for Jenkins Plugins.
>
> Motivation
>
> The main driver to propose a revision of the parent plugin POM is to
> decouple this artifact from the Jenkins Core:
>
>-
>
>Simplifying the mechanism to build and test a plugin against different
>core versions.
>-
>
>Decoupling build-related aspects, such as static analysis tools, JRE
>signatures, etc. from the baseline core versions, as they are totally
>independent concerns, reducing the need to include otherwise common
>configuration in each plugin POM just because we want to support and older
>baseline.
>
>
> One use case that would greatly benefit from this change is for example,
> jenkins#1530 , where it
> is necessary to propose API changes in core and matching plugin usages. The
> current plugins/pom.xml does not work if you mvn deploy a SNAPSHOT
> revision. Plugin Compatibility Testing can also benefit from this change.
>
> Approach
>
> As stated above the approach is based in making the plugin parent POM
> independent of the main Jenkins core project, and performing the following
> actions:
>
>-
>
>Make the Jenkins Core version to use configurable via a property, so
>that a simple mvn -Djenkins.version= hpi:run is enough to compile
>and run a plugin with a different core version.
>-
>
>Make the Jenkins Test Harness version to use also configurable (the
>default being the same Jenkins core version), for those cases that may need
>it, such as copyartifact#76
>.
>-
>
>Reduce the number of Maven plugin pinned versions to those really used.
>-
>
>Reduce the number of number of elements (versions, etc) overridable
>via properties to those that have a specific reason, setting the values to
>those intended to be used. There’s no reason to make everything overridable
>as the parent pom evolution is now independent of the baseline Jenkins Core
>versions.
>
>
> Other aspects included:
>
>-
>
>Default configuration for findbugs, including the possibility of
>automatically activating exclusions, and a property to define if findbug
>errors should break the build (default true).
>-
>
>JRE signature verification configured to the Java level defined for
>the build (using a property as well).
>-
>
>Regarding releases:
>-
>
>   Launching javadoc:javadoc in the prepare phase, in order to avoid
>   the inconvenience “stricter” Java 8 javadoc breaking builds in the 
> release
>   phase.
>   -
>
>   Skipping tests in the release phase, cutting release build times
>   for plugins with a great number of tests.
>   -
>
>General cleanup.
>
>
> Ok, show me the code
>
> The current proposal is being pushed to
> https://github.com/andresrc/plugin-pom. It is not deployed to any
> repository yet, so in order to test it a local install is required. The
> artifactId is intentionally changed to avoid confusion. JIRA issue
> [JENKINS-32493]  has
> been filed.
>
> Some plugins have been used to verify the current proposal, including:
>
>-
>
>Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
>-
>
>Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
>-
>
>Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
>-
>
>Script Security:
>https://github.com/jenkinsci/script-security-plugin/pull/36
>-
>
>Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
>
>
> There is also an update on the Maven archetype at
> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
>
> Next Steps
>
> After collecting feedback from the community and if there’s certain
> consensus about going forward the next steps would be:
>
>-
>
>Create a repository for the artifact in jenkinsci.
>-
>
>Decide the final artifact maven coordinates.
>-
>
>Perform a release.
>-
>
>Update the documentation (wiki, etc.)
>-
>
>Upgrade some plugins to use the new POM in order to drive adoption.
>-
>
>Upgrade to PCT to support it.
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a0668ee9-908d-42c1-9b18-a98751869572%40googlegroups.com
> 

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Jesse Glick]

On Mon, Jan 18, 2016 at 4:35 AM,   wrote:
> Make the Jenkins Test Harness version to use also configurable (the default
> being the same Jenkins core version)

Since updated to use 2.0, now that it exists!

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3K27ygw83ouDwjwH_Gz6ecLkdf0tngx4QfeKa21qQkug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] New Parent POM for Jenkins Plugins

[Manuel Jesús Recena Soto]

Baptiste, I totally agree with you but in this case will be very
important to keep well-documented this parent-POM.

2016-01-18 18:00 GMT+01:00 Baptiste Mathus :
> +1
>
> Interested by jenkins.version sure, but also (even more?) by the fact it
> will be far easier to add things in that new parent that will be able to
> propagate far far quicker than upgrading to a more recent Jenkins base a
> like we have to do currently. (Example: upgrading the maven-hpi-plugin for
> one, and so on).
>
> Le 18 janv. 2016 4:34 PM, "domi"  a écrit :
>>
>> +100
>>
>> Am 18.01.2016 um 10:35 schrieb arodrig...@cloudbees.com:
>>
>> Hi all,
>>
>>
>> Please find below a proposal for a new parent POM for Jenkins Plugins.
>>
>>
>> Motivation
>>
>>
>> The main driver to propose a revision of the parent plugin POM is to
>> decouple this artifact from the Jenkins Core:
>>
>> Simplifying the mechanism to build and test a plugin against different
>> core versions.
>>
>> Decoupling build-related aspects, such as static analysis tools, JRE
>> signatures, etc. from the baseline core versions, as they are totally
>> independent concerns, reducing the need to include otherwise common
>> configuration in each plugin POM just because we want to support and older
>> baseline.
>>
>>
>> One use case that would greatly benefit from this change is for example,
>> jenkins#1530, where it is necessary to propose API changes in core and
>> matching plugin usages. The current plugins/pom.xml does not work if you mvn
>> deploy a SNAPSHOT revision. Plugin Compatibility Testing can also benefit
>> from this change.
>>
>>
>> Approach
>>
>>
>> As stated above the approach is based in making the plugin parent POM
>> independent of the main Jenkins core project, and performing the following
>> actions:
>>
>> Make the Jenkins Core version to use configurable via a property, so that
>> a simple mvn -Djenkins.version= hpi:run is enough to compile and run a
>> plugin with a different core version.
>>
>> Make the Jenkins Test Harness version to use also configurable (the
>> default being the same Jenkins core version), for those cases that may need
>> it, such as copyartifact#76.
>>
>> Reduce the number of Maven plugin pinned versions to those really used.
>>
>> Reduce the number of number of elements (versions, etc) overridable via
>> properties to those that have a specific reason, setting the values to those
>> intended to be used. There’s no reason to make everything overridable as the
>> parent pom evolution is now independent of the baseline Jenkins Core
>> versions.
>>
>>
>> Other aspects included:
>>
>> Default configuration for findbugs, including the possibility of
>> automatically activating exclusions, and a property to define if findbug
>> errors should break the build (default true).
>>
>> JRE signature verification configured to the Java level defined for the
>> build (using a property as well).
>>
>> Regarding releases:
>>
>> Launching javadoc:javadoc in the prepare phase, in order to avoid the
>> inconvenience “stricter” Java 8 javadoc breaking builds in the release
>> phase.
>>
>> Skipping tests in the release phase, cutting release build times for
>> plugins with a great number of tests.
>>
>> General cleanup.
>>
>>
>> Ok, show me the code
>>
>>
>> The current proposal is being pushed to
>> https://github.com/andresrc/plugin-pom. It is not deployed to any repository
>> yet, so in order to test it a local install is required. The artifactId is
>> intentionally changed to avoid confusion. JIRA issue [JENKINS-32493] has
>> been filed.
>>
>>
>> Some plugins have been used to verify the current proposal, including:
>>
>> Branch-API: https://github.com/jenkinsci/branch-api-plugin/pull/25
>>
>> Copyartifact: https://github.com/jenkinsci/copyartifact-plugin/pull/78
>>
>> Workflow: https://github.com/jenkinsci/workflow-plugin/pull/303
>>
>> Script Security:
>> https://github.com/jenkinsci/script-security-plugin/pull/36
>>
>> Support Core: https://github.com/jenkinsci/support-core-plugin/pull/53
>>
>>
>> There is also an update on the Maven archetype at
>> https://github.com/jenkinsci/maven-hpi-plugin/pull/27.
>>
>>
>> Next Steps
>>
>>
>> After collecting feedback from the community and if there’s certain
>> consensus about going forward the next steps would be:
>>
>> Create a repository for the artifact in jenkinsci.
>>
>> Decide the final artifact maven coordinates.
>>
>> Perform a release.
>>
>> Update the documentation (wiki, etc.)
>>
>> Upgrade some plugins to use the new POM in order to drive adoption.
>>
>> Upgrade to PCT to support it.
>>
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>>