Re: [pde-build-dev] PDE Build and RCP - my observations

[Andrew Niefer <aniefer@xxxxxxxxxx>]

Peter,

New in 3.2 is the ability to build an
RCP product directly from a .product file.  It basically generates
a feature based on the .product file and then builds that feature.  While
I expect your setup is already past this in terms of complexity, it might
be something that can help simplify your build.  

We have written new docs in 3.2, look
under the Tasks (and at the configuration properties under Reference) in
the Plug-in Development Environment Guide  in the help.  Going
through these docs might suggest ways to simplify your build as we have
made changes in 3.2 towards that end.

More comments below.

-Andrew

Peter Bracken wrote on 06/06/2006 10:15:34 AM:
...
> First of all, when building RCP applications
how do you guys resolve
> the Eclipse dependencies for RCP applications? The PDE Build compiles
> and packages features just fine but it doesn't tell you what
> org.eclipse.* plugins your application uses/needs.
> What I have done is create my own Ant task that examines a .product
> file for dependencies and copies them over from the eclipse
> installation. It works for me, what do you guys do?
> It does mean that the .product file must be maintained by the build
engineer.

If a bundle is not listed in an included feature then
PDE build will not package that bundle in the final result.  This
is because there is the other usecase of building things that will deploy
into existing eclipse installs instead of being a product themselves.

The only other choice is to maintain the .product
file with all its dependencies (the UI can automatically add required plugins)
and to use the new product build support.  (This uses a new generateFeature
task to generate a feature including everything from the .product file).

> 
> Which brings me to another point. There are a lot of files that must
> be maintained regularly by a build engineer. Our application is made
> up of several features. This means that each feature has its own map
> file, customTargets.xml and build.properties files as well as the
> feature.xml file that must also be maintained.
> For me this means that each time I do a build I've got to make sure
> that all the correct plug-ins are in their relevant feature.xml files,
> make sure that all those plug-ins have a corresponding listing in
> their relevant map files and make sure that I've added the feature
to
> the .product file and made sure that all the required plug-ins have
> been added to the list. There's a fair bit of room for error here,
> especially if a developer has been lazy (hardly!) and forgotten to
> tell me that there are new plug-ins that should be included in the
> build!

You should only need 1 customTargets.xml for your
entire application.  If you have multiple features, include them in
one master feature for the purpose of the build and run the build on that
master.  If the master feature does not have the bin.includes property,
then it will not be included in the final result.

If you need custom steps on a per feature (or even
per plugin) basis, there is new support for feature/plugin level callbacks
(see the docs).

> 
> Again there are problems when a plug-in has become obsolete and must
> be removed from the build, or when a plug-in is refactored and
> references must be updated in the map, feature.xml and .product files.
> 
> Some of the time I have experienced compile errors that don't show
up
> in the Eclipse workbench. This is usually due to developers listing
> dependencies in the Build Path instead of in the plug-in manifest
but
> every so often it's to do with the ordering of the plug-in
> dependencies in some plug-ins' manifest files. If I shift some
> plug-ins up or down then I don't get errors.

New in 3.2 is compiling with access rules which tell
the compiler which packages from each item on the classpath you are allowed
to use.  This should reduce the number of problems relating to the
order of the plug-in dependencies.

> Would I be correct in saying that for a large
project you would
> probably need a dedicated build engineer to keep it all in check?
> Making sure that developers are telling you about which plug-ins
> should be in which feature, making sure they're writing their test
> plug-ins correctly. Making sure that the map files are in synch with
> the feature.xml files.

Eclipse itself has 2 build engineers (yay Sonia &
Kim!).  If the developers concentrated on making sure the plug-ins
they own build properly (maintaining map file entries, the manifest and
the plug-in build.properties) then ideally the build engineer only has
to worry about the features.  Though in practice it may not always
work out that way.

> 
> It seems to me that there is a lot of room for error in this system.
> What are your thoughts on these issues? Am I making a mountain out
of
> a molehill? Is it just the job of a build engineer to do all of this?
> Have I just been making a lot of mistakes along the way?
> 
> Peter
> _______________________________________________
> pde-build-dev mailing list
> pde-build-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pde-build-dev