Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
I was once asked the same question three times in the period of a single week: "Can classes in one plug-in access classes in another, and if so, how?" This question seems to crop up more during RCP development, but the answer is the same for building any plug-in.
The answer is yes, and if you think about it, the reason should seem obvious.
Whenever you build a plug-in, you are making use of classes in other Eclipse plug-ins. To prove it, just try to develop an Eclipse view without being able to have your class inherit from the class org.eclipse.ui.part.ViewPart.
The motivation for the question comes from every developer's desire to organize their code in a modular way. Take for example the situation of developing two different plug-ins, each requiring the same base classes. Do you copy the base classes into each plug-in? Of course not.
What you want to do is create a plug-in that contains the base code and two other plug-ins that depend on it. That way you only have to worry about one development stream for the base-plug. If you are building RCP applications, this situation is likely to happen often. Code you write for one RCP application is often useful in another. So the lesson for today is don't make monolithic plug-ins containing all your code. Think of a plug-in as just another package structure, and break your code up accordingly. Then let Eclipse help make your packages in a plug-in either public or private.
The first step to making a package available for export from a plug-in is to double-click on its plugin.xml file or its MANIFEST.MF file. This action produces a multi-tabbed editor similar to the one shown in Figure 1. I clicked on my base project's MANIFEST.MF file to get the editor.
I have one package in this plug-in (com.espirity.content), and I want to have its class visible to other plug-ins. Only public classes will be visible. I did this by going to the editors Runtime tab and adding my package to the list of exported packages, as shown in Figure 2.
The default is to have this package visible to all downstream plug-ins. However, you can also make a package visible to select plug-ins by manipulating the package visibility plug-in list on the right side of the editor. To make a package visible to all plug-ins, leave this list empty.
With the package visibility established, the next step is to access classes in your exported package from a dependent plug-in's code. Double-click on your dependent plug-in's plugin.xml file or its MANIFEST.MF file and go to its Dependencies tab as shown in Figure 3.
In the Required Plug-ins list, make sure to add your previous plug-in. In my case it was the plug-in named BaseProject. If you forget to do this, your code will not compile while attempting to access the remote classes, even if you add import statements to the packages.
In my example, I added the following import statement to the part of my code that required access to the remote classes:
import com.espirity.content.ExampleContent;
Once everything compiles correctly, you are ready to test your two plug-ins.
A word of warning: When you try to load your dependent plug-in, it will fail to load if the one you depend on is not in the Eclipse plug-in's directory or you haven't configured it to be included in your test run. That makes perfect sense, because if code you depend on is not available, then your code won't work, so Eclipse figures there's no point in loading it.
This column was originally run in September, 2006, and may be inconsistent with current versions.
Share this link: http://www.sdtimes.com/link/32768