Here is an outline of what I see for
the publisher/build work.
Jeff, could you look at the 2nd point
of publishing a .product file. I believe a lot of it is there, though
the branding will need work I think. We will need an ant task for
it that pde.build can call.
I'm going to be working on the 1st and
3rd points, as well as updating the .product file with version information.
Publishing from Source. This exists
in M4 but is turned off by default and likely needs more work.
Bundles - pretty straightforward, See
as an example org.eclipse.pde.build.tests/PublishingTests#testPublishBundle_simple
Features (& rootfiles) See org.eclipse.pde.build.tests/PublishingTests#testPublishFeature_ExecutableFeature.
This is particularly interesting in
the case of products. Features contributing rootfiles get associated
rootfile IUs with the appropriate artifacts. This is in contrast
with the current generator which relies on pde.build to collect the rootfiles
and the generator puts them all in one product IU regardless of which feature
The contribution of the launcher is
especially interesting, the org.eclipse.equinox.executable feature results
in root IUs that can then be taken by products and rebranded.
Publishing a .product should be able
to run independently of any other publishing action.
Configuration information (start levels,
config.ini properties, etc). For the generator, pde.build gathers
all the rootfiles into some directory, generates a config.ini and even
a bundle.info file. and runs the generator on it to store config
information across multiple invocations of the generator. I think
even the current publisher is doing something similar. I would
like to get rid of this and have the publisher generate all of this straight
from the .product file.
read the new start level stuff
out of the .product file
read any config.ini file refered
to by the .product file
generate default start levels
when no other start level info is available.
Any other files (eclipse.ini,
.eclipseproduct) that would have been generated by pde.build's ProductGenerator
Versions of IUs to include in the product
PDE/Build will modify the .product
file to write version information for each included plugin/feature
In the case of features, the
publisher will still need to know version information for the transitive
closure of IUs so it can attach config IUs. PDE/Build will provide
version advice file.
Branding. Given the id of some
feature, org.eclipse.equinox.executable by default, that provides the brandable
rootfiles (ie the launcher), the publisher should be able to create
branded versions of those artifacts for inclusion in the product. This
is an equivalent of pde/build's BrandingIron (renaming executables. eclipse.ini,
and Eclipse.App folders. (See Features/rootfiles above).
Director install as packaging phase.
Use Director to install and then archive
the results. Do this instead of having build collect everything itself.
In the case of building update sites
this should be selective mirror instead?