subject:"Jenkins Plugin pom \(future of\)"

Re: Jenkins Plugin pom (future of)

2020-01-24 Thread James Nord

Hi all,

The following versions of the jenkins-bom where all garbage and have been *
*deleted** from the repository and republished

* 2.164.1
* 2.164.2
* 2.164.3
* 2.176.1
* 2.176.2
* 2.176.3
* 2.176.4

if you have already tried to use one of these versions then you will need 
to remove the version from your local repository cache (~/.m2/repository) 
as well as any maven proxies you may be using.

I do not think these have been pulled in builds on ci.jenkins.io yet (which 
uses its own cache) but if you see the failure that Ulli saw on CI but not 
locally due to the bom then please let me know and I will file an INFRA 
ticket and try and get them cleaned up).

/James

On Tuesday, January 21, 2020 at 2:42:23 PM UTC, James Nord wrote:
>
> Never mind, several of the retrospective BOMs are garbage because I used a 
> non local parent and the resolved parent is flattened so the properties 
> where missing :-(
>
> I guess I can republish them (which is just awful because releases are 
> golden).  but I don't think there is much other good solutions.
>
> /James
>
>
> On Tuesday, January 21, 2020 at 2:32:38 PM UTC, James Nord wrote:
>>
>> do you have a PR I can checkout locally?
>>
>>
>> On Monday, January 20, 2020 at 10:13:54 PM UTC, Ullrich Hafner wrote:
>>>
>>> Ok, thanks. 2.164 would be ok for me. 
>>>
>>> Now I get:
>>>
>>> mvn validate
>>> [INFO] Scanning for projects...
>>> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>>> [ERROR] 'dependencies.dependency.version' for 
>>> org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
>>> '${access-modifier-annotation.version}'. @ 
>>> org.jenkins-ci.main:jenkins-bom:2.164.3, 
>>> /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
>>>  
>>> line 211, column 18
>>>  @ 
>>> [ERROR] The build could not read 1 project -> [Help 1]
>>> [ERROR]   
>>> [ERROR]   The project 
>>> org.jvnet.hudson.plugins:analysis-pom:2.0.0-beta-2-SNAPSHOT 
>>> (/Users/hafner/Development/git/warnings-ng-plugin-devenv/analysis-pom-plugin/pom.xml)
>>>  
>>> has 1 error
>>> [ERROR] 'dependencies.dependency.version' for 
>>> org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
>>> '${access-modifier-annotation.version}'. @ 
>>> org.jenkins-ci.main:jenkins-bom:2.164.3, 
>>> /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
>>>  
>>> line 211, column 18
>>> [ERROR] 
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the 
>>> -e switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR] 
>>> [ERROR] For more information about the errors and possible solutions, 
>>> please read the following articles:
>>> [ERROR] [Help 1] 
>>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>>>
>>>
>>> Am 20.01.2020 um 14:09 schrieb James Nord :
>>>
>>> On Friday, January 17, 2020 at 1:28:09 PM UTC, James Nord wrote:


 On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:
>
> Would its make sense to remove that part from the pom until we have 
> older Jenkins versions supported? Otherwise we will hardly find some 
> testers for the changes...
>
> Am 17.01.2020 um 12:16 schrieb Oleg Nenashev :
>
> IIUC James was about retrospectively doing releases for older versions.
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now 
> lists only 2.190.x indeed
>
>
 2.190.x was retrospectively published.  I have an internal task (now 
 up) to publish some boms for CloudBees' fixed lines (which is pretty much 
 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way 
 into repo.jenkins.org, it just got paused due to Christmas/New Year,  
 sickness and investigating 
 https://issues.jenkins-ci.org/browse/JENKINS-60754 (thanks Jesse!).

 However anything older than 2.164 should be a security risk now (I do 
 not know of any other companies performing releases with backports of 
 Jenkins security fixes) - so I am not intending to publish anything else 
 other than the 2.164 line as this enables users bad habits of upgrading 
 plugins to get new features whilst still running an insecure core, hence I 
 would recommend bumping to at least 2.164.x in the warnings-ng plugins in 
 preparation.

 of note 93% of users who are using the latest warnings-ng plugin are on 
 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect 
 this to be an issue for users of your (well at least warnings-ng) plugins.


>>> 2.164.[1-3] and 2.176.[1-4] have now been published to 
>>> repo.jenkins-ci.org.
>>>
>>> I'm not intending to publish more versions, however if there is a 
>>> demonstrable need then I can publish some more.
>>>
>>> For trying to track down changes between versions you can still use 
>>

Re: Jenkins Plugin pom (future of)

2020-01-21 Thread James Nord

Never mind, several of the retrospective BOMs are garbage because I used a 
non local parent and the resolved parent is flattened so the properties 
where missing :-(

I guess I can republish them (which is just awful because releases are 
golden).  but I don't think there is much other good solutions.

/James


On Tuesday, January 21, 2020 at 2:32:38 PM UTC, James Nord wrote:
>
> do you have a PR I can checkout locally?
>
>
> On Monday, January 20, 2020 at 10:13:54 PM UTC, Ullrich Hafner wrote:
>>
>> Ok, thanks. 2.164 would be ok for me. 
>>
>> Now I get:
>>
>> mvn validate
>> [INFO] Scanning for projects...
>> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>> [ERROR] 'dependencies.dependency.version' for 
>> org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
>> '${access-modifier-annotation.version}'. @ 
>> org.jenkins-ci.main:jenkins-bom:2.164.3, 
>> /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
>>  
>> line 211, column 18
>>  @ 
>> [ERROR] The build could not read 1 project -> [Help 1]
>> [ERROR]   
>> [ERROR]   The project 
>> org.jvnet.hudson.plugins:analysis-pom:2.0.0-beta-2-SNAPSHOT 
>> (/Users/hafner/Development/git/warnings-ng-plugin-devenv/analysis-pom-plugin/pom.xml)
>>  
>> has 1 error
>> [ERROR] 'dependencies.dependency.version' for 
>> org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
>> '${access-modifier-annotation.version}'. @ 
>> org.jenkins-ci.main:jenkins-bom:2.164.3, 
>> /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
>>  
>> line 211, column 18
>> [ERROR] 
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the 
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR] 
>> [ERROR] For more information about the errors and possible solutions, 
>> please read the following articles:
>> [ERROR] [Help 1] 
>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>>
>>
>> Am 20.01.2020 um 14:09 schrieb James Nord :
>>
>> On Friday, January 17, 2020 at 1:28:09 PM UTC, James Nord wrote:
>>>
>>>
>>> On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:

 Would its make sense to remove that part from the pom until we have 
 older Jenkins versions supported? Otherwise we will hardly find some 
 testers for the changes...

 Am 17.01.2020 um 12:16 schrieb Oleg Nenashev :

 IIUC James was about retrospectively doing releases for older versions.
 https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now 
 lists only 2.190.x indeed


>>> 2.190.x was retrospectively published.  I have an internal task (now up) 
>>> to publish some boms for CloudBees' fixed lines (which is pretty much 
>>> 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way 
>>> into repo.jenkins.org, it just got paused due to Christmas/New Year,  
>>> sickness and investigating 
>>> https://issues.jenkins-ci.org/browse/JENKINS-60754 (thanks Jesse!).
>>>
>>> However anything older than 2.164 should be a security risk now (I do 
>>> not know of any other companies performing releases with backports of 
>>> Jenkins security fixes) - so I am not intending to publish anything else 
>>> other than the 2.164 line as this enables users bad habits of upgrading 
>>> plugins to get new features whilst still running an insecure core, hence I 
>>> would recommend bumping to at least 2.164.x in the warnings-ng plugins in 
>>> preparation.
>>>
>>> of note 93% of users who are using the latest warnings-ng plugin are on 
>>> 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect 
>>> this to be an issue for users of your (well at least warnings-ng) plugins.
>>>
>>>
>> 2.164.[1-3] and 2.176.[1-4] have now been published to 
>> repo.jenkins-ci.org.
>>
>> I'm not intending to publish more versions, however if there is a 
>> demonstrable need then I can publish some more.
>>
>> For trying to track down changes between versions you can still use 
>> -Djenkins.version=x.zyz if you also specify -Djenkins-bom.version=a.abc 
>> which will not be 100% correct but should be close enough. (only ant,slf4j 
>> commons-codec and spotbugs-annotations have changed between the published 
>> versions)
>>
>> /James
>>  
>>
>> -- 
>> 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 jenkin...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/9640e383-2686-41fe-b80b-26df95d5d13e%40googlegroups.com
>>  
>> 
>> .
>>
>>
>>

-- 
You received this message because yo

Re: Jenkins Plugin pom (future of)

2020-01-21 Thread James Nord

do you have a PR I can checkout locally?


