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.
Jeff
Andrew Niefer wrote:
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.
- 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?
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|