hmmm...
from the docs:
Plugin Class Loaders
For loading the classes of each plugin, IDEA uses a separate class loader.
This allows each plugin to use a different version of some library, even if
the same library is used by IDEA itself or another plugin.
By default, the classes not found in the plugin class loader are loaded
through the main IDEA class loader. However, it is possible to use the
depends element in plugin.xml to specify that a plugin depends on one or
more other plugins. In this case, the class loaders of those plugins will be
used for classes not found in the current plugin. This allows a plugin to
reference classes from other plugins.
This seems to say that it should only be loading it from the parent
classloader if your plugins classloader failed to locate it. Can you verify
that your plugin, when asked to load a class using the CURRENT classloader
in fact loads it from the parent classloader?
Also, obviously not a good option for distribution, but for debugging you
might consider editing this line in idea.bat/sh:
set REQUIRED_IDEA_JVM_ARGS=-Xbootclasspath/p:%IDEA_HOME%/lib/boot.jar
%IDEA_PROPERTIES_PROPERTY%
Malachi
On 3/23/06, Kirill Grouchnikov <kirillcool_at_yahoo.com> wrote:
>
> Malachi,
>
> The same order here. It's not the build that fails, the exception is at
> runtime. I guess it's something to do with the PluginClassLoader that is
> used for plugin code (which could be different from regular
> IdeaClassLoader).
>
> Kirill
>
>
> *Malachi de �lfweald <malachid_at_gmail.com>* wrote:
>
> Have you checked what order they are in in your IntelliJ module?
>
> File | Settings | Modules | (select your module) | Order/Export | (HERE)
>
> mine is:
> JDK 1.6
> <Module Source>
> <other dependant modules>
> JAXB
>
> However, I am using Maven to actually build, not IntelliJ.
>
>
> Malachi
>
> On 3/21/06, Kirill Grouchnikov <kirillcool_at_yahoo.com> wrote:
> >
> > Kohsuke,
> >
> > With the class loader being
> > com.intellij.ide.plugins.cl.PluginClassLoader (not much i can do here)
> > and four (!) versions of QName class in the classpath:
> > jar:file:/H:/IntelliJ%20IDEA%205.1/jre/lib/rt.jar!/javax/xml/namespace/QName.class
> >
> > jar:file:/C:/Documents and
> > Settings/Owner/.IntelliJIdea50/sandbox/plugins/jaxbw-plugin/lib/jsr173_1.0_api.jar!/javax/xml/namespace/QName.class
> > jar:file:/H:/IntelliJ IDEA 5.1/lib/xml-
> > apis.jar!/javax/xml/namespace/QName.class
> > jar:file:/H:/IntelliJ IDEA 5.1/lib/ant/lib/xml-
> > apis.jar!/javax/xml/namespace/QName.class
> >
> > it's obviously a complete disaster.
> >
> > Moreover, the LinkageError is thrown not always. On one computer it's
> > thrown on simple schema, on another it's not thrown on the same schema but
> > is thrown on FPML / HRXML / VoiceXML. The IDEA version is the same in both
> > cases.
> >
> > I have tried using the user classpath option and point to the rt.jar,
> > but the XJC driver fails nonetheless. Any option that comes to your mind?
> >
> > Kirill
> >
> >
> > *Kohsuke Kawaguchi < Kohsuke.Kawaguchi_at_Sun.COM>* wrote:
> >
> > Kirill Grouchnikov wrote:
> > > The jsr173_1.0_api.jar contains the version of QName without
> > > serialVersionUID (in package javax.xml.namespace). The rt.jar of JDK
> > > 5.0_06 contains QName (in the same package) with serialVersionUID.
> >
> > When you have a conflict between a class in rt.jar and a class in a jar
> > file on your classpath, rt.jar always wins, by the default Java class
> > loader delegation rule.
> >
> > So when you see a loader constraints violated like this, it must be that
> >
> > you are setting up a classloader that doesn't follow the parent-first
> > delegation rule. Such a classloader usually allows certain classes to be
> >
> > loaded from the parent (for example you need to get java.lang.String
> > from rt.jar), and if so, you can usually fix them by tweaking that list
> > to include javax.xml.namespace.
> >
> > > As i understand, the JAXB 2.0 compiled classes use the former version,
> >
> > > while at runtime the class loader may decide to use the JRE version
> > > instead - i think this is what causes the LinkageError.
> >
> > Compiling classes against one version of QName and using it against
> > another version of QName is not an issue, unless we generate code that
> > relies on serialVersionUID, which we don't.
> >
> > Even if this is an issue, you'll get a different error, not "loader
> > constraints violated" error.
> >
> > > Any reason why the QName classes are different and why JAXB 2.0 is not
> >
> > > compiled against the JDK version? I know there's little time left
> > until
> > > FCS but this seems like a serious issue.
> >
> > I don't think the compilation vs the runtime difference is the problem,
> > for the reason I mentioned. JAXB RI is compilied against JDK 5.0 (in
> > fact it's very difficult not to!)
> >
> > --
> > Kohsuke Kawaguchi
> > Sun Microsystems kohsuke.kawaguchi_at_sun.com
> >
> >
> > ------------------------------
> > Yahoo! Mail
> > Bring photos to life! New PhotoMail
> > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=39174/*http://photomail.mail.yahoo.com>makes
> > sharing a breeze.
> >
>
>
> ------------------------------
> Yahoo! Messenger with Voice.<http://us.rd.yahoo.com/mail_us/taglines/postman3/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com+%0A>PC-to-Phone calls for ridiculously low rates.
>
>