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 <o.v.nenas...@gmail.com>: > > IIUC James was about retrospectively doing releases for older versions. > https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-bom/ > <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 <o.v.n...@gmail.com <>>: >> >> And... 4.0-beta-2: >> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-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 >> <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 >> <https://github.com/jenkinsci/plugin-pom/pull/269> >> GMaven to GMavenPlus: https://github.com/jenkinsci/plugin-pom/pull/209 >> <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 >> <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 >> <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 >> <http://ci.jenkins.io/>(unable to fetch link because issues.jenkins.io >> <http://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 >> <https://github.com/search?utf8=%E2%9C%93&q=org%3Ajenkinsci++filename%3A.mvn_exec_node&type=Code&ref=advsearch&l=&l=>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 <jn...@cloudbees.com <>> 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 jenkin...@googlegroups.com <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/f1b9d76c-e7af-4618-8c2f-ba50b40dc7da%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/f1b9d76c-e7af-4618-8c2f-ba50b40dc7da%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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 > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/ed535b59-41cb-4637-bcdd-8bf5184c949b%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/ed535b59-41cb-4637-bcdd-8bf5184c949b%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/957BE2D4-93B3-46ED-A887-4B89074988C1%40gmail.com.
