Re: [equinox-dev] Framework extensions must be co-located with the org.e

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

That sounds reasonable. If you haven't already why not open a bug as this feels like it's more complex than it should be.
Another approach that might be worth looking at is to extend the symantics of "osgi.framework.extensions" to allow paths (similar to osgi.bundles)

"Miles Sabin" ---11/28/2008 12:13:01 PM---Hi folks,

From:	"Miles Sabin" <miles@xxxxxxxxxxxxxx>
To:	equinox-dev@xxxxxxxxxxx
Date:	11/28/2008 12:13 PM
Subject:	[equinox-dev] Framework extensions must be co-located with the org.eclipse.osgi bundle?

---

Hi folks,

I'm working on the Eclipse plugin for the Scala programming language,

  http://www.scala-lang.org/

As I expect most of you probably know, Scala is a "Java compatible"
language with excellent interoperation with Java in both directions.
Consequently it's made sense to try as far a possible to integrate
Scala support into the JDT. Doing this has led me down much the same
path as the AJDT people, and I'm right now working with Andrew
Eisenberg on his org.eclipse.contribution.weaving.jdt bundle which is
allowing Scala functionality to be hooked into the JDT much more
smoothly than I would have previously believed possible.

My only real concern currently is the requirement spelled out in red here,

  http://wiki.eclipse.org/Adaptor_Hooks

that the org.eclipse.equinox.weaving.hook bundle has to be installed
in the same directory as the org.eclipse.osgi bundle at runtime. This
implies that the Equinox Aspects bundles (and any plugin which depends
on them) can't easily be installed relative to a read-only Eclipse
install. That would be a bit of shame, because I'd like to be able to
offer an update-site based distribution of the Scala tooling
irrespective of how people have their Eclipse installation laid out.

However, it appears that defining osgi.frameworkClassPath to point to
both the org.eclipse.osgi bundle in the read-only area and the
org.eclipse.equinox.weaving.hook bundle jar in the read-write area is
enough to do the trick. And looking at the source of
org.eclipse.equinox.launcher, it really does seem that this is a close
to trivial classpath issue.

The availability of this workaround means that the current situation
isn't a showstopper for me, but clearly it's a bit awkward in that it
requires manual editing of the config.ini in the read-write
configuration area ... and as far as I can tell it isn't possible to
use p2.inf magic to deal with that.

So would it be possible to make the launcher a bit more flexible about
where it looks for framework extensions? If there aren't any better
qualified takers, I could put together a patch.

Cheers,


Miles

-- 
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev