On Thu, Apr 11, 2019 at 4:10 AM Ullrich Hafner <[email protected]> wrote: > [shading does not] prevent developers to use the shaded classes, they are > still there, just with another package name
True, but the Jenkins plugin class loader can refuse to serve such classes, so any such mistake would immediately fail at runtime. > We can add an architecture test or check style rule to prevent those imports > though. Yes, you can use the Enforcer plugin to check this sort of thing at build time. > Maybe we can use an enforcer rule […] that checks that no transitive > dependencies are used at all? Then developers need to provide explicit > dependencies. We may want to do this anyway. (The Maven plugin for NetBeans modules enforces such a rule.) > The only problem I see here is if classes of the dependency are part of the > plugin API. You can use explicit dependencies when an API includes other APIs in its signatures. It just means that clients need to declare dependencies on both, or they will not be able to compile. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0bxVjsVgN5dt7cH7Ohdi%2Bg0VZ79VKTte%3DnssT6MocdUA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
