On Thu, Feb 26, 2015 at 4:25 AM, Kirill <[email protected]> wrote: > Build step, introduced by plugin A, has private fields with the types from > library C. So when the appropriate job config is saved, these types are > referred in config.xml. That's probably what you suggested to avoid.
Yes, exactly. > The question is: what class loader is used to load config.xml? Probably, > uber class loader? I believe so. FWIW, when working on the NetBeans module system I eventually just made the equivalent of UberClassLoader throw a (descriptive) ClassNotFoundException if it were ever asked to load a class defined in two different modules (~ plugins). Thus, rather than having class loading succeed but *sometimes* result in a ClassCastException (depending on which plugin happened to be asked to load the class first), you could *consistently* get this error whenever both plugins were installed at once. Thus you would be alerted earlier to the need to factor out the library into its own “wrapper” plugin that both feature plugins depend on, or pass a specific (plugin) ClassLoader to any deserialization-type calls, etc. -- 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/CANfRfr32DjF1BqQa8m41dW0Nkt4NZUQwK8gij47PTi%3D1gWbZjw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
