[p2-dev] Publisher/Build Work

[Andrew Niefer <aniefer@xxxxxxxxxx>]

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.

-Andrew

• 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 contributed them.
    • 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.
      1. read the new start level stuff out of the .product file
      2. read any config.ini file refered to by the .product file
      3. generate default start levels when no other start level info is available.
      4. Any other files (eclipse.ini, .eclipseproduct) that would have been generated by pde.build's ProductGenerator
      • Versions of IUs to include in the product
      1. PDE/Build will modify the .product file to write version information for each included plugin/feature
      2. 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?