On Monday, January 20, 2020 at 10:13:54 PM UTC, Ullrich Hafner wrote:
>
> Ok, thanks. 2.164 would be ok for me. 
>
> Now I get:
>
> mvn validate
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
> '${access-modifier-annotation.version}'. @ 
> org.jenkins-ci.main:jenkins-bom:2.164.3, 
> /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
>  
> line 211, column 18
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project 
> org.jvnet.hudson.plugins:analysis-pom:2.0.0-beta-2-SNAPSHOT 
> (/Users/hafner/Development/git/warnings-ng-plugin-devenv/analysis-pom-plugin/pom.xml)
>  
> has 1 error
> [ERROR] 'dependencies.dependency.version' for 
> org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
> '${access-modifier-annotation.version}'. @ 
> org.jenkins-ci.main:jenkins-bom:2.164.3, 
> /Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
>  
> line 211, column 18
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the 
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, 
> please read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>
>
> Am 20.01.2020 um 14:09 schrieb James Nord  >:
>
> On Friday, January 17, 2020 at 1:28:09 PM UTC, James Nord wrote:
>>
>>
>> On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:
>>>
>>> Would its make sense to remove that part from the pom until we have 
>>> older Jenkins versions supported? Otherwise we will hardly find some 
>>> testers for the changes...
>>>
>>> Am 17.01.2020 um 12:16 schrieb Oleg Nenashev :
>>>
>>> IIUC James was about retrospectively doing releases for older versions.
>>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now 
>>> lists only 2.190.x indeed
>>>
>>>
>> 2.190.x was retrospectively published.  I have an internal task (now up) 
>> to publish some boms for CloudBees' fixed lines (which is pretty much 
>> 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way 
>> into repo.jenkins.org, it just got paused due to Christmas/New Year,  
>> sickness and investigating 
>> https://issues.jenkins-ci.org/browse/JENKINS-60754 (thanks Jesse!).
>>
>> However anything older than 2.164 should be a security risk now (I do not 
>> know of any other companies performing releases with backports of Jenkins 
>> security fixes) - so I am not intending to publish anything else other than 
>> the 2.164 line as this enables users bad habits of upgrading plugins to get 
>> new features whilst still running an insecure core, hence I would recommend 
>> bumping to at least 2.164.x in the warnings-ng plugins in preparation.
>>
>> of note 93% of users who are using the latest warnings-ng plugin are on 
>> 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect 
>> this to be an issue for users of your (well at least warnings-ng) plugins.
>>
>>
> 2.164.[1-3] and 2.176.[1-4] have now been published to repo.jenkins-ci.org
> .
>
> I'm not intending to publish more versions, however if there is a 
> demonstrable need then I can publish some more.
>
> For trying to track down changes between versions you can still use 
> -Djenkins.version=x.zyz if you also specify -Djenkins-bom.version=a.abc 
> which will not be 100% correct but should be close enough. (only ant,slf4j 
> commons-codec and spotbugs-annotations have changed between the published 
> versions)
>
> /James
>  
>
> -- 
> 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 jenkin...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/9640e383-2686-41fe-b80b-26df95d5d13e%40googlegroups.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/94a1c57b-7c5f-4f66-8047-07055920bf90%40googlegroups.com.

Re: Jenkins Plugin pom (future of)

2020-01-20 Thread Ullrich Hafner

Ok, thanks. 2.164 would be ok for me. 

Now I get:

mvn validate
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for 
org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
'${access-modifier-annotation.version}'. @ 
org.jenkins-ci.main:jenkins-bom:2.164.3, 
/Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
 line 211, column 18
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project 
org.jvnet.hudson.plugins:analysis-pom:2.0.0-beta-2-SNAPSHOT 
(/Users/hafner/Development/git/warnings-ng-plugin-devenv/analysis-pom-plugin/pom.xml)
 has 1 error
[ERROR] 'dependencies.dependency.version' for 
org.kohsuke:access-modifier-annotation:jar must be a valid version but is 
'${access-modifier-annotation.version}'. @ 
org.jenkins-ci.main:jenkins-bom:2.164.3, 
/Users/hafner/.m2/repository/org/jenkins-ci/main/jenkins-bom/2.164.3/jenkins-bom-2.164.3.pom,
 line 211, column 18
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException

> Am 20.01.2020 um 14:09 schrieb James Nord :
> 
> On Friday, January 17, 2020 at 1:28:09 PM UTC, James Nord wrote:
> 
> On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:
> Would its make sense to remove that part from the pom until we have older 
> Jenkins versions supported? Otherwise we will hardly find some testers for 
> the changes...
> 
>> Am 17.01.2020 um 12:16 schrieb Oleg Nenashev >:
>> 
>> IIUC James was about retrospectively doing releases for older versions.
>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ 
>>  now 
>> lists only 2.190.x indeed
>> 
> 
> 
> 2.190.x was retrospectively published.  I have an internal task (now up) to 
> publish some boms for CloudBees' fixed lines (which is pretty much 
> 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way into 
> repo.jenkins.org , it just got paused due to 
> Christmas/New Year,  sickness and investigating 
> https://issues.jenkins-ci.org/browse/JENKINS-60754 
>  (thanks Jesse!).
> 
> However anything older than 2.164 should be a security risk now (I do not 
> know of any other companies performing releases with backports of Jenkins 
> security fixes) - so I am not intending to publish anything else other than 
> the 2.164 line as this enables users bad habits of upgrading plugins to get 
> new features whilst still running an insecure core, hence I would recommend 
> bumping to at least 2.164.x in the warnings-ng plugins in preparation.
> 
> of note 93% of users who are using the latest warnings-ng plugin are on 
> 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect 
> this to be an issue for users of your (well at least warnings-ng) plugins.
> 
> 
> 2.164.[1-3] and 2.176.[1-4] have now been published to repo.jenkins-ci.org.
> 
> I'm not intending to publish more versions, however if there is a 
> demonstrable need then I can publish some more.
> 
> For trying to track down changes between versions you can still use 
> -Djenkins.version=x.zyz if you also specify -Djenkins-bom.version=a.abc which 
> will not be 100% correct but should be close enough. (only ant,slf4j 
> commons-codec and spotbugs-annotations have changed between the published 
> versions)
> 
> /James
>  
> 
> -- 
> 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/9640e383-2686-41fe-b80b-26df95d5d13e%40googlegroups.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/B774C6FF-EF06-4F6A-BD5A-9A168C6E29D1%40gmail.com.

Re: Jenkins Plugin pom (future of)

2020-01-20 Thread James Nord

On Friday, January 17, 2020 at 1:28:09 PM UTC, James Nord wrote:
>
>
> On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:
>>
>> Would its make sense to remove that part from the pom until we have older 
>> Jenkins versions supported? Otherwise we will hardly find some testers for 
>> the changes...
>>
>> Am 17.01.2020 um 12:16 schrieb Oleg Nenashev :
>>
>> IIUC James was about retrospectively doing releases for older versions.
>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now 
>> lists only 2.190.x indeed
>>
>>
> 2.190.x was retrospectively published.  I have an internal task (now up) 
> to publish some boms for CloudBees' fixed lines (which is pretty much 
> 2.164.[1-3] ) , which will be adapted for OSS jenkins and make their way 
> into repo.jenkins.org, it just got paused due to Christmas/New Year,  
> sickness and investigating 
> https://issues.jenkins-ci.org/browse/JENKINS-60754 (thanks Jesse!).
>
> However anything older than 2.164 should be a security risk now (I do not 
> know of any other companies performing releases with backports of Jenkins 
> security fixes) - so I am not intending to publish anything else other than 
> the 2.164 line as this enables users bad habits of upgrading plugins to get 
> new features whilst still running an insecure core, hence I would recommend 
> bumping to at least 2.164.x in the warnings-ng plugins in preparation.
>
> of note 93% of users who are using the latest warnings-ng plugin are on 
> 2.190.1 or higher and 99% are on 2.164.1 or higher, so I would not expect 
> this to be an issue for users of your (well at least warnings-ng) plugins.
>
>
2.164.[1-3] and 2.176.[1-4] have now been published to repo.jenkins-ci.org.

I'm not intending to publish more versions, however if there is a 
demonstrable need then I can publish some more.

For trying to track down changes between versions you can still use 
-Djenkins.version=x.zyz if you also specify -Djenkins-bom.version=a.abc 
which will not be 100% correct but should be close enough. (only ant,slf4j 
commons-codec and spotbugs-annotations have changed between the published 
versions)

/James
 

-- 
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/9640e383-2686-41fe-b80b-26df95d5d13e%40googlegroups.com.

Re: Jenkins Plugin pom (future of)

2020-01-17 Thread James Nord



On Friday, January 17, 2020 at 12:46:15 PM UTC, Ullrich Hafner wrote:
>
> Would its make sense to remove that part from the pom until we have older 
> Jenkins versions supported? Otherwise we will hardly find some testers for 
> the changes...
>
> Am 17.01.2020 um 12:16 schrieb Oleg Nenashev  >:
>
> IIUC James was about retrospectively doing releases for older versions.
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now 
> lists only 2.190.x indeed
>
> On Friday, January 17, 2020 at 11:49:19 AM UTC+1, Ullrich Hafner wrote:
>>
>> While testing the new pom it appears that it requires at least LTS 
>> 2.190.x (due to the jenkins-bom dependency).
>> Isn’t this version too new?
>>
>> Am 30.12.2019 um 16:31 schrieb Oleg Nenashev :
>>
>> And... 4.0-beta-2: 
>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-2
>> All discussed changes have been integrated. It would be great to have 
>> some testing before we cut final 4.0.
>> If someone has more ideas which you would like to integrate, please 
>> suggest in the thread (or submit pull requests!)
>>
>> I wonder if it would make sense to integrate SpotBugs (and CheckStyle) 
>>> into the verify phase as well. So plugin developers will get the results 
>>> automatically by running mvn verify (or mvn install).
>>>
>>
>>  This one has not been implemented yet IIUC. +1 for doing so
>>
>> BR, Oleg
>>
>>
>> On Friday, December 27, 2019 at 2:23:15 PM UTC+1, Oleg Nenashev wrote:
>>>
>>> 4.0-beta-1 is here: 
>>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 . 
>>> It includes only the pul lrequest from James Nord, but I will integrate 
>>> other changes into beta-2.
>>>
>>> Regarding the Group ID change, I retract my proposal. Although it would 
>>> be useful in general, the scope of changes in docs and development tools is 
>>> way too big.
>>> My particular concerns like Dependabot can be addressed in Dependabot 
>>> Core itself, it will take much less time.
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Monday, December 23, 2019 at 3:42:44 PM UTC+1, Oleg Nenashev wrote:

 Looks like there is a consensus in this thread about the new POM, apart 
 from "minor" implementation details

 What is my suggestion is:

