[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] Easier setup in Eclipse: here it is.
|
Hi Ringo -
I've tested your nifty plugins locally, and they work with one small change.
The plugin.xml file for your org.jdom plugin must include the following text:
<requires>
<import plugin="org.apache.xerces"/>
</requires>
Otherwise, there's a ClassDefNotFound exception when JDOM is used, because
it can't find Xerces.
With that change - it works great! (I also had to change all of the
Stellation plugin.xml files, of course).
I'm still looking into the SWT classpath variable issue.
Its certainly possible to add org.eclipse.swt as a plugin dependency of the
Stellation UI plugin, but this doesn't set up the build-time classpath
directly. One can get Eclipse to set the SWT build path for a specific
platform, as follows:
* Open PDE manifest editor
* Go to Dependencies pane
* Highlight the entry for org.eclipse.swt
* Right-click to get the context menu, then select Compute Build Path.
On my Linux system (where I use Motif currently), this adds a classpath
variable for ECLIPSE_HOME/plugins/org.eclipse.swt.motif.2.0.0/ws/motif/swt.jar.
Presumably, when I load the same project into my Win2K system, I will get a
classpath error and have to ask Eclipse to recompute
the build path -- for each plugin using SWT. Since this changes
the plugin .classpath file, it will be flagged as a change by the SCM
system, and likely cause endless rippling as developers work on different
platforms. Not good.
I must be missing something, since I doubt the SWT team would have allowed
a problem like this to persist. Perhaps the problem doesn't manifest if
one is self-hosting (e.g. has org.eclipse.swt as a project in the local
workspace? Tried it - no -- that didn't work.).
It's worth noting that the org.eclipse.swt plugin.xml file has exports the
swt jar as "$ws$/swt.jar". The magic $ws$ variable is translated, at
plugin load time, to the appropriate platform-specific path. However, this
is of no apparent use in a compile-time classpath....
In R1.0, a copy of the swt win32 jar was kept in a fixed location for use
in buildtime classpaths. I don't know what the R2 solution is.
Any ideas?
- Jim
At 10:10 AM 7/17/02 -0400, Mark C. Chu-Carroll wrote:
On Wednesday 17 July 2002 10:03 am, Ringo De Smet wrote:
> --- "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx> wrote:
> > *Very* cool. Thanks!
>
> Mark, let me know if things don't work as expected.
> After applying the changes in your working environment, does it also
> solve the SWT variable problem for you guys?
I haven't tested it yet... I'm trying to finish expunging a nasty bug. Once
I'm done, I'll give it a test, and let you know if it works. (Or perhaps
one of the other Watson folk can give it a shot while I'm busy? Jim,
any chance you have time to give this a try?)
--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
