CAL-based Eclipse plugin.

[Karel Gardas]

Hello,
I'm thinking about using Cal for my future Eclipse hacking. I've just
performed google search and found to my surprise that I'm not able to
get single reference to any Eclipse plugin project being written in
Cal. Hence my question arise: is it possible to use Cal to enhance
Eclipse by writing at least some of the plugin code directly in Cal?
How complex is this if this is possible at all? My idea is to use Cal
as a vehicle for EMF Ecore modeling and models transformations.
Thanks!
Karel

[Luke]

Hi Karel,

I can only really comment in general terms, having never actually
tried to create a plug-in project that includes the necessary CAL
runtime components.

In theory including CAL within a plug-in should work fine. At the end
of the day CAL is just Java, however there are of course a set of
deployment choices and configuration to figure out.
CAL can be deployed as a Car-Jar (a Jar with special internal
structure that CAL services understand), or a Jar - with entry points
callable from Java.
You can also choose to deploy actual .cal source files and have
compilation occur at load-time.
Of course your outer package (i.e. plug-in) will need to include all
the requisite CAL runtime Jars in all cases.

One of the bigger things to get right (as always in Java-based stuff)
is the classpath. In general CAL's symbol searching is rooted in the
Java classpath.

You should be able to set up a simple project first validates you are
able to call into and out of CAL (possibly included in the project as
a Car-Jar or Jar).
After that comes the extra special requirements that arise from the
Eclipse plug-in system. I remember there being various gotchas
associated with the way plug-ins work: how they load, initialise and
what classes they can see. Unfortunately, I was never very close to
the detail, and can't remember exactly what the issues were. It's
also possible (see your other posting) that some aspects of the way
that plug-ins work have changed over the several last Eclipse
releases.

-- Luke

[Karel Gardas]

Hi Luke,

thank you for all this information. I've finally got to the point
where I actually started testing CAL/Java as an Eclipse plug-in
together. Just first step on the long journey fails immediately. I'm
not able to find any CAL bugtracking so could you be so kind and let
the man in command of CAL/Eclipse plug-in know that the CAL/New wizard
check for presence of top-level Java project, but such test is not
good as it disables possibility of creating CAL source file inside the
plug-in project. :-) Verified on helios (Eclipse 3.6).

BTW: currently I'm trying to use Quark as a CAL to Java compiler and
use Java to be compiled by Eclipse and as you recommended use CAL's
Jar files together with my Eclipse plug-in infrastructure.

Thanks,
Karel

[Karel Gardas]

Hi Luke,

you are right about trickiness of Eclipse and its classloader
infrastructure. Please see thread `Where to find Eclipse-plugin
sources?' where I've reported issue while using
BasicCALServices.makeCompiled call from inside the Eclipse plug-in.

Well, the issue seems to be caused by Eclipse classloaders as it
seems. I've kind of fixed that by really crude hack where in
BasicNullaryEnvironment's getFile methods I try to use Eclipse's way
of transforming bundle's URL to real file URL by using reflection.
This way the code is compilable even w/o Eclipse plugins on the
classpath and once run outside of the Eclipse it simply throws
exception and continues with usual Quark way.

I'm attaching the patch below for your reference. Please let me know
if this is includable into Quark or if you do have different strategy
how to proceed in this case.

Thanks,
Karel

--- /export/home/karel/vcs/Open-Quark/src/CAL_Platform/src/org/
openquark/cal/services/BasicNullaryEnvironment.java Wed Au
g 18 15:12:13 2010
+++ BasicNullaryEnvironment.java Sat Sep 11 18:16:48 2010
@@ -190,6 +190,31 @@
*/
private static File getFile(ResourcePath.Folder folder, boolean
createDirectoryIfAbsent) {
URL resourceURL = getURL(folder);
+ // here we need to check if we're working inside the Eclipse
or not
+ // Let's use introspection for this as we'd not like to
depend on
+ // Eclipse stuff here.
+ boolean insideEclipse = false;
+ try {
+ Class floaderClass =
Class.forName("org.eclipse.core.runtime.FileLocator");
+ Class urlClass = Class.forName("java.net.URL");
+ java.lang.reflect.Method m = null;
+ if (floaderClass != null) {
+ m = floaderClass.getMethod("toFileURL", urlClass);
+ }
+ if (floaderClass != null
+ && m != null) {
+ // Wow! This looks like Eclipse from inside!
+ URL backupResourceURL = resourceURL;
+ Object result = m.invoke(null, new Object[]
{backupResourceURL});
+ insideEclipse = true;
+ resourceURL = (URL)result;
+ }
+ }
+ catch (Exception ex) {
+ }
+// if (!insideEclipse) {
+// System.err.println("That's boring stand-alone Java app
probably...");
+// }

// Check whether the resource does not currently exist.
if (resourceURL != null) {
@@ -236,6 +261,32 @@

// If the file exists, return it.
URL resourceURL = getURL(filePath);
+ // here we need to check if we're working inside the Eclipse
or not
+ // Let's use introspection for this as we'd not like to
depend on
+ // Eclipse stuff here.
+ boolean insideEclipse = false;
+ try {
+ Class floaderClass =
Class.forName("org.eclipse.core.runtime.FileLocator");
+ Class urlClass = Class.forName("java.net.URL");
+ java.lang.reflect.Method m = null;
+ if (floaderClass != null) {
+ m = floaderClass.getMethod("toFileURL", urlClass);
+ }
+ if (floaderClass != null
+ && m != null) {
+ // Wow! This looks like Eclipse from inside!
+ URL backupResourceURL = resourceURL;
+ Object result = m.invoke(null, new Object[]
{backupResourceURL});
+ insideEclipse = true;
+ resourceURL = (URL)result;
+ }
+ }
+ catch (Exception ex) {
+ }
+// if (!insideEclipse) {
+// System.err.println("That's boring stand-alone Java app
probably...");
+// }
+
if (resourceURL != null) {
URI resourceURI = WorkspaceLoader.urlToUri(resourceURL);

On Aug 19, 10:16 pm, Luke <luke.ev...@gmail.com> wrote:

[Luke]

Thanks Karel.

As previously noted I'm not vested enough in the ins and outs with
this code, but I'll try to run this patch past some of the experts.
Glad you've found a workaround for your problem in the meantime.

Cheers

-- Luke

[Luke]

Further to this, it turns out that there are some other changes we've
had to make in the vault loading code in order to support CAL running
in the JBoss5 context (which is what we do here).
There are clearly several things that can depend on context in terms
of exactly how files get loaded, and it may be worth factoring out
these concerns into some kind of "resolver" delegates.

We'll give this some more thought.

-- Luke

[Karel Gardas]

Hi Luke,

sounds good! If you keep Eclipse users needs in mind during your
refactoring of vault loading code that would be great.

Thanks,
Karel

> --
> You received this message because you are subscribed to the Google Groups "CAL Language Discussion" group.
> To post to this group, send email to cal_la...@googlegroups.com.
> To unsubscribe from this group, send email to cal_language...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cal_language?hl=en.
>
>

[Luke]

Sure thing.

On Sep 21, 9:24 pm, Karel Gardas <karel.gar...@gmail.com> wrote:
> Hi Luke,
>