• create new feature project
• add plug-ins to the feature
• create new updatesite project
• add the feature to the updatesite (pre-p2 style – site.xml)
• export newly created updatesite (letting Eclipse to deal with creating p2 meta data)

Since I needed to automate this process I started researching on p2 capabilities and found out that it can be done from command line using FeatureAndBundlesPublisher application. Sample command line invocation to do it:

%ECLIPSE_EXE% -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher -metadataRepository file:/%P2_TARGET% -artifactRepository file:/%P2_TARGET% -source %P2_SRC% -compress -configs win32.win32.x86 -publishArtifacts

Where:

• ECLIPSE_EXE – points to Eclipse executable;
• P2_TARGET – path to an empty directory where p2 repository should be created;
• P2_SRC – path to the directory with /plugins subdirectory and plug-ins to be published (jar files) inside;
• -compress parameter is optional. It compresses artifacts.xml and content.xml to jar (zip) files.

• Create new Eclipse plug-in: File -> New -> Other -> Plug-in Development -> Plug-in Project
• Add dependency: MANIFEST.MF -> Dependencies tab -> Add -> org.eclipse.ui
• Add extension point org.eclipse.ui.menus: plugin.xml -> Extension -> Add -> org.eclipse.ui.menus
  • Right-click -> New -> menuContribution
    • Enter locationURI: menu:file
      • Right click -> New -> command
      • Enter commandId: tk.urbas.eclipse.sample.sampleCommand
      • Enter label: Sample Menu Item
• Add extension point org.eclipse.ui.commands: plugin.xml -> Extensions -> Add -> org.eclipse.ui.commands
  • Right-click -> New -> command
    • Enter id: tk.urbas.eclipse.sample.sampleCommand
    • Enter label: Sample Command
• Add extension point org.eclipse.ui.handlers: plugin.xml -> Extensions -> Add -> org.eclipse.ui.handlers
  • Right-click -> New -> handler
    • Enter commandId: tk.urbas.eclipse.sample.sampleCommand
    • Enter class: tk.urbas.eclipse.sample.SampleHandler
    • Click class link and create class
    • Provide sample implementation of the handler class implementing org.eclipse.core.commands.IHandler or extending org.eclipse.core.commands.AbstractHandler

Menu, command, handler

MANIFEST.MF

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Sample Handler
Bundle-SymbolicName: tk.urbas.eclipse.sample;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Vendor: urbas.tk
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Require-Bundle: org.eclipse.ui

plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <extension
         point="org.eclipse.ui.menus">
      <menuContribution
            locationURI="menu:file">
         <command
               commandId="tk.urbas.eclipse.sample.sampleCommand"
               label="Sample Menu Item"
               style="push">
         </command>
      </menuContribution>
   </extension>
   <extension
         point="org.eclipse.ui.commands">
      <command
            id="tk.urbas.eclipse.sample.sampleCommand"
            name="Sample Command">
      </command>
   </extension>
   <extension
         point="org.eclipse.ui.handlers">
      <handler
            class="tk.urbas.eclipse.sample.SampleHandler"
            commandId="tk.urbas.eclipse.sample.sampleCommand">
      </handler>
   </extension>
 
</plugin>

Handler – sample implementation showing a message

package tk.urbas.eclipse.sample;
 
import org.eclipse.core.commands.AbstractHandler;
import org.eclipse.core.commands.ExecutionEvent;
import org.eclipse.core.commands.ExecutionException;
import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.swt.widgets.Display;
 
public class SampleHandler extends AbstractHandler {
 
	@Override
	public Object execute(ExecutionEvent event) throws ExecutionException {
		MessageDialog.openInformation(Display.getDefault().getActiveShell(),
				"Sample Handler", "Sample Handler");
		return null;
	}
}

I decided to choose my very personal Top 5 for Galileo release:

1. Update. New UI for installing and updating new features in Eclipse really leverages user experience. After introducing p2 in 3.4 a lot of people missed old Update Manager. With more stable and matured p2 in 3.5 version hopefully no one is missing 3.3 style updates any more. One capability I would find useful there is installing particular Installable Units instead just these which are based on Eclipse features. In p2 world all IUs are supposed to be equal.
2. Setting the cookies in Browser. I’m really happy to finally see setCookie(value, url) method in SWT Browser class. That’s the part of API that was really missing there to make embedded browser more functional in Eclipse RCP world. Next step would be probably providing SWT support for the Webkit based browsers.
3. Target Platforms. Galileo way of defining target platform is another item I find really useful for Eclipse RCP. Finally at least partially runtime for Eclipse RCP application can be independent from the plug-ins set in Eclipse IDE used for development!
4. Mylyn. Previous Mylyn version satisfied most of my requirements to work with Bugzilla. But new Mylyn Editor just feels better for me even if it took me a day or two to get used to the context activation button being moved from right to left side of the toolbar.
5. OSGi Declarative Services. I’m excited about declarative services in Equinox. I didn’t have opportunity to try it yet but I have high hopes for the near future!

Let’s assume: plug-in A and fragment B with a defined host plug-in A are sitting together on single update site. Plug-in A in reality cannot run without appropriate version of fragment B (e.g. situation similar to SWT).

