Re: [platform-ant-dev] org.eclipse.ant.core in the Equinox project

["Rafael Chaves" <Rafael_Chaves@xxxxxxxxxx>]

Thanks for pointing out those two PRs.
No, we would have the same problem if xerces is added to the AntClassLoader
classpath. If we keep the order as it is now in Eclipse, the remaining
caveat is that all plugins' exported classes will be visible to Ant scripts
(not only those belonging to plugins that provide classpath extensions),
hiding those in the URL classpath. Not sure about how bad (if any) that
is, though.

Rafael

Darin Swanson/Minneapolis/IBM@IBMUS Sent by: platform-ant-dev-admin@xxxxxxxxxxx 11/08/2003 02:16 PM Please respond to platform-ant-dev

To:        platform-ant-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ant-dev] org.eclipse.ant.core in the Equinox project

For the reasons behind the current class loading "order", please
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=33664 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=33117.

The AntClassLoader used to load from the URL classpath first (note that
you can have folders as well as JARs) and then from the plugin classloaders.

I would think you are going to need to stick to using the current ordering
to avert the problems seen in bug 33664: ensuring that the Xerces classes
are always loaded from the Xerces plugin classloader...unless you have
addressed this somewhere else in the Equinox project?

Darins

"Rafael Chaves" <Rafael_Chaves@xxxxxxxxxx> Sent by: platform-ant-dev-admin@xxxxxxxxxxx 08/08/03 06:12 AM Please respond to platform-ant-dev

To:        platform-ant-dev@xxxxxxxxxxx        cc:                Subject:        [platform-ant-dev] org.eclipse.ant.core in the Equinox project

Hello all, 

First, a little bit of context:

I am one of the Platform/Core developers working on the Equinox project.
We are porting/migrating existing 3.0 M2 plug-ins to our prototype that
runs on top of OSGi (which is a component framework), and so far we have
had good results in the process. But one of the main differences between
regular Eclipse and Eclipse on top of OSGi is that the latter is much more
conservative about giving a bundle (= plugin) classloader to other bundles.
And this is one of the requirements of the Ant support in Eclipse - tasks
can see plug-ins. 

Well, we can still do that with OSGi because we can make the Ant Core plug-in
have access to the exported classes of all bundles in the platform. The
slight diference between this approach and the current one in regular Eclipse
is that not only those plug-ins that declare extensions to Ant Core extension
points will be available to the AntClassLoader. All Eclipse classes will
be available. So, since currently the AntClassLoader looks first into plugins
(except for Ant classes) and then into the JARs classpath, we may end up
getting classes from the wrong place (from plugins instead of from JARs).
This can be avoided if we do it the other way around: first loook into
the JARs, then into the plugins. What, of course, causes a similar problem:
classes declared by plugins may be hidden by those declared in JARs.

Now, the question is: is there a problem with any of these changes (*all*
plugin classes available to the AntClassLoader, and classes being looked
first in the JARs classpath, then in plugins' classloaders)?

Thanks, 

Rafael