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. -- 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.
