Thanks for all the suggestions! I ended up building an URLClassLoader that contains all the jars in an Eclipse project + the compiler output folders.
This first attempt had no parent classloader at all (each project can be trageted against a different VM version than the one used to launch Eclipse). Almost worked! Had to set the thread's context classloader to get going. But, of course the Registry created by that classloader can not be seen by code running in the context of the plugin's class loader - so I can't access the resulting Registry directly. For things to work, the plugin code needs to be able to see the Registry (without using reflection that is). Tried again, putting the plugin classloader as the parent of the special loader, still no luck. the HM in the plugin and in the project are still loaded by different loaders so the same problem exists. I could hack around all day to get "something" working but I think I've proved that using this approach as a stopgap measure to help me port Spindle to Tapestry 3.1 is a no go. Too complex and too many special cases where things will break. Back to plan B - simulating the HM internals - the slow route. Geoff On Wed, 30 Mar 2005 12:43:24 -0500, Geoff Longman <[EMAIL PROTECTED]> wrote: > I'm whipping up a demo Eclipse plugin that will create a Registry > based on the classpath of a Java project. The plugin will contain a > view that will display the contents of the Registry. > > I need a classloader that I can add the project jars and output folder > to in order to create a ClassResolver. > > But, I have never played with custom classloaders so if anyone has a > pointer to a good resource explaining how to make one I'd be grateful! > > This work is to improve my understanding of how HM works inside so I > can better approach Spindle -> Tapestry 3.1 > > Geoff > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
