That is what I was thinking of Gary ... seriously even just your email clearly stating that changing the plugn MANIFEST would be good. We can always write up a more formal article later.
So yeah - let's start with your great email (so we don't forget). Jody > > > Jody, > > Were you referring to posting on the GeoTools wiki at > http://docs.codehaus.org/display/GEOTDOC/Home ? > > At 01:54 PM 4/12/2007, Jody Garnett wrote: > > [snip] ... do you mind posting [your email] to the GeoTools site as > a news item? > > I can see where there might be a place for an article on "how to > bundle GeoTools in an Eclipse plug-in", but I'm not sure I'm really > qualified to do so. At this time I am still learning to use Eclipse > plug-ins/bundles and I would be a bit afraid that I might put out the > wrong information. On the other hand, once something gets out on a > wiki, it is easy for somebody else to add corrections (usually, the > tough part is getting the article out there in the first place). > > So, if that's what you're looking for, I will volunteer to do so. > And, if anyone on this mailing list has recommendations on content, > please let me know. > > Gary > > > At 01:54 PM 4/12/2007, Jody Garnett wrote: >> A message from the Isle of death then ... >>> Other the other hand, Eclipse plug-ins present their own problem. >>> This happens because the Eclipse framework depends on its own, >>> custom classloaders (actually, the OSGi classloader). Unless you >>> make special provision when building an eclipse plug-in project >>> (which are essentially the same things as OSGi bundles), the >>> classloader can't find the resources defined in the JAI extensions >>> jar files. >> Darn I was sure this was one of the first things to try ... your >> email messages is *spot on* ... do you mind posting it to the >> GeoTools site as a news item? >>> In my earlier posts I mentioned two kinds of exceptions. First, >>> there were "NoClassDefFoundError" exceptions. These were thrown in >>> the case where the classloader could not find the JAI classes it >>> needed. >> Okay that makes sense - unless you tell OSGi "please look in the >> java extensions for more classes" it won't see the jars defined >> there. By default OSGi gives you Java and just Java (not CLASSPATH, >> no extensions, no nothing). >>> I attempted to solve this problem by including the JAI jar files in >>> my plug-in... (Yes, it felt wrong at the time, but it was all I >>> could think of) . This approach got rid of the not-found exception, >>> but led to another, the "ClassCastException". >> This would also make sense - the *exact* same class from different >> class loaders will produce a ClassCastException. These problems are >> kind of like nested russian dolls. >> >> We want to see: >> >> Platform (the glue code) >> | JAI INTERFACE >> | NATIVE IMPLEMENTATION >> || GEOTOOLS IMPLEMENTATION >> || YOUR CODE >> >> (as long as the implementation and interface are using the *same* >> interface - their classloader is a "child" of the classloader that >> has the interface we are good) >> >> This is what you tried first: >> | JAI INTERFACES >> | NATIVE IMPLEMENTATIONS >> || JAI INTERFACES >> || GEOTOOLS IMPLEMENTATION >> ||| YOUR CODE >> >>> It turns out that the solution that was suggested to me was to >>> include the following line >>> >>> Eclipse-BuddyPolicy: ext >>> >>> In the manifest.mf file associated with the plug-in I built to hold >>> the GeoTools jars. This seems to have solved the problem. I know >>> that there is more to it than I've described here, but I have not >>> yet sorted out all the details. Perhaps somebody else can add the >>> missing information. >> Bah - I really wish we had gotten you to try that earlier. I am very >> glad you are up and running now. >>> Over the last couple of weeks, I've done a lot of looking into the >>> OSGi classloaders trying to understand this issue. And I have >>> concluded that the whole situation related to understanding how to >>> use OSGi/Eclipse bundles was best described by a line in a certain >>> well-known pirate movie: "it is an isle of the dead which cannot be >>> reached, except by those who already know where it is." >> Classloaders are always Evil; it is almost like they do not trust us >> or something. >> >> Java has a different idea for how to seperate things "comming real >> soon now", basically makes little mini virtiual machines. They are >> hoping to use that to segreagate their modules in the future; for now >> the rest of the world uses OSGi -and is very thankful that OSGi takes >> most of the pain of class loaders away from us. >> >> The Java Extensions thing that JAI uses can be viewed as Sun's first >> attempt to solve the problem. >> OSGi can be viewed as the popular way to solve the problem. >> And sun is working on a JVN level change to sandbox modules. >> >> Needless to say none of these solutions place nice with others. >> Jody >>> Web articles on the subject assume a certain amount of background >>> knowledge on the readers part, but completely ignores the fact that >>> if the reader had that background knowledge he wouldn't need to be >>> reading the web article. And, while I know that I haven't done a lot >>> better than that myself in writing this posting, I do hope it helps >>> a little. >>> >>> >>> Again, my thanks for the help I've received on this mailing list. >>> >>> Gary ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-gt2-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