My understanding of p2-power was that I wouldn’t need to create separate feature C aggregating A and B just to make fragment B be automatically installed when I request installation of plug-in A.

I spent some time on reviewing Eclipse Bugzilla and mailing lists. Interesting findings:

http://wiki.eclipse.org/Equinox_p2_Meeting_2007#Fragments_optional_vs._requirement

https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430

Any suggestions about handling such “required” fragment scenario without getting rid of autogenerated p2 repository and hand crafting p2 metadata?

1. Adding org.eclipse.ui.startup extension:
   • Dependencies:
     • org.eclipse.ui
     • org.eclipse.core.runtime
   • Extension:

     <?xml version="1.0" encoding="UTF-8"?>
     <?eclipse version="3.2"?>
     <plugin>
        <extension point="org.eclipse.ui.startup">
           <startup class="tk.urbas.eclipse.urbanlife.Startup"></startup>
        </extension>
     </plugin>

2. Implementing Job:

   package tk.urbas.eclipse.urbanlife;
    
   import org.eclipse.core.runtime.IProgressMonitor;
   import org.eclipse.core.runtime.IStatus;
   import org.eclipse.core.runtime.Status;
   import org.eclipse.core.runtime.jobs.Job;
    
   public class RefreshDataJob extends Job {
    
       public RefreshDataJob(String name) {
           super(name);
       }
    
       @Override
       protected IStatus run(IProgressMonitor monitor) {
           // Work to do in the background
           return Status.OK_STATUS;
       }
   }

3. Scheduling Job to run periodically:

   package tk.urbas.eclipse.urbanlife;
    
   import org.eclipse.core.runtime.jobs.IJobChangeEvent;
   import org.eclipse.core.runtime.jobs.Job;
   import org.eclipse.core.runtime.jobs.JobChangeAdapter;
   import org.eclipse.ui.IStartup;
    
   public class Startup implements IStartup {
    
       private static final long STARTUP_DELAY = 5000; // 5 seconds delay for first run
       protected static final long JOB_INTERVAL = 60000; // Job should run every 60 seconds
    
       public void earlyStartup() {
           final Job updateJob = new RefreshDataJob("Refreshing data in the background");
           updateJob.schedule(STARTUP_DELAY);
           updateJob.addJobChangeListener(new JobChangeAdapter() {
               @Override
               public void done(IJobChangeEvent event) {
                   super.done(event);
                   updateJob.schedule(JOB_INTERVAL);
               }
           });
       }
   }

Let me know if you have any better solution for implementing this. All improvements, suggestions and comments will be greatly appreciated.

Required software:

• Eclipse for RCP/Plug-in Developer
• JEE Standard Tools & Axis
  

Configuration steps:

• Define new JEE service in a workspace
  
• Create new plug-in project
  
• Add following dependencies to the plug-in:
  • org.apache.commons.logging
  • javax.wsdl
  • javax.xml.rpc
  • javax.xml.soap
  • org.apache.commons.discovery
  • org.apache.axis

  

• Generate web service client code
  

  

Consume web service:

Using web service in side a plug-in is no different than anyone else. Sample of invoking web service method:

TransportServiceSoap service = new TransportServiceLocator().getTransportServiceSoap();
service.getCities();

Instruction presented above is based on Eclipse 3.4.1 and uses sample web service from http://www.urbanlife.pl/

• it requires absolute paths to plug-ins/features locations
• every single plug-in has to be listed there

Workaround for this is not using map file at all and provide appropriate build directory structure outside. To skip fetching resources based on map file configuration one need to set skipMaps property in build.properties file. Next step is to configure getting plug-ins/features resources into build directory. Recommended phase for copying the source code is preSetup phase in PDE build. To hook into this phase standard ant task for copying the files/directories in to build directory have to be invoked in preSetup target in customTargets.xml (it is generated by Pluginbuilder as well as other configuratoin files in build-files directory).

Those two modifications allow to make use of Pluginbuilder generated scripts to build Eclipse based applications without coupling it tightly to version control system.

Creating and scheduling Job may look like this:

 TrainJob job = new TrainJob(TRAIN_JOB_NAME + file.getName(), classifier);
 job.setRule(file);
 job.setUser(true);
 job.setPriority(Job.SHORT);
 job.schedule(); // start as soon as possible

Sample of custom Job:

package pl.edu.agh.caracal.classifier.popup.jobs;
 
import static org.eclipse.core.runtime.Status.OK_STATUS;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.jobs.Job;
import pl.edu.agh.caracal.classifier.ext.classifiers.AbstractClassifier;
 
/**
 * Class for execution of training of a classifier
 *
 * @since 1.0
 */
public class TrainJob extends Job {
 private AbstractClassifier classifier;
 
/**
  * Public constructor TrainJob
  *
  * @param name Train job name
  * @param classifier Classifier to be trained
  */
 public TrainJob(String name, AbstractClassifier classifier) {
 	super(name);
 	this.classifier = classifier;
 }
 
 @Override
 protected IStatus run(IProgressMonitor monitor) {
 	// Long running operation - in this case classifier training
       // ...
       return OK_STATUS;
 }
 
}

Standard GUI for presenting Job progress: