• 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.

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?

Agenda, specific date and place should be announced here