Hey Andrew, |
I have the bulk of this working. Most of it was already there but
either not hooked in or not updated to the new product file format
etc. Is there a particular bug report you are using to track the
stuff? I can attach a patch there.
Andrew Niefer wrote:
Here is an outline of what I see for
the publisher/build work.
Jeff, could you look at the 2nd
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
3rd points, as well as updating the .product file with version
- Publishing from Source. This
in M4 but is turned off by default and likely needs more work.
- Bundles - pretty
as an example
- Features (& rootfiles)
- This is particularly
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
and the generator puts them all in one product IU regardless of which
- The contribution of
the launcher is
especially interesting, the org.eclipse.equinox.executable feature
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.
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
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
default start levels
when no other start level info is available.
other files (eclipse.ini,
.eclipseproduct) that would have been generated by pde.build's
- Versions of IUs to
include in the product
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
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
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.
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?
p2-dev mailing list