- This topic has 6 replies, 2 voices, and was last updated 18 years, 9 months ago by
.
-
Posts
-
For the most part, Genuitec does a great job on development and an even better job on support, so we can go long periods of time without having any issues that affect our devlopment. Not so this week.
We had a major demo of strategic direction stuff for pretty much everyone with a CxO title, their direct reports, with their direct reports’ own minions and so on.
To make a long story short we needed to demonstrate server-side functionality and build a new graphical editor based off of Eclipse’s Graphical Editing Framework, in a week. That’s like providing brain surgery in 5 minutes, which is doable if you consider simply removing the brain and death of the patient as unfortunate event. Nonetheless, we finished on the 6 day and all we needed to do was add the various plugins together, bundle into a feature and toss them up on an update site.
Here’s where the fun begins, the #@#& projects would not complie, other rather the gef project would no longer compile. We racked our brains trying to understand why it only compiles on one developer’s machine and not others. Finally we discovered that the problem that threatened our demo was ME.
Here’s how. Those of us developing the server-side had ME installed since we were deploying and testing to Tomcat, JBoss, Weblogic, etc. However the developer who was developing the GEF editor was new to Eclipse and didn’t have ME installed. However, there shouldn’t be a problem because he didn’t need it. The editor had no ties to ME, so in theory we should have been able to package his plugin with the others and away we go.
The problem was that ME includes draw2d and gef, and in those plugins the classes are package differnently. Thus if you have ME installed and import the draw2d and gef projects into your workspace then you pick up the ME projects instead of the GEF SDK which is installed in your eclipse plugins dir. When done this way, no project that depends on org.eclipse.gef or org.eclipse.draw2d can see the classes.
Steps to reproduce:
0. Create a new eclipse install (with gef sdk) and workspace.
1. Import gef (and all its required plugins).
2. Create a new class that extends a gef class. Everything should now be compiled.
3. Install ME and choose this eclipse install, everything should once again be ok, because the gef projects were previously imported from your eclipse dir.
4. Repeat steps 0 – 2, only this time install ME at step 0 and it will fail.If you expand all the imported projects you will see that they all have linked jars with the code, except for the draw2d and gef projects picked up from eclipse which only have an org folder.
binyan,
First, I’m sorry you experienced a problem and second, congratulations on the demo.
I’m trying to dig in to your post to understand it a bit better. Can you go into more detail on this statement:
The problem was that ME includes draw2d and gef, and in those plugins the classes are package differnently
First, for the record, we don’t repackage GEF or Draw2D in any way; we simply ship a release as available from Eclipse.og for convenience. The reason I ask is that for MyEclipse 4.0M2, we packaged the latest version of GEF/Draw2D available at the time, for Eclipse 3.1, which was verison 3.1 RC3 of GEF. However, you didn’t specify if you were using this version of ME or another and what likely happened is that your GEF developer used a different version of Eclipse and or GEF than the rest of the team. As with most Eclipse projects, the GEF team repackages and occasionally introduces breaking changes between versions so I can certainly see this being an issue if your ME team was using version 3.8.4, for instance, and your GEF guy was using 3.1 + GEF. Can you comment on the versions of Eclipse/ME/GEF used by the team?
I didn’t think that you all repackaged GEF, but rather the version you packaged was not GEF 3.1 final. In GEF 3.1, when the plugins are loaded into your workspace, they have the gef and draw2d jars linked to them. However if ME 4.0M2 is installed in an Eclipse 3.1 final install and then you try and import the plugins into the workspace then you will get the ME gef and draw2d plugins instead and there will not be a linked gef nor draw2d plugin jar file in the project. Instead you will have an “org” folder which you can expand all the way to see the classes. This looks like some type of packaging change from GEF 3.1 RC3 to GEF 3.1 Final and the fact that you MUST import the plugins before (or without) ME being installed.
The GEF developer had originally installed eclipse 3.1 and then installed the GEF 3.1 final SDK. He imported the plugins into the workspace for browsing and then created the editor. He didn’t need ME so he didn’t install it at that point. Once the editor was working the other devs tried to import his project and the required plugins into our workspaces that already had eclipse and ME integrated. Thus when we brought the plugins in, the editor no longer compiled even though the plugin projects were in our workspaces. What really threw us for a loop was that when we went back to the original GEF developer’s machine and add ME to it, it contiuned to work. This was because he had already loaded the plugins into his workspace, thus his plugins were still resolving against the GEF SDK plugins in his eclipse install and not the one’s in his ME install.
OK. I see what’s going on. It’s the old “the Eclipse teams don’t update any of their plugin versions between releases” thing. Since our plugins were already installed as 3.1.0 and the next build was also 3.1.0, Eclipse just picked one. To compensate we’ve adjusted our plugin versions back to 3.0.99 so that later 3.1 releases should override them and avoid problems like this going forward. Thanks for pointing it out and hanging in there to help us resolve it in the next build.
Scott, that’s cerainly a path ME can take however, I don’t believe there is a real fix for this since eclipse teams don’t update thir versions between releases, which I think causes more problems than not updating would solve. Frankly, we have the build # included in our version IDs and since the build # always goes up for a specific version this could solve it by being unique, but Eclipse has not decided to go that route.
The best we and/or ME can do is document this. Now that we understand what is going on we can work around it in 5 minutes by shutting down ME, removing the ME links file, restart eclipse and importing any plugins that are duplicated between ME and eclipse proper. Finally shutown again and re-add the ME link file and we’re back in business.
I agree. There’s really no way around it, but educating everyone on how Eclipse resolves plugin dependencies and when conflicts might occur can go a long way. For example, from the sound of your initial post, *finding* the cause of the issue was 95% of the angst. Solving it is really as straightforward as you articulate above. In fact, you really don’t have to remove the links file as you should be able to specify the location of any plugins you want to import in the wizard by specifying either the main Eclipse installation location or any of its extension locations, since MyEclipse doesn’t install into the main distribution.