1. I cut the 3.55 release of Plugin POM today
2. We start integration 4.0 changes into master. First versions 
will be "beta". It will stay in Beta until we all agree that the 
 desired 
breaking changes are done
3. Initial changes to be merged
   - Bulk PR from James Nord: 
   https://github.com/jenkinsci/plugin-pom/pull/269 
   - GMaven to GMavenPlus: 
   https://github.com/jenkinsci/plugin-pom/pull/209
   - JTH 2.58 with breaking changes in HTML Unit: 
   https://github.com/jenkinsci/plugin-pom/pull/271
   - (?) Group ID change. Will submit a PR for discussion
4. If a new release of 3.x is needed, we will create a new branch 
for it

 BR, Oleg

 On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:
>
> I have a draft PR at 
> https://github.com/jenkinsci/plugin-pom/pull/269/files which leaves 
> the javascript builders untouched.
>
> Shall we take the rest of the conversation there (but answered here 
> for completeness) ?
>
> On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
>>
>> I am in favor of a Plugin POM 4.0 with a major cleanup. My 
>> recommendation would be to start from a 4.0-rc so that we can do some 
>> evaluation and incremental cleanup before 4.0
>>
>> My suggestions:
>>
>>- Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
>>plugin-pom as now). It would protect users from picking up the RC and 
>> give 
>>us some space to introduce more parent POMs if needed. 
>>
>> not sure why that helps in this case.  
>
>>
>>- It will also allow to workaround the issue with Dependabot 
>>where filtering out "org.jenkins-ci.plugins*" leads to the Parent POM 
>> not 
>>being updated. And we definitely do want it to be updated (and not so 
>> much 
>>- for plugin minimum dependencies)
>>
>>
> Won't that cause dependabot to not update the parent when it can - 
> because the groupId has changed?
>
>  
>
>>
>>- I will be also fine if 4.0 uses 2.204+ as a required baseline 
>>so that we remove the Java 7- remainders (e.g. `
>>org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to 
>>finalize the Java 11-only plugins support PR (core patches are done 
>> in 
>>2.160.x, but we still have no tooling to deliver such plugins to 
>> [custom?] 
>>update centers).
>>
>>
> not yet done - will do
>  
>
>>
>>- Bump Maven requirement to 3.6.0

Re: Jenkins Plugin pom (future of)

2020-01-17 Thread Ullrich Hafner

Would its make sense to remove that part from the pom until we have older 
Jenkins versions supported? Otherwise we will hardly find some testers for the 
changes...

> Am 17.01.2020 um 12:16 schrieb Oleg Nenashev :
> 
> IIUC James was about retrospectively doing releases for older versions.
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ 
>  now 
> lists only 2.190.x indeed
> 
> On Friday, January 17, 2020 at 11:49:19 AM UTC+1, Ullrich Hafner wrote:
> While testing the new pom it appears that it requires at least LTS 2.190.x 
> (due to the jenkins-bom dependency).
> Isn’t this version too new?
> 
>> Am 30.12.2019 um 16:31 schrieb Oleg Nenashev >:
>> 
>> And... 4.0-beta-2: 
>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-2 
>> 
>> All discussed changes have been integrated. It would be great to have some 
>> testing before we cut final 4.0.
>> If someone has more ideas which you would like to integrate, please suggest 
>> in the thread (or submit pull requests!)
>> 
>> I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into 
>> the verify phase as well. So plugin developers will get the results 
>> automatically by running mvn verify (or mvn install).
>> 
>>  This one has not been implemented yet IIUC. +1 for doing so
>> 
>> BR, Oleg
>> 
>> 
>> On Friday, December 27, 2019 at 2:23:15 PM UTC+1, Oleg Nenashev wrote:
>> 4.0-beta-1 is here: 
>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 
>>  . 
>> It includes only the pul lrequest from James Nord, but I will integrate 
>> other changes into beta-2.
>> 
>> Regarding the Group ID change, I retract my proposal. Although it would be 
>> useful in general, the scope of changes in docs and development tools is way 
>> too big.
>> My particular concerns like Dependabot can be addressed in Dependabot Core 
>> itself, it will take much less time.
>> 
>> Best regards,
>> Oleg
>> 
>> On Monday, December 23, 2019 at 3:42:44 PM UTC+1, Oleg Nenashev wrote:
>> Looks like there is a consensus in this thread about the new POM, apart from 
>> "minor" implementation details
>> 
>> What is my suggestion is:
>> I cut the 3.55 release of Plugin POM today
>> We start integration 4.0 changes into master. First versions will be "beta". 
>> It will stay in Beta until we all agree that the desired breaking changes 
>> are done
>> Initial changes to be merged
>> Bulk PR from James Nord: https://github.com/jenkinsci/plugin-pom/pull/269 
>>  
>> GMaven to GMavenPlus: https://github.com/jenkinsci/plugin-pom/pull/209 
>> 
>> JTH 2.58 with breaking changes in HTML Unit: 
>> https://github.com/jenkinsci/plugin-pom/pull/271 
>> 
>> (?) Group ID change. Will submit a PR for discussion
>> If a new release of 3.x is needed, we will create a new branch for it
>> BR, Oleg
>> 
>> On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:
>> I have a draft PR at https://github.com/jenkinsci/plugin-pom/pull/269/files 
>>  which leaves the 
>> javascript builders untouched.
>> 
>> Shall we take the rest of the conversation there (but answered here for 
>> completeness) ?
>> 
>> On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
>> I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation 
>> would be to start from a 4.0-rc so that we can do some evaluation and 
>> incremental cleanup before 4.0
>> 
>> My suggestions:
>> Change its groupId to "io.jenkins.main.pom" (and artifact ID = plugin-pom as 
>> now). It would protect users from picking up the RC and give us some space 
>> to introduce more parent POMs if needed. 
>> not sure why that helps in this case.  
>> It will also allow to workaround the issue with Dependabot where filtering 
>> out "org.jenkins-ci.plugins*" leads to the Parent POM not being updated. And 
>> we definitely do want it to be updated (and not so much - for plugin minimum 
>> dependencies)
>> 
>> Won't that cause dependabot to not update the parent when it can - because 
>> the groupId has changed?
>> 
>>  
>> I will be also fine if 4.0 uses 2.204+ as a required baseline so that we 
>> remove the Java 7- remainders (e.g. `org.codehaus.mojo.signature` for Java 
>> 1.5 o_O). It would help to finalize the Java 11-only plugins support PR 
>> (core patches are done in 2.160.x, but we still have no tooling to deliver 
>> such plugins to [custom?] update centers).
>> 
>> not yet done - will do
>>  
>> Bump Maven requirement to 3.6.0+ or so. There is no point in supporting 
>> 3.3.1 (and 3.5.4 for incrementals)
>> 
>> 3.6.3 is required

Re: Jenkins Plugin pom (future of)

2020-01-17 Thread Oleg Nenashev

IIUC James was about retrospectively doing releases for older versions.
https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ now 
lists only 2.190.x indeed

On Friday, January 17, 2020 at 11:49:19 AM UTC+1, Ullrich Hafner wrote:
>
> While testing the new pom it appears that it requires at least LTS 2.190.x 
> (due to the jenkins-bom dependency).
> Isn’t this version too new?
>
> Am 30.12.2019 um 16:31 schrieb Oleg Nenashev  >:
>
> And... 4.0-beta-2: 
> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-2
> All discussed changes have been integrated. It would be great to have some 
> testing before we cut final 4.0.
> If someone has more ideas which you would like to integrate, please 
> suggest in the thread (or submit pull requests!)
>
> I wonder if it would make sense to integrate SpotBugs (and CheckStyle) 
>> into the verify phase as well. So plugin developers will get the results 
>> automatically by running mvn verify (or mvn install).
>>
>
>  This one has not been implemented yet IIUC. +1 for doing so
>
> BR, Oleg
>
>
> On Friday, December 27, 2019 at 2:23:15 PM UTC+1, Oleg Nenashev wrote:
>>
>> 4.0-beta-1 is here: 
>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 . 
>> It includes only the pul lrequest from James Nord, but I will integrate 
>> other changes into beta-2.
>>
>> Regarding the Group ID change, I retract my proposal. Although it would 
>> be useful in general, the scope of changes in docs and development tools is 
>> way too big.
>> My particular concerns like Dependabot can be addressed in Dependabot 
>> Core itself, it will take much less time.
>>
>> Best regards,
>> Oleg
>>
>> On Monday, December 23, 2019 at 3:42:44 PM UTC+1, Oleg Nenashev wrote:
>>>
>>> Looks like there is a consensus in this thread about the new POM, apart 
>>> from "minor" implementation details
>>>
>>> What is my suggestion is:
>>>
>>>1. I cut the 3.55 release of Plugin POM today
>>>2. We start integration 4.0 changes into master. First versions will 
>>>be "beta". It will stay in Beta until we all agree that the desired 
>>>breaking changes are done
>>>3. Initial changes to be merged
>>>   - Bulk PR from James Nord: 
>>>   https://github.com/jenkinsci/plugin-pom/pull/269 
>>>   - GMaven to GMavenPlus: 
>>>   https://github.com/jenkinsci/plugin-pom/pull/209
>>>   - JTH 2.58 with breaking changes in HTML Unit: 
>>>   https://github.com/jenkinsci/plugin-pom/pull/271
>>>   - (?) Group ID change. Will submit a PR for discussion
>>>4. If a new release of 3.x is needed, we will create a new branch 
>>>for it
>>>
>>> BR, Oleg
>>>
>>> On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:

 I have a draft PR at 
 https://github.com/jenkinsci/plugin-pom/pull/269/files which leaves 
 the javascript builders untouched.

 Shall we take the rest of the conversation there (but answered here for 
 completeness) ?

 On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
>
> I am in favor of a Plugin POM 4.0 with a major cleanup. My 
> recommendation would be to start from a 4.0-rc so that we can do some 
> evaluation and incremental cleanup before 4.0
>
> My suggestions:
>
>- Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
>plugin-pom as now). It would protect users from picking up the RC and 
> give 
>us some space to introduce more parent POMs if needed. 
>
> not sure why that helps in this case.  

>
>- It will also allow to workaround the issue with Dependabot where 
>filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not 
> being 
>updated. And we definitely do want it to be updated (and not so much - 
> for 
>plugin minimum dependencies)
>
>
 Won't that cause dependabot to not update the parent when it can - 
 because the groupId has changed?

  

>
>- I will be also fine if 4.0 uses 2.204+ as a required baseline so 
>that we remove the Java 7- remainders (e.g. `
>org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to 
>finalize the Java 11-only plugins support PR (core patches are done in 
>2.160.x, but we still have no tooling to deliver such plugins to 
> [custom?] 
>update centers).
>
>
 not yet done - will do
  

>
>- Bump Maven requirement to 3.6.0+ or so. There is no point in 
>supporting 3.3.1 (and 3.5.4 for incrementals)
>
>
 3.6.3 is required for excludes wildcard matching which is in use in the 
 wild - so I guess a push would maek sense - but its not yet on 
 ci.jenkins.io(unable to fetch link because issues.jenkins.io is 
 unhappy)
  

>
>- Remove JGit profiles (YAGNI?)
>
> they've already gone 
  

>

Re: Jenkins Plugin pom (future of)

2020-01-17 Thread Ullrich Hafner

While testing the new pom it appears that it requires at least LTS 2.190.x (due 
to the jenkins-bom dependency).
Isn’t this version too new?

> Am 30.12.2019 um 16:31 schrieb Oleg Nenashev :
> 
> And... 4.0-beta-2: 
> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-2 
> 
> All discussed changes have been integrated. It would be great to have some 
> testing before we cut final 4.0.
> If someone has more ideas which you would like to integrate, please suggest 
> in the thread (or submit pull requests!)
> 
> I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into 
> the verify phase as well. So plugin developers will get the results 
> automatically by running mvn verify (or mvn install).
> 
>  This one has not been implemented yet IIUC. +1 for doing so
> 
> BR, Oleg
> 
> 
> On Friday, December 27, 2019 at 2:23:15 PM UTC+1, Oleg Nenashev wrote:
> 4.0-beta-1 is here: 
> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 
>  . It 
> includes only the pul lrequest from James Nord, but I will integrate other 
> changes into beta-2.
> 
> Regarding the Group ID change, I retract my proposal. Although it would be 
> useful in general, the scope of changes in docs and development tools is way 
> too big.
> My particular concerns like Dependabot can be addressed in Dependabot Core 
> itself, it will take much less time.
> 
> Best regards,
> Oleg
> 
> On Monday, December 23, 2019 at 3:42:44 PM UTC+1, Oleg Nenashev wrote:
> Looks like there is a consensus in this thread about the new POM, apart from 
> "minor" implementation details
> 
> What is my suggestion is:
> I cut the 3.55 release of Plugin POM today
> We start integration 4.0 changes into master. First versions will be "beta". 
> It will stay in Beta until we all agree that the desired breaking changes are 
> done
> Initial changes to be merged
> Bulk PR from James Nord: https://github.com/jenkinsci/plugin-pom/pull/269 
>  
> GMaven to GMavenPlus: https://github.com/jenkinsci/plugin-pom/pull/209 
> 
> JTH 2.58 with breaking changes in HTML Unit: 
> https://github.com/jenkinsci/plugin-pom/pull/271 
> 
> (?) Group ID change. Will submit a PR for discussion
> If a new release of 3.x is needed, we will create a new branch for it
> BR, Oleg
> 
> On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:
> I have a draft PR at https://github.com/jenkinsci/plugin-pom/pull/269/files 
>  which leaves the 
> javascript builders untouched.
> 
> Shall we take the rest of the conversation there (but answered here for 
> completeness) ?
> 
> On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
> I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation 
> would be to start from a 4.0-rc so that we can do some evaluation and 
> incremental cleanup before 4.0
> 
> My suggestions:
> Change its groupId to "io.jenkins.main.pom" (and artifact ID = plugin-pom as 
> now). It would protect users from picking up the RC and give us some space to 
> introduce more parent POMs if needed. 
> not sure why that helps in this case.  
> It will also allow to workaround the issue with Dependabot where filtering 
> out "org.jenkins-ci.plugins*" leads to the Parent POM not being updated. And 
> we definitely do want it to be updated (and not so much - for plugin minimum 
> dependencies)
> 
> Won't that cause dependabot to not update the parent when it can - because 
> the groupId has changed?
> 
>  
> I will be also fine if 4.0 uses 2.204+ as a required baseline so that we 
> remove the Java 7- remainders (e.g. `org.codehaus.mojo.signature` for Java 
> 1.5 o_O). It would help to finalize the Java 11-only plugins support PR (core 
> patches are done in 2.160.x, but we still have no tooling to deliver such 
> plugins to [custom?] update centers).
> 
> not yet done - will do
>  
> Bump Maven requirement to 3.6.0+ or so. There is no point in supporting 3.3.1 
> (and 3.5.4 for incrementals)
> 
> 3.6.3 is required for excludes wildcard matching which is in use in the wild 
> - so I guess a push would maek sense - but its not yet on ci.jenkins.io 
> (unable to fetch link because issues.jenkins.io 
>  is unhappy)
>  
> Remove JGit profiles (YAGNI?)
> they've already gone 
>  
> Keep profiles for integration tests and JMH
> JMH has not gone - not sure what it you where on about there was no profile 
> for plugins but its now there by default.
> 
>  
> MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended way to 
> manage test dependencies.
> Erm...  though shalt not manage dependencies in a profil

Re: Jenkins Plugin pom (future of)

2019-12-30 Thread Oleg Nenashev

And... 4.0-beta-2: 
https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-2
All discussed changes have been integrated. It would be great to have some 
testing before we cut final 4.0.
If someone has more ideas which you would like to integrate, please suggest 
in the thread (or submit pull requests!)

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into 
> the verify phase as well. So plugin developers will get the results 
> automatically by running mvn verify (or mvn install).
>

 This one has not been implemented yet IIUC. +1 for doing so

BR, Oleg


On Friday, December 27, 2019 at 2:23:15 PM UTC+1, Oleg Nenashev wrote:
>
> 4.0-beta-1 is here: 
> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 . 
> It includes only the pul lrequest from James Nord, but I will integrate 
> other changes into beta-2.
>
> Regarding the Group ID change, I retract my proposal. Although it would be 
> useful in general, the scope of changes in docs and development tools is 
> way too big.
> My particular concerns like Dependabot can be addressed in Dependabot Core 
> itself, it will take much less time.
>
> Best regards,
> Oleg
>
> On Monday, December 23, 2019 at 3:42:44 PM UTC+1, Oleg Nenashev wrote:
>>
>> Looks like there is a consensus in this thread about the new POM, apart 
>> from "minor" implementation details
>>
>> What is my suggestion is:
>>
>>1. I cut the 3.55 release of Plugin POM today
>>2. We start integration 4.0 changes into master. First versions will 
>>be "beta". It will stay in Beta until we all agree that the desired 
>>breaking changes are done
>>3. Initial changes to be merged
>>   - Bulk PR from James Nord: 
>>   https://github.com/jenkinsci/plugin-pom/pull/269 
>>   - GMaven to GMavenPlus: 
>>   https://github.com/jenkinsci/plugin-pom/pull/209
>>   - JTH 2.58 with breaking changes in HTML Unit: 
>>   https://github.com/jenkinsci/plugin-pom/pull/271
>>   - (?) Group ID change. Will submit a PR for discussion
>>4. If a new release of 3.x is needed, we will create a new branch for 
>>it
>>
>> BR, Oleg
>>
>> On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:
>>>
>>> I have a draft PR at 
>>> https://github.com/jenkinsci/plugin-pom/pull/269/files which leaves the 
>>> javascript builders untouched.
>>>
>>> Shall we take the rest of the conversation there (but answered here for 
>>> completeness) ?
>>>
>>> On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:

 I am in favor of a Plugin POM 4.0 with a major cleanup. My 
 recommendation would be to start from a 4.0-rc so that we can do some 
 evaluation and incremental cleanup before 4.0

 My suggestions:

- Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
plugin-pom as now). It would protect users from picking up the RC and 
 give 
