JGears on Eclipse Update Site

For the last couple of months I have been working on getting our JGears for Eclipse products ready for "shipping". I say "shipping" because unlike previous releases of JBuilder, which have always had a physical disc in a box that is literally shipped to customers and resellers, we are selling our JGears through our update site. Anybody can download the JGears, although the functionality will only be enabled with a valid license.

At any rate, we are using the Eclipse Update Site technology for installing the JGears. I learned a lot about it, although I suspect there is still a lot that I don’t know. When working on the project, I did a Google search for articles about Eclipse update sites, I was surprised that a very simple blog I had written came up on the first page of search results. Actually, "dismayed" is a more accurate description of how I felt. That blog was quite basic, and the fact that it was relatively high in the search results only served to emphasize the lack of information and documentation in this area. It’s a problem I have with Eclipse and Open Source software in general — there are lots of dedicated developers writing neat, powerful software, but the documentation is often lagging, if it is there at all. Lest that be misinterpreted, let me state that I am not against Open Source software, not at all. It just gets challenging to work with at times.

I digress. I am going to try to fill in the Eclipse update site information gap a little, and hopefully with the correct information. In a series of blogs, until I run out of steam, I will cover some of the issues we ran into.

Dependencies

One issue we ran into is how the Update Manager resolves dependencies. This is an issue in particular because our update site contains both the JGears and JBuilder 2007 itself, so that JBuilder customers can get updates to JBuilder. Keep in mind that the JGears are essentially JBuilder 2007 functionality split up into different parts. When an Eclipse user wants to download a JGear, we want to be sure that the user only downloads the files necessary for the JGear, and not any of the JBuilder files. Sounds simple, right? Following is a simplified example that shows how it gets tricky. This particulars of this scenario are made up to demonstrate the point.

1. JBuilder Enterprise feature.xml includes the Optimizeit feature.xml:
   ...
<includes id="com.borland.optimizeit"
version="1.0.2"
optional="true"/>
...
2. JGear Performance feature.xml requires the Optimizeit feature.xml:
   …
   <requires>
...
<import feature="com.borland.optimizeit" version="1.0.2"/>
...
</requires>
...
3. User goes to update site, selects JGear Performance, then clicks on the Select Required button.

At this point, if you look at what is selected, you would expect, among other things, that JGear Performance and Optimizeit are selected. Instead, based on your site.xml, what you may see selected are JGear Performance and JBuilder Enterprise! So if the user proceeded, she would not only download JGear Performance, but all of JBuilder Enterprise.

Why does this happen? Because when the user presses the Select Required button, Eclipse apparently goes through the site.xml, looking for the first thing that resolves the Optimizeit requirement¹ . In this case, because JBuilder Enterprise includes Optimizeit, JBuilder Enterprise resolves the requirement, and it is selected. Unfortunately, everything else in JBuilder Enterprise and its dependencies in turn are also selected, so the user ends up downloading a lot more than she needs for the JGear.

Possible Solutions

• One solution is to simply change the JGear Performance feature.xml to include com.borland.optimizeit, instead of requiring it. The trade-off is that you are now including one feature in more than one feature. That seems wrong to me, but in certain cases it is unavoidable.
• Another solution is to change the JBuilder Enterprise feature.xml to require com.borland.optimizeit instead of including it. The drawbacks to this approach are:
  1. Requires are less flexible in that they don’t have platform filters. Optimizeit is currently not available on the Mac. If we include it in a feature, we can say only include if the platform is Windows or Linux. If we don’t want the JGear Performance feature including Optimizeit to ship on a Mac, then fine, but if we do want the rest of JGear Performance to be available on the Mac, we can’t do that with a requires.
  2. Requires are also less flexible in that they are always required, as the name implies. You can’t make them optional. Generally, I like to make included features optional. That way the user can disable them or not even download them if they are something he is not going to use.
  3. As far as I know, PDE builds will only build items included in features. In this example, it means that Optimizeit would have to be built separately. Which may or not be a bad thing in the particular case.
• An ugly solution is to reorder the site.xml. If we put JBuilder Enterprise at the bottom of the site.xml, then when the dependencies are resolved, the Optimizeit feature will be found before the JBuilder Enterprise feature, and since it satisfies the requirement, JBuilder Enterprise will not be selected.

With JBuilder and the JGears, the number and mix of dependencies than the simple example above. Sometimes the solution uses all 3 of the above techniques, even #3, which I really dislike, but was sometimes unavoidable.

¹ I say "apparently", based on the results of my limited testing in this area. I did not find any documentation describing this as intentional behavior, nor did I debug the code to confirm it.

Share This | Email this page to a friend

Posted by Charles Overbeck on September 7th, 2007 under Eclipse, JBuilder |

Server Response from: dnrh1.codegear.com