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.
(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.
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
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)
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.
--
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-de...@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.
On Thu, Dec 12, 2019 at 4:24 PM James Nord <jn...@cloudbees.com> 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.
<profile>
<id>skip</id>
<properties>
<maven.javadoc.skip>true</maven.javadoc.skip>
<pmd.skip>true</pmd.skip>
<spotbugs.skip>true</spotbugs.skip>
<checkstyle.skip>true</checkstyle.skip>
<skipTests>true</skipTests>
<skipITs>true</skipITs>
<revapi.skip>true</revapi.skip>
</properties>
</profile>
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-de...@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.
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
Veering a bit off topic: rather than sinking more effort into the
library BOM we could decide to finally prioritize JENKINS-30685,
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).
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.0My 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 removalI 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, OlegVeering 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 POMI 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).
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).
Best regards,Oleg
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)
--
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-de...@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.
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?
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@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.
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...
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/ed535b59-41cb-4637-bcdd-8bf5184c949b%40googlegroups.com
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 <o.v.n...@gmail.com>:IIUC James was about retrospectively doing releases for older versions.
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.
--
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-de...@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.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.