us some space to introduce more parent POMs if needed. 

 not sure why that helps in this case.  
>>>

- It will also allow to workaround the issue with Dependabot where 
filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not 
 being 
updated. And we definitely do want it to be updated (and not so much - 
 for 
plugin minimum dependencies)


>>> Won't that cause dependabot to not update the parent when it can - 
>>> because the groupId has changed?
>>>
>>>  
>>>

- I will be also fine if 4.0 uses 2.204+ as a required baseline so 
that we remove the Java 7- remainders (e.g. `
org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to 
finalize the Java 11-only plugins support PR (core patches are done in 
2.160.x, but we still have no tooling to deliver such plugins to 
 [custom?] 
update centers).


>>> not yet done - will do
>>>  
>>>

- Bump Maven requirement to 3.6.0+ or so. There is no point in 
supporting 3.3.1 (and 3.5.4 for incrementals)


>>> 3.6.3 is required for excludes wildcard matching which is in use in the 
>>> wild - so I guess a push would maek sense - but its not yet on 
>>> ci.jenkins.io (unable to fetch link because issues.jenkins.io is 
>>> unhappy)
>>>  
>>>

- Remove JGit profiles (YAGNI?)

 they've already gone 
>>>  
>>>

- Keep profiles for integration tests and JMH

 JMH has not gone - not sure what it you where on about there was no 
>>> profile for plugins but its now there by default.
>>>
>>>  
>>>

- MAYBE: Introduce an opt-in profile for Plugin BOM as a 
recommended way to manage test dependencies.

 Erm...  though shalt not manage dependencies in a profile  that's 
>>> what started this mess :)
>>>
>>>
- This makes sense if and only if we find that the Plugin BOM is 
maintainable enough to keep it running

 There is

Re: Jenkins Plugin pom (future of)

2019-12-27 Thread Oleg Nenashev

4.0-beta-1 is here: 
https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0-beta-1 . It 
includes only the pul lrequest from James Nord, but I will integrate other 
changes into beta-2.

Regarding the Group ID change, I retract my proposal. Although it would be 
useful in general, the scope of changes in docs and development tools is 
way too big.
My particular concerns like Dependabot can be addressed in Dependabot Core 
itself, it will take much less time.

Best regards,
Oleg

On Monday, December 23, 2019 at 3:42:44 PM UTC+1, Oleg Nenashev wrote:
>
> Looks like there is a consensus in this thread about the new POM, apart 
> from "minor" implementation details
>
> What is my suggestion is:
>
>1. I cut the 3.55 release of Plugin POM today
>2. We start integration 4.0 changes into master. First versions will 
>be "beta". It will stay in Beta until we all agree that the desired 
>breaking changes are done
>3. Initial changes to be merged
>   - Bulk PR from James Nord: 
>   https://github.com/jenkinsci/plugin-pom/pull/269 
>   - GMaven to GMavenPlus: 
>   https://github.com/jenkinsci/plugin-pom/pull/209
>   - JTH 2.58 with breaking changes in HTML Unit: 
>   https://github.com/jenkinsci/plugin-pom/pull/271
>   - (?) Group ID change. Will submit a PR for discussion
>4. If a new release of 3.x is needed, we will create a new branch for 
>it
>
> BR, Oleg
>
> On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:
>>
>> I have a draft PR at 
>> https://github.com/jenkinsci/plugin-pom/pull/269/files which leaves the 
>> javascript builders untouched.
>>
>> Shall we take the rest of the conversation there (but answered here for 
>> completeness) ?
>>
>> On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
>>>
>>> I am in favor of a Plugin POM 4.0 with a major cleanup. My 
>>> recommendation would be to start from a 4.0-rc so that we can do some 
>>> evaluation and incremental cleanup before 4.0
>>>
>>> My suggestions:
>>>
>>>- Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
>>>plugin-pom as now). It would protect users from picking up the RC and 
>>> give 
>>>us some space to introduce more parent POMs if needed. 
>>>
>>> not sure why that helps in this case.  
>>
>>>
>>>- It will also allow to workaround the issue with Dependabot where 
>>>filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not 
>>> being 
>>>updated. And we definitely do want it to be updated (and not so much - 
>>> for 
>>>plugin minimum dependencies)
>>>
>>>
>> Won't that cause dependabot to not update the parent when it can - 
>> because the groupId has changed?
>>
>>  
>>
>>>
>>>- I will be also fine if 4.0 uses 2.204+ as a required baseline so 
>>>that we remove the Java 7- remainders (e.g. `
>>>org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to 
>>>finalize the Java 11-only plugins support PR (core patches are done in 
>>>2.160.x, but we still have no tooling to deliver such plugins to 
>>> [custom?] 
>>>update centers).
>>>
>>>
>> not yet done - will do
>>  
>>
>>>
>>>- Bump Maven requirement to 3.6.0+ or so. There is no point in 
>>>supporting 3.3.1 (and 3.5.4 for incrementals)
>>>
>>>
>> 3.6.3 is required for excludes wildcard matching which is in use in the 
>> wild - so I guess a push would maek sense - but its not yet on 
>> ci.jenkins.io (unable to fetch link because issues.jenkins.io is unhappy)
>>  
>>
>>>
>>>- Remove JGit profiles (YAGNI?)
>>>
>>> they've already gone 
>>  
>>
>>>
>>>- Keep profiles for integration tests and JMH
>>>
>>> JMH has not gone - not sure what it you where on about there was no 
>> profile for plugins but its now there by default.
>>
>>  
>>
>>>
>>>- MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended 
>>>way to manage test dependencies.
>>>
>>> Erm...  though shalt not manage dependencies in a profile  that's 
>> what started this mess :)
>>
>>
>>>- This makes sense if and only if we find that the Plugin BOM is 
>>>maintainable enough to keep it running
>>>
>>> There is also the support for javascript builds, but a quick search  
 of
  
 repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) 
 that 
 use this (the javascript ecosystem moves much faster so I would argue this 
 is better handled by documentation or another possibly another pom) so I 
 think this should be a candidate for removal

>>>
>>> I would highly recommend to bring it up in the UX SIG before going 
>>> forward with it. Since there is a planned effort to streamline and revamp 
>>> the Jenkins Frontend, it might be a good topic for discussion.
>>> I see no problem if a new Parent POM was introduced for such purpose, 
>>> but -0.5 for just

Re: Jenkins Plugin pom (future of)

2019-12-23 Thread Oleg Nenashev

Looks like there is a consensus in this thread about the new POM, apart 
from "minor" implementation details

What is my suggestion is:

   1. I cut the 3.55 release of Plugin POM today
   2. We start integration 4.0 changes into master. First versions will be 
   "beta". It will stay in Beta until we all agree that the desired breaking 
   changes are done
   3. Initial changes to be merged
  - Bulk PR from James 
  Nord: https://github.com/jenkinsci/plugin-pom/pull/269 
  - GMaven to GMavenPlus: 
  https://github.com/jenkinsci/plugin-pom/pull/209
  - JTH 2.58 with breaking changes in HTML Unit: 
  https://github.com/jenkinsci/plugin-pom/pull/271
  - (?) Group ID change. Will submit a PR for discussion
   4. If a new release of 3.x is needed, we will create a new branch for it

BR, Oleg

On Tuesday, December 17, 2019 at 1:10:56 AM UTC+1, James Nord wrote:
>
> I have a draft PR at 
> https://github.com/jenkinsci/plugin-pom/pull/269/files which leaves the 
> javascript builders untouched.
>
> Shall we take the rest of the conversation there (but answered here for 
> completeness) ?
>
> On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
>>
>> I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation 
>> would be to start from a 4.0-rc so that we can do some evaluation and 
>> incremental cleanup before 4.0
>>
>> My suggestions:
>>
>>- Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
>>plugin-pom as now). It would protect users from picking up the RC and 
>> give 
>>us some space to introduce more parent POMs if needed. 
>>
>> not sure why that helps in this case.  
>
>>
>>- It will also allow to workaround the issue with Dependabot where 
>>filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not being 
>>updated. And we definitely do want it to be updated (and not so much - 
>> for 
>>plugin minimum dependencies)
>>
>>
> Won't that cause dependabot to not update the parent when it can - because 
> the groupId has changed?
>
>  
>
>>
>>- I will be also fine if 4.0 uses 2.204+ as a required baseline so 
>>that we remove the Java 7- remainders (e.g. `
>>org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to 
>>finalize the Java 11-only plugins support PR (core patches are done in 
>>2.160.x, but we still have no tooling to deliver such plugins to 
>> [custom?] 
>>update centers).
>>
>>
> not yet done - will do
>  
>
>>
>>- Bump Maven requirement to 3.6.0+ or so. There is no point in 
>>supporting 3.3.1 (and 3.5.4 for incrementals)
>>
>>
> 3.6.3 is required for excludes wildcard matching which is in use in the 
> wild - so I guess a push would maek sense - but its not yet on 
> ci.jenkins.io (unable to fetch link because issues.jenkins.io is unhappy)
>  
>
>>
>>- Remove JGit profiles (YAGNI?)
>>
>> they've already gone 
>  
>
>>
>>- Keep profiles for integration tests and JMH
>>
>> JMH has not gone - not sure what it you where on about there was no 
> profile for plugins but its now there by default.
>
>  
>
>>
>>- MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended 
>>way to manage test dependencies.
>>
>> Erm...  though shalt not manage dependencies in a profile  that's 
> what started this mess :)
>
>
>>- This makes sense if and only if we find that the Plugin BOM is 
>>maintainable enough to keep it running
>>
>> There is also the support for javascript builds, but a quick search  
>>> of
>>>  
>>> repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
>>> use this (the javascript ecosystem moves much faster so I would argue this 
>>> is better handled by documentation or another possibly another pom) so I 
>>> think this should be a candidate for removal
>>>
>>
>> I would highly recommend to bring it up in the UX SIG before going 
>> forward with it. Since there is a planned effort to streamline and revamp 
>> the Jenkins Frontend, it might be a good topic for discussion.
>> I see no problem if a new Parent POM was introduced for such purpose, but 
>> -0.5 for just removing is (see Jesse's concern). We could also keep the 
>> profile for now and kick the topic down the road.
>>
>>
> kicked it down the road.
>  
>
>> BR, Oleg
>>
>>
>> Veering a bit off topic: rather than sinking more effort into the
>>> library BOM we could decide to finally prioritize JENKINS-30685,
>>
>>
>> I would say it is a separate topic . It is a pretty big change inside the 
>> core, and Parent POM
>>
>> I wonder if it would make sense to integrate SpotBugs (and CheckStyle) 
>>> into the verify phase as well. So plugin developers will get the results 
>>> automatically by running mvn verify (or mvn install).
>>>
>>
>>
> not sure where that comment was made - spotbugs is already in the verify 
> sta

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread James Nord

I have a draft PR at https://github.com/jenkinsci/plugin-pom/pull/269/files 
which 
leaves the javascript builders untouched.

Shall we take the rest of the conversation there (but answered here for 
completeness) ?

On Monday, December 16, 2019 at 10:16:52 PM UTC, Oleg Nenashev wrote:
>
> I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation 
> would be to start from a 4.0-rc so that we can do some evaluation and 
> incremental cleanup before 4.0
>
> My suggestions:
>
>- Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
>plugin-pom as now). It would protect users from picking up the RC and give 
>us some space to introduce more parent POMs if needed. 
>
> not sure why that helps in this case.  

>
>- It will also allow to workaround the issue with Dependabot where 
>filtering out "org.jenkins-ci.plugins*" leads to the Parent POM not being 
>updated. And we definitely do want it to be updated (and not so much - for 
>plugin minimum dependencies)
>
>
Won't that cause dependabot to not update the parent when it can - because 
the groupId has changed?

 

>
>- I will be also fine if 4.0 uses 2.204+ as a required baseline so 
>that we remove the Java 7- remainders (e.g. `
>org.codehaus.mojo.signature` for Java 1.5 o_O). It would help to 
>finalize the Java 11-only plugins support PR (core patches are done in 
>2.160.x, but we still have no tooling to deliver such plugins to [custom?] 
>update centers).
>
>
not yet done - will do
 

>
>- Bump Maven requirement to 3.6.0+ or so. There is no point in 
>supporting 3.3.1 (and 3.5.4 for incrementals)
>
>
3.6.3 is required for excludes wildcard matching which is in use in the 
wild - so I guess a push would maek sense - but its not yet on 
ci.jenkins.io (unable to fetch link because issues.jenkins.io is unhappy)
 

>
>- Remove JGit profiles (YAGNI?)
>
> they've already gone 
 

>
>- Keep profiles for integration tests and JMH
>
> JMH has not gone - not sure what it you where on about there was no 
profile for plugins but its now there by default.

 

>
>- MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended 
>way to manage test dependencies.
>
> Erm...  though shalt not manage dependencies in a profile  that's what 
started this mess :)


>- This makes sense if and only if we find that the Plugin BOM is 
>maintainable enough to keep it running
>
> There is also the support for javascript builds, but a quick search  
>> of
>>  
>> repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
>> use this (the javascript ecosystem moves much faster so I would argue this 
>> is better handled by documentation or another possibly another pom) so I 
>> think this should be a candidate for removal
>>
>
> I would highly recommend to bring it up in the UX SIG before going forward 
> with it. Since there is a planned effort to streamline and revamp the 
> Jenkins Frontend, it might be a good topic for discussion.
> I see no problem if a new Parent POM was introduced for such purpose, but 
> -0.5 for just removing is (see Jesse's concern). We could also keep the 
> profile for now and kick the topic down the road.
>
>
kicked it down the road.
 

> BR, Oleg
>
>
> Veering a bit off topic: rather than sinking more effort into the
>> library BOM we could decide to finally prioritize JENKINS-30685,
>
>
> I would say it is a separate topic . It is a pretty big change inside the 
> core, and Parent POM
>
> I wonder if it would make sense to integrate SpotBugs (and CheckStyle) 
>> into the verify phase as well. So plugin developers will get the results 
>> automatically by running mvn verify (or mvn install).
>>
>
>
not sure where that comment was made - spotbugs is already in the verify 
stage?
 

>  
>  
>
> On Monday, December 16, 2019 at 4:19:13 PM UTC+1, Jesse Glick wrote:
>>
>> On Mon, Dec 16, 2019 at 7:14 AM James Nord  wrote: 
>> >> we cannot easily use another POM as Maven does not support multiple 
>> inheritance 
>> > 
>> > Sure we can,   we can have a base parent, then we have another parent 
>> with specialisation that has the base parent as it's own pom. 
>> > Then you pick your parent from the possible options. (generic, 
>> specialist etc) 
>>
>> Right, you can do this, so long as there is at most one useful 
>> addition needed by a given plugin. As soon as you want to (say) manage 
>> JS asset bundling and use managed versions of PowerMock in the same 
>> plugin, you are going to need to start copying and pasting. 
>>
>> > the Jenkins APIs expose some of the internals of its libraries as API. 
>> > (acegi security, jelly, XStream ) 
>>
>> Yes these are all effectively part of the Jenkins core API surface. 
>> But they should not be controlled by a BOM either, because a plugin 
>> should not be attempting to

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread Oleg Nenashev

I am in favor of a Plugin POM 4.0 with a major cleanup. My recommendation 
would be to start from a 4.0-rc so that we can do some evaluation and 
incremental cleanup before 4.0

My suggestions:

   - Change its groupId to "io.jenkins.main.pom" (and artifact ID = 
   plugin-pom as now). It would protect users from picking up the RC and give 
   us some space to introduce more parent POMs if needed. It will also allow 
   to workaround the issue with Dependabot where filtering out 
   "org.jenkins-ci.plugins*" leads to the Parent POM not being updated. And we 
   definitely do want it to be updated (and not so much - for plugin minimum 
   dependencies)
   - I will be also fine if 4.0 uses 2.204+ as a required baseline so that 
   we remove the Java 7- remainders (e.g. `org.codehaus.mojo.signature` for 
   Java 1.5 o_O). It would help to finalize the Java 11-only plugins support 
   PR (core patches are done in 2.160.x, but we still have no tooling to 
   deliver such plugins to [custom?] update centers).
   - Bump Maven requirement to 3.6.0+ or so. There is no point in 
   supporting 3.3.1 (and 3.5.4 for incrementals)
   - Remove JGit profiles (YAGNI?)
   - Keep profiles for integration tests and JMH
   - MAYBE: Introduce an opt-in profile for Plugin BOM as a recommended way 
   to manage test dependencies. This makes sense if and only if we find that 
   the Plugin BOM is maintainable enough to keep it running

There is also the support for javascript builds, but a quick search  
> of
>  
> repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
> use this (the javascript ecosystem moves much faster so I would argue this 
> is better handled by documentation or another possibly another pom) so I 
> think this should be a candidate for removal
>

I would highly recommend to bring it up in the UX SIG before going forward 
with it. Since there is a planned effort to streamline and revamp the 
Jenkins Frontend, it might be a good topic for discussion.
I see no problem if a new Parent POM was introduced for such purpose, but 
-0.5 for just removing is (see Jesse's concern). We could also keep the 
profile for now and kick the topic down the road.

BR, Oleg


Veering a bit off topic: rather than sinking more effort into the
> library BOM we could decide to finally prioritize JENKINS-30685,


I would say it is a separate topic . It is a pretty big change inside the 
core, and Parent POM

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into 
> the verify phase as well. So plugin developers will get the results 
> automatically by running mvn verify (or mvn install).
>

 
 

On Monday, December 16, 2019 at 4:19:13 PM UTC+1, Jesse Glick wrote:
>
> On Mon, Dec 16, 2019 at 7:14 AM James Nord  > wrote: 
> >> we cannot easily use another POM as Maven does not support multiple 
> inheritance 
> > 
> > Sure we can,   we can have a base parent, then we have another parent 
> with specialisation that has the base parent as it's own pom. 
> > Then you pick your parent from the possible options. (generic, 
> specialist etc) 
>
> Right, you can do this, so long as there is at most one useful 
> addition needed by a given plugin. As soon as you want to (say) manage 
> JS asset bundling and use managed versions of PowerMock in the same 
> plugin, you are going to need to start copying and pasting. 
>
> > the Jenkins APIs expose some of the internals of its libraries as API. 
> > (acegi security, jelly, XStream ) 
>
> Yes these are all effectively part of the Jenkins core API surface. 
> But they should not be controlled by a BOM either, because a plugin 
> should not be attempting to use its own copies. The libraries which 
> are eligible for _either_ JENKINS-30685 or BOM management are those 
> which are used as implementation details and which plugins would 
> plausibly want to override, such as Guava. 
>
> >  you can not easily have multiple slf4j implementations either 
>
> This one seems to be in a special category if I understand correctly 
> (but I probably do not). 
>
> > I can make improvements in the plugin pom and use the benefits 
> immediately, and I would expect a lot more breakage in changing the class 
> loaders. 
>
> Yes, in the short term anyway. 
>

-- 
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/3aea07f5-2f2a-4a0f-930b-a95f3d02c944%40googlegroups.com.

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread Jesse Glick

On Mon, Dec 16, 2019 at 7:14 AM James Nord  wrote:
>> we cannot easily use another POM as Maven does not support multiple 
>> inheritance
>
> Sure we can,   we can have a base parent, then we have another parent with 
> specialisation that has the base parent as it's own pom.
> Then you pick your parent from the possible options. (generic, specialist etc)

Right, you can do this, so long as there is at most one useful
addition needed by a given plugin. As soon as you want to (say) manage
JS asset bundling and use managed versions of PowerMock in the same
plugin, you are going to need to start copying and pasting.

> the Jenkins APIs expose some of the internals of its libraries as API.
> (acegi security, jelly, XStream )

Yes these are all effectively part of the Jenkins core API surface.
But they should not be controlled by a BOM either, because a plugin
should not be attempting to use its own copies. The libraries which
are eligible for _either_ JENKINS-30685 or BOM management are those
which are used as implementation details and which plugins would
plausibly want to override, such as Guava.

>  you can not easily have multiple slf4j implementations either

This one seems to be in a special category if I understand correctly
(but I probably do not).

> I can make improvements in the plugin pom and use the benefits immediately, 
> and I would expect a lot more breakage in changing the class loaders.

Yes, in the short term anyway.

-- 
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/CANfRfr2Gsrmgs0xuMmS1uFxhp3qM25%2BBAfcLrtCazpVfbt0kZg%40mail.gmail.com.

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread Ullrich Hafner



> Am 13.12.2019 um 00:08 schrieb Jeff Thompson :
> 
> On 12/12/19 2:23 PM, James Nord wrote:
>> For those of you that are not aware the jenkins bom is trying to solve to 
>> problem of not consuming newer versions of libraries that are shipped in 
>> Jenkins core as this can cause unexpected failure at runtime, and to make 
>> keeping the versions used in step with the Jenkins version targeted in the 
>> POM.
> I really like the goals you are pursuing here, to produce a parent pom that 
> is more consistent and reduces problems at build and run time. It's a hard 
> task to get everything lined up right and it does require "breaking some 
> eggs".
>> (skipTests is a surefire flag but we abuse it to also skip spotbugs which 
>> when you know how maven works becomes surprising)
> I would really like to break that egg. That overloading is just confusing and 
> it causes problems when people aren't aware of its non-standard behavior. If 
> people need they can create local aliases or whatever to achieve the same 
> result. It shouldn't be in a parent pom like this.
>> we have findbugs properties as well (to cope with people that are have used 
>> a findbugs flag in their build and we now use spotbugs.
> I'm in favor of breaking this egg, also. Findbugs is dead and has been for a 
> while. We're past the point of needing to support a migration period.
> 
+1 on removing findbugs and using spotbugs

I wonder if it would make sense to integrate SpotBugs (and CheckStyle) into the 
verify phase as well. So plugin developers will get the results automatically 
by running mvn verify (or mvn install).
This will make the buildPlugin step also simpler, see discussions in:
- https://issues.jenkins.io/browse/INFRA-2294 

- https://issues.jenkins.io/browse/INFRA-2000 

- https://github.com/jenkins-infra/pipeline-library/pull/121 



-- 
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/9BA8A1F8-CCD3-4EC2-A9F2-E26E3CDF8E53%40gmail.com.

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread Ullrich Hafner



> Am 16.12.2019 um 13:14 schrieb James Nord :
> 
> 
> 
> On Friday, December 13, 2019 at 3:34:05 PM UTC, Jesse Glick wrote:
> On Thu, Dec 12, 2019 at 4:24 PM James Nord > wrote: 
> > There is also the support for javascript builds, but a quick search of 
> > repos showed only 29 repositories … that use this … so I would argue this 
> > is better handled by documentation or another possibly another pom 
> 
> 29 repositories is quite a lot, I think. If this is handled by 
> “documentation” then we will have no straightforward way of making 
> sure those plugins use up-to-date mojos or best practices.
> 
> it does not look like the javascript parts have been updated in over 3 years, 
> I doubt we are following best practices at all here, but I accept your 
> alternative POV.
> 
>  
> And we 
> cannot easily use another POM as Maven does not support multiple 
> inheritance (without a somewhat scary extension that IDEs and other 
> tools would not grok).
> 
> 
> Sure we can,   we can have a base parent, then we have another parent with 
> specialisation that has the base parent as it's own pom.  
> Then you pick your parent from the possible options. (generic, specialist etc)
> 
>  
> I understand your desire to simplify, but this 
> sounds like it could just be making more maintenance work for us 
> overall. No strong opinion about it though, beyond Devin’s request 
> that a POM update must not _silently_ cease to package JS assets. 
> 
> ack
>  
> 
> Regarding `-DskipTests`, I would perhaps propose some profile like 
> `-Pquick` that skips running tests, SpotBugs, Enforcer, and anything 
> else that is a sort of a test: i.e., could break the build but could 
> not affect the content of artifacts if the build passes. I wish this 
> were built in to / standardized by Maven itself so that mojos and IDEs 
> and everything else could agree on a single flag. (Note that you still 
> need to _compile_ tests, at least if `no-test-jar=false`.) 
> 
> 
> ok - seems trivial enough (so long as all the mojos have a skip option)

I use:


  skip
  
true
true
true
true
true
true
true
  


>  
> 
> Veering a bit off topic: rather than sinking more effort into the 
> library BOM we could decide to finally prioritize JENKINS-30685, 
> hiding all these things from the plugin “classpath” at both compile 
> time and runtime. Core could then use whatever library versions it 
> felt like with no impact on plugins, no BOM would be needed, and those 
> plugins actually requiring (say) Guava would need to declare a 
> dependency on some version of some library wrapper plugin once they 
> update `jenkins.version` past the split. I do not believe there is 
> anything all that technically difficult here, except to the extent 
> that functional tests might get messy (JENKINS-41827); it is more 
> about summoning the will to do it and follow up with various issues 
> afterwards. 
> 
> 
> I disagree with you in thinking this is easier - especially as the Jenkins 
> APIs expose some of the internals of its libraries as API.
> (acegi security, jelly 
> ,
>  XStream  
> )
>   you can not easily have multiple slf4j implementations either - it's going 
> to blow up at some point.
> thus even if you did do this isolation I beleive there is still a need for 
> some form of jenkins-bom (perhaps with a more limited set of libraries).
> There is also the issue that a plugin may include some library and may depend 
> on another plugin, at somepoint later this other plugin also depends on the 
> library but at an incompatable version and it becomes part of its API.
>  
> I'm happy to be proven wring but for the moment I can make improvements in 
> the plugin pom and use the benefits immediately, and I would expect a lot 
> more breakage in changing the class loaders.
> 
> -- 
> 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/1a8dcb62-349f-4f1e-b3dd-32a125869c13%40googlegroups.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/jenkinsc

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread James Nord

As far as I can tell 
https://github.com/jenkinsci/plugin-pom/blob/master/pom.xml#L120-L126 no 
longer needs to have the type set to executable-war (can just be type war) 
(original commit 

 and 
hpi-plugin code 
,
 
mode code 
)
 
or am I missing something?

/James

On Thursday, December 12, 2019 at 9:23:55 PM UTC, James Nord wrote:
>
> Hi all,
>
> firstly apologies about the recent messiness with consuming the jenkins 
> bom  in the 
> plugin-pom .
>
> For those of you that are not aware the jenkins bom is trying to solve to 
> problem of not consuming newer versions of libraries that are shipped in 
> Jenkins core as this can cause unexpected failure at runtime, and to make 
> keeping the versions used in step with the Jenkins version targeted in the 
> POM.
>
> Now the previous attempt revealed a couple of issues mainly that you 
> should not enable dependencies in a profile when the resulting pom is to be 
> consumed later.  Also Profile activation (applies to incrementals) via 
> environment/system properties is a bad idea when that changes what can be 
> consumed/produced. The reason for this is when you want to aggregate 
> several plugins in a build to perform batch testing of all their masters 
> and some want to use one profile and others don't (but you can only set one 
> property for the whole of the aggregation).
>
> So to get a parent that works for plugins I need to break some eggs.  And 
> this is the email about what eggs we want to also break, and which eggs are 
> created by Fabergé and are too valuable to throw away. 
>
> for my part we have a lot of properties that are overloaded in profiles 
> (skipTests is a surefire flag but we abuse it to also skip spotbugs which 
> when you know how maven works becomes surprising), we have findbugs 
> properties as well (to cope with people that are have used a findbugs flag 
> in their build and we now use spotbugs.
>
> There is also the support for javascript builds, but a quick search 
> of
>  
> repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
> use this (the javascript ecosystem moves much faster so I would argue this 
> is better handled by documentation or another possibly another pom) so I 
> think this should be a candidate for removal.
>
> Given we are breaking eggs, I do not see a reason for the new parent not 
> to use the jenkins-bom unconditionally.
>
> Is there any other legacy that people think can be cleaned up / removed, 
> or other points of view that people want to put forward before a PR lands 
> as a surprise?
>
> Regards
>
> /James
>
>
>

-- 
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/a0510bff-9502-4684-977c-e770a4fd45b6%40googlegroups.com.

Re: Jenkins Plugin pom (future of)

2019-12-16 Thread James Nord

On Friday, December 13, 2019 at 3:34:05 PM UTC, Jesse Glick wrote:
>
> On Thu, Dec 12, 2019 at 4:24 PM James Nord  > wrote: 
> > There is also the support for javascript builds, but a quick search of 
> repos showed only 29 repositories … that use this … so I would argue this 
> is better handled by documentation or another possibly another pom 
>
> 29 repositories is quite a lot, I think. If this is handled by 
> “documentation” then we will have no straightforward way of making 
> sure those plugins use up-to-date mojos or best practices. 

it does not look like the javascript parts have been updated in over 3 
years, I doubt we are following best practices at all here, but I accept 
your alternative POV.

> And we 
> cannot easily use another POM as Maven does not support multiple 
> inheritance (without a somewhat scary extension that IDEs and other 
> tools would not grok).

Sure we can,   we can have a base parent, then we have another parent with 
specialisation that has the base parent as it's own pom.  
Then you pick your parent from the possible options. (generic, specialist 
etc)

> I understand your desire to simplify, but this 
> sounds like it could just be making more maintenance work for us 
> overall. No strong opinion about it though, beyond Devin’s request 
> that a POM update must not _silently_ cease to package JS assets. 
>

ack

>
> Regarding `-DskipTests`, I would perhaps propose some profile like 
> `-Pquick` that skips running tests, SpotBugs, Enforcer, and anything 
> else that is a sort of a test: i.e., could break the build but could 
> not affect the content of artifacts if the build passes. I wish this 
> were built in to / standardized by Maven itself so that mojos and IDEs 
> and everything else could agree on a single flag. (Note that you still 
> need to _compile_ tests, at least if `no-test-jar=false`.) 
>

ok - seems trivial enough (so long as all the mojos have a skip option)

>
> Veering a bit off topic: rather than sinking more effort into the 
> library BOM we could decide to finally prioritize JENKINS-30685, 
> hiding all these things from the plugin “classpath” at both compile 
> time and runtime. Core could then use whatever library versions it 
> felt like with no impact on plugins, no BOM would be needed, and those 
> plugins actually requiring (say) Guava would need to declare a 
> dependency on some version of some library wrapper plugin once they 
> update `jenkins.version` past the split. I do not believe there is 
> anything all that technically difficult here, except to the extent 
> that functional tests might get messy (JENKINS-41827); it is more 
> about summoning the will to do it and follow up with various issues 
> afterwards. 
>

I disagree with you in thinking this is easier - especially as the Jenkins 
APIs expose some of the internals of its libraries as API.
(acegi security, jelly 
,

XStream  
)

you can not easily have multiple slf4j implementations either - it's going 
to blow up at some point.
thus even if you did do this isolation I beleive there is still a need for 
some form of jenkins-bom (perhaps with a more limited set of libraries).
There is also the issue that a plugin may include some library and may 
depend on another plugin, at somepoint later this other plugin also depends 
on the library but at an incompatable version and it becomes part of its 
API.

I'm happy to be proven wring but for the moment I can make improvements in 
the plugin pom and use the benefits immediately, and I would expect a lot 
more breakage in changing the class loaders.

-- 
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/1a8dcb62-349f-4f1e-b3dd-32a125869c13%40googlegroups.com.

Re: Jenkins Plugin pom (future of)

2019-12-13 Thread Jesse Glick

On Thu, Dec 12, 2019 at 4:24 PM James Nord wrote:
> There is also the support for javascript builds, but a quick search of repos
> showed only 29 repositories … that use this … so I would argue this is better
> handled by documentation or another possibly another pom

29 repositories is quite a lot, I think. If this is handled by
“documentation” then we will have no straightforward way of making
sure those plugins use up-to-date mojos or best practices. And we
cannot easily use another POM as Maven does not support multiple
inheritance (without a somewhat scary extension that IDEs and other
tools would not grok). I understand your desire to simplify, but this
sounds like it could just be making more maintenance work for us
overall. No strong opinion about it though, beyond Devin’s request
that a POM update must not _silently_ cease to package JS assets.

Regarding `-DskipTests`, I would perhaps propose some profile like
`-Pquick` that skips running tests, SpotBugs, Enforcer, and anything
else that is a sort of a test: i.e., could break the build but could
not affect the content of artifacts if the build passes. I wish this
were built in to / standardized by Maven itself so that mojos and IDEs
and everything else could agree on a single flag. (Note that you still
need to _compile_ tests, at least if `no-test-jar=false`.)

Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,
hiding all these things from the plugin “classpath” at both compile
time and runtime. Core could then use whatever library versions it
felt like with no impact on plugins, no BOM would be needed, and those
plugins actually requiring (say) Guava would need to declare a
dependency on some version of some library wrapper plugin once they
update `jenkins.version` past the split. I do not believe there is
anything all that technically difficult here, except to the extent
that functional tests might get messy (JENKINS-41827); it is more
about summoning the will to do it and follow up with various issues
afterwards.

--
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/CANfRfr2_th7uMJzGsKMq4kkvSY3PRCbP%3D-EXaiSQ0ikFo7Psmg%40mail.gmail.com.

Re: Jenkins Plugin pom (future of)

2019-12-13 Thread Devin Nusbaum

Some housekeeping in the plugin POM sounds good to me.

> for my part we have a lot of properties that are overloaded in profiles 
> (skipTests is a surefire flag but we abuse it to also skip spotbugs which 
> when you know how maven works becomes surprising)

I was always a bit confused by that behavior, but never realized it was 
specific to the plugin POM. +1 for removing it.

> There is also the support for javascript builds, but a quick search  
> of
>  repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
> use this (the javascript ecosystem moves much faster so I would argue this is 
> better handled by documentation or another possibly another pom) so I think 
> this should be a candidate for removal.

I agree that given how infrequently this profile is used, it makes sense to 
remove it. I do have one concern though - If one of the plugins currently using 
the profile updates to a version of the plugin POM in which it has been 
removed, will the plugin’s build continue to work silently even though the 
produced artifacts will be broken? (I saw this happen at least once after 
https://github.com/jenkinsci/plugin-pom/pull/36 
 changed the profile used for 
this functionality)? If so, would it be possible to replace the profile with 
one that just fails the build if `.mvn_exec_node` is present to avoid this 
issue, since if downstream plugins copied the profile into their POM, it would 
make more sense for them to activate it by default anyway?

Devin

> On Dec 12, 2019, at 16:23, James Nord  wrote:
> 
> Hi all,
> 
> firstly apologies about the recent messiness with consuming the jenkins bom 
>  in the plugin-pom 
> .
> 
> For those of you that are not aware the jenkins bom is trying to solve to 
> problem of not consuming newer versions of libraries that are shipped in 
> Jenkins core as this can cause unexpected failure at runtime, and to make 
> keeping the versions used in step with the Jenkins version targeted in the 
> POM.
> 
> Now the previous attempt revealed a couple of issues mainly that you should 
> not enable dependencies in a profile when the resulting pom is to be consumed 
> later.  Also Profile activation (applies to incrementals) via 
> environment/system properties is a bad idea when that changes what can be 
> consumed/produced. The reason for this is when you want to aggregate several 
> plugins in a build to perform batch testing of all their masters and some 
> want to use one profile and others don't (but you can only set one property 
> for the whole of the aggregation).
> 
> So to get a parent that works for plugins I need to break some eggs.  And 
> this is the email about what eggs we want to also break, and which eggs are 
> created by Fabergé and are too valuable to throw away. 
> 
> for my part we have a lot of properties that are overloaded in profiles 
> (skipTests is a surefire flag but we abuse it to also skip spotbugs which 
> when you know how maven works becomes surprising), we have findbugs 
> properties as well (to cope with people that are have used a findbugs flag in 
> their build and we now use spotbugs.
> 
> There is also the support for javascript builds, but a quick search  
> of
>  repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that 
> use this (the javascript ecosystem moves much faster so I would argue this is 
> better handled by documentation or another possibly another pom) so I think 
> this should be a candidate for removal.
> 
> Given we are breaking eggs, I do not see a reason for the new parent not to 
> use the jenkins-bom unconditionally.
> 
> Is there any other legacy that people think can be cleaned up / removed, or 
> other points of view that people want to put forward before a PR lands as a 
> surprise?
> 
> Regards
> 
> /James
> 
> 
> 
> -- 
> 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/2ce40a15-fe85-475a-8218-255140d4e1f5%40googlegroups.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 jenkins

Re: Jenkins Plugin pom (future of)

2019-12-12 Thread Jeff Thompson

On 12/12/19 2:23 PM, James Nord wrote:
For those of you that are not aware the jenkins bom is trying to solve
to problem of not consuming newer versions of libraries that are
shipped in Jenkins core as this can cause unexpected failure at
runtime, and to make keeping the versions used in step with the
Jenkins version targeted in the POM.
I really like the goals you are pursuing here, to produce a parent pom
that is more consistent and reduces problems at build and run time. It's
a hard task to get everything lined up right and it does require
"breaking some eggs".
(skipTests is a surefire flag but we abuse it to also skip spotbugs
which when you know how maven works becomes surprising)
I would really like to break that egg. That overloading is just
confusing and it causes problems when people aren't aware of its
non-standard behavior. If people need they can create local aliases or
whatever to achieve the same result. It shouldn't be in a parent pom
like this.
we have findbugs properties as well (to cope with people that are have
used a findbugs flag in their build and we now use spotbugs.

I'm in favor of breaking this egg, also. Findbugs is dead and has been
for a while. We're past the point of needing to support a migration period.

Jeff

--
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/082a905a-9370-aec9-3065-9a0cad80f3bf%40cloudbees.com.

Jenkins Plugin pom (future of)

2019-12-12 Thread James Nord

Hi all,

firstly apologies about the recent messiness with consuming the jenkins bom
in the plugin-pom
.

For those of you that are not aware the jenkins bom is trying to solve to
problem of not consuming newer versions of libraries that are shipped in
Jenkins core as this can cause unexpected failure at runtime, and to make
keeping the versions used in step with the Jenkins version targeted in the
POM.

Now the previous attempt revealed a couple of issues mainly that you should
not enable dependencies in a profile when the resulting pom is to be
consumed later. Also Profile activation (applies to incrementals) via
environment/system properties is a bad idea when that changes what can be
consumed/produced. The reason for this is when you want to aggregate
several plugins in a build to perform batch testing of all their masters
and some want to use one profile and others don't (but you can only set one
property for the whole of the aggregation).

So to get a parent that works for plugins I need to break some eggs. And
this is the email about what eggs we want to also break, and which eggs are
created by Fabergé and are too valuable to throw away.

for my part we have a lot of properties that are overloaded in profiles
(skipTests is a surefire flag but we abuse it to also skip spotbugs which
when you know how maven works becomes surprising), we have findbugs
properties as well (to cope with people that are have used a findbugs flag
in their build and we now use spotbugs.

There is also the support for javascript builds, but a quick search
of

repos showed only 29 repositories (22 in jenkinsci and 7 in cloudbees) that
use this (the javascript ecosystem moves much faster so I would argue this
is better handled by documentation or another possibly another pom) so I
think this should be a candidate for removal.

Given we are breaking eggs, I do not see a reason for the new parent not to
use the jenkins-bom unconditionally.

Is there any other legacy that people think can be cleaned up / removed, or
other points of view that people want to put forward before a PR lands as a
surprise?

Regards

/James

--
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/2ce40a15-fe85-475a-8218-255140d4e1f5%40googlegroups.com.

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Re: Jenkins Plugin pom (future of)

Jenkins Plugin pom (future of)

23 matches

Site Navigation

Mail list logo

Footer information