An incompatibility between Ganymede and Galileo

In working on my company’s product I saw that the correct icons were appearing when the product was run in Ganymede, but not Galileo.  The problem is captured in bug 295803 and has to do with the selection of the Navigator Content Extension (NCE) to provide the label when there are two NCEs that operate on the same content.  In my applications case, it was my app’s NCE and the NCE that takes care of resources.  In Ganymede, the higher priority of these NCEs has the first opportunity to provide the labels, but in Galileo, it’s the opposite, the lowest priority provides the labels, which is certainly not what you want.

I think we should address the above bug in 3.5.2, as it’s a bad incompatible change.

Here is the (amazingly pretty and elegant) code that I used to work around the problem:

        /*
         * Yum. Due to Eclipse bug 295803 we need to change the priority of the
         * NCE for our product. This only needs to happen on a 3.5.0 or 3.5.1
         * system. We sense this by the org.eclipse.ui.navigator bundle version
         * (in which the minor version lags one behind the main Eclipse
         * version.) Note that if this bug is fixed in 3.5.2, then the version
         * check needs to consider only CNF versions 3.4.0 and 3.4.1.
         */
        Bundle bundle = Platform.getBundle("org.eclipse.ui.navigator"); //$NON-NLS-1$
        Dictionary headers = bundle.getHeaders();
        String version = (String)headers.get("Bundle-Version"); //$NON-NLS-1$
        if (version.startsWith("3.4")) //$NON-NLS-1$
        {
            INavigatorContentService ncs = getNavigator()
                    .getNavigatorContentService();
            NavigatorContentDescriptor desc = (NavigatorContentDescriptor)ncs
                    .getContentDescriptorById("com.oaklandsw.transform.navigatorContent"); //$NON-NLS-1$

            try
            {
                Field[] fields = desc.getClass().getDeclaredFields();
                for (int i = 0; i < fields.length; i++)
                {
                    if (fields[i].getName().equals("priority")) //$NON-NLS-1$
                    {
                        fields[i].setAccessible(true);
                        fields[i]
                                .set(desc,
                                     new Integer(Priority.LOWEST_PRIORITY_VALUE));
                        break;
                    }
                }
            }
            catch (Exception e)
            {
                Util.impossible(e);
            }
        }

Posted in Common Navigator | 1 Comment

RCP, p2, Vista and VirtualStore

I have an RCP application that uses p2 and needs to run on all of our platforms (this uses 3.4.2).  Everything was great until Vista came along.  On Vista when going to the Software Updates… dialog it gets the “not properly configured” dialog and won’t let me do the fun p2 stuff.

The problem is that Vista does not like it (sort of) if you try to write things in the Program Files directory.  You can write as much as you like only during the install process, and there seems to be some way that it writes a “virtual store” into this area when the app is running, but p2 will not work with this.

The solution that I have found is to (my app is called “osdt”, which is also the name of my launcher executable):

  1. Add
    • -Dosgi.configuration.area=@user.home/osdt/configuration

    to my Launching Arguments in my product file in the VM Arguments section for all platforms.  This tells it to look for the configuration area in a location that’s relative to the Java “user.home” system property (c:/Users/<User name> on Vista and c:/Documents and Settings/<User name> on XP.)

  2. Add the following into my config.ini file:
    • eclipse.p2.data.area=@config.dir/../p2
    • osgi.instance.area=@user.home/osdt/workspace
  3. This makes sure that the p2 data area is relative to the configuration and my workspace is also created relative to the user’s home directory.

  4. Teach my installer to put the configuration and p2 directories in the expected location. I use install4j – and the key here is to have it come up with the variable setting the location to install these things at install time using the “user.home” system property from Java so that the Eclipse @user.home and where the kit is being installed to will always be in sync.

All of this was great, but it did not work, and I was finding that no matter what I did to my osdt.ini file it had no effect. The problem was that the Vista “virtual store” mechanism had written my information from the previous installs and that was silently overriding what was in the Program Files folder. In general, if you write something to the Program Files folder, it will really be written to c:/Users/<User name>/AppData/Local/VirtualStore/Program Files, and whatever is at this virtual store location will silently take precedence over what is in the Program Files folder. Once I deleted the stuff in the virtual store location everything was fine.

Posted in Uncategorized | 6 Comments

Application “…” could not be found in the registry.

Just spent a couple of hours debugging one of these and thought I would write it up in hopes that it makes things better.

My use case is that I’m calling my application from an API which means I’m dynamically starting it using the EclipseStarter class (with reflection since I can’t reference Eclipse stuff from the JAR file that my customers use).

Everything used to work in this particular set of tests (don’t they all say that?), and then when I run them I get the error below.

It turns out the problem was the plugin (bundle) that contained the application definition (in the plugin.xml) did not get resolved.  It did not get resolved because it depended on a plugin that did not exist.  However there is nothing in the logs that indicated there was a problem loading this plugin, it was just silently not loaded.  I only discovered this debugging the bundle resolution code and wondering why it was not resolved.

So if you get this error and you can’t think of any other reason for it, make sure all of your dependent bundles are present, and ;resoution=optional could be your friend.

This bug has been filed about this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=277058 (this happened in 3.4.2, so maybe it’s fixed in 3.5).

Caused by: java.lang.RuntimeException: Application “com.oaklandsw.transform.runtime.engine” could not be found in the registry. The applications available are: org.eclipse.equinox.app.error, org.eclipse.update.core.standaloneUpdate, org.eclipse.updat
e.core.siteOptimizer.
at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:242)
at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.oaklandsw.transform.runtime.RuntimeFactory.createRuntime(RuntimeFactory.java:229)
… 76 more

Posted in Uncategorized | 4 Comments

Compatibility is Restored

As of N20090304-2000 (and 3.5M6) the CNF incompatibilities with prior released have been fixed, and what’s even better is the mechanism is cleaner and simpler to explain.

bug 255793

bug 252293

I won’t elaborate right now for personal reasons (broken elbow), but the docs will be updated (thanks to help from  my lovely wife) and I will explain all in the docs and at EclipseCon.

Posted in Common Navigator | 1 Comment

How cool is this?

I was looking at this:

/*
* Non-Javadoc. Method declared on Viewer.
*/
public void refresh() {
refresh(getRoot());
}

I hit F3 when Viewer was selected and it took me there.  It appeared to do it because it matched the name of a class.  Hitting F3 on Method also worked.  Pretty cool!

Posted in Uncategorized | 1 Comment

Warnings

I was just talking with my wife and told her that I only had a couple of more sets of warnings to go:

her: “What are you talking about?”

me: “In the Common Navigator.”

her: “You don’t have warnings, that must have been what you inherited.”

me: “Yes, there are about 6300 warnings in Platform UI/JDT code right now.  (expletive deleted)”

I’m doing my part.

Posted in Uncategorized | Leave a comment

All done with Common Navigator DnD issues (for now)

I have no outstanding bugs or enhancement requests related to DnD.

Thanks to Dani Megert for helping me with many of the issues.

Now it’s onto issues of priority and categorization for actions and sorting.  And a few other things.

Posted in Common Navigator | Leave a comment

Which bugs for CNF DnD?

Someone asked which bugs/enhancements I plan to address.

I plan to address all of them (that are known to me — if I missed any, let me know).  The ones that are currently marked for M6 have a fix waiting review, I will get to the rest in the next day or two.

261865 maj P2 francisu@ieee.org rob.stryker@jboss.com ASSI 0 3.5 M6 dnd [CommonNavigator] Drag from Project Explorer to Package Explorer gets “assertion failed”
261060 maj P3 francisu@ieee.org jtcornett@yahoo.com ASSI 0 3.5 M6 dnd [CommonNavigator] Java EE perspective drag drop src folder onto its own project deletes src folder
258017 maj P3 francisu@ieee.org keshavrao.veerapaneni@sap.com NEW 1 3.5 M6 dnd [CommonNavigator] Project Explorer Drop Problem
242265 enh P3 francisu@ieee.org mike.bernat@softwareag-usa.com NEW 0 3.5 M6 dnd [CommonNavigator] [JFace] Common Navigator validateDrop needs DropTargetEvent
150688 enh P3 francisu@ieee.org mdelder@us.ibm.com ASSI 0 3.5 M6 dnd [CommonNavigator] Expose the ability for CommonDropAdapterAssistants to select feedback
224016 nor P3 francisu@ieee.org francisu@ieee.org NEW 0 dnd [DND][CommonNavigator] Drag to Project Explorer ignored after Drag from it
209537 nor P3 francisu@ieee.org makandre@ca.ibm.com NEW 0 dnd [CommonNavigator] Weird drag’n drop behavior
261606 enh P2 francisu@ieee.org rob.stryker@jboss.com NEW 0 dnd [CommonNavigator] Drag and Drop support lacks any adaptability
107119 enh P3 francisu@ieee.org jcorchis@ca.ibm.com NEW 0 dnd [CommonNavigator][DND] Add DND support for linking in the Project Explorer
Posted in Common Navigator | Leave a comment

Drag and Drop

In the next few days I intend to address as many of the CNF drag and drop defects as possible.  I have marked them all with “dnd” in the status whiteboard (search for Platform/UI/CommonNavigator).  The way I work is to work on one area of code at a time to really learn it and to try and address all of the issues with it before moving on to the next area.  So if you have any DnD issues, other bugs, questions, etc, now is the time.

Posted in Common Navigator | 2 Comments

Something to Watch Out for – Objects that don’t Match Content Extensions

With the M5 changes to the Common Navigator (are you sick about hearing about this yet?), the caching of the association between objects added by the content provider and the the navigator content extension has been temporarily removed.  The reason for this is to make sure the behaviour of finding the correct navigator content extension for a given object is always the same (previously it was not, depending on the state of the cache).

As bug 262675 has revealed, it was possible to have an object in the cache associated with a navigator content extension, even though that object did not match an expression defined by that extension.  This is because all objects provides by the content provider were blindly added to the cache.  Since the cache has been removed, it has revealed cases where the navigator content extensions were not setup correctly to account for all of the possible objects (one of these was missing in the case of the above DTP bugs).  This will require a simple change to fix (look at the patch associated with the bug report).

It is possible that this problem may show up with other users of the CNF.  The problem has always been there, it was just very non-deterministic and hard to reproduce given the cache.  Now these problems with show up quickly so they can be fixed.  I will also be done some work for M5 (tomorrow) to make the error handling of these cases work well.

Posted in Common Navigator | Leave a comment