[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Using pde to build a feature and the associated branding plugin
|
You can avoid the problem by using the same ID but different project name.
Project name of the feature and its corresponding plug-in need not be the
same (in Eclipse, we use the suffix '-feature' to solve this problem). In
fact, you also have the CVS problem because you want to keep your features
in the repository as well.
Bottom line:
1) When creating the feature project, provide different plug-in ID and
project name in the wizard.
2) You need to provide build.properties and use 'bin.includes' entries to
specify what files should be packaged in the plug-in archive when built.
For example, the following is the contents of build.properties file for
org.eclipse.jdt attribution plug-in (used by JDT feature):
bin.includes=\
about.html,\
about.ini,\
about.mappings,\
about.properties,\
eclipse32.gif,\
plugin.properties,\
plugin.xml,\
welcome.xml
# note: the following files are intentionally not listed in bin.includes
# cpl-v10.html
# notice.html
# these files need to end up as root files in <install>/eclipse/ for a jdt
runtime platform build
Regards,
Dejan Glozic, Ph.D.
Application Development
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4854
Pat
McCarthy/Raleigh/IBM@IBMUS To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@ Subject: [platform-update-dev] Using pde to build a feature and the
eclipse.org associated branding plugin
08/07/2002 02:05 PM
Please respond to
platform-update-dev
I guess this will just add to the problem/issue of overloading plug-ins
with information about a feature.
Working up an education topic on using PDE to take plug-ins, build them
using the ant support, defining features to support update manager
processing for install and so on. Structure is:
Step 1. Generate JAR files for selected plug-ins
Step 2. Package the function provided by your plug-ins as a feature
Step 3. Define product and feature branding for your function
Step 4. Package Feature
Step 4. Implement an installed product
Step 5. Install a new feature as an extension to an existing product
Step 6. Create feature and plug-in archives
Step 7. Implement an update site
Step 8. Add a feature to an existing product configuration
Step 8. Deploy and deliver service for an installed feature
I've started to work through the feature branding bit and was
considering if I should provide a plugin project with branding or have
them build it themselves. Either way I seem to be stuck.
To be the "branding plug-in" for a feature it must be a plug-in with the
same id as the feature. Given the default of having plug-in and feature
projects be created such that the dir name is the id - I can't have both
in my workspace.
Playing a bit with a branding plug-in project of name x.y.z.brand and
hacking the plugin id back to x.y.z.
That will get me over the dir name issue. But first pass packaging as
run by ant - i tossed the source.brand.jar = src/ entry - no runtime jar
rqrd, given it is only a branding plugin.... But, if this entry is not
there - the pkging task won't do anything.
Thoughts on either? (dir/id issue or pkging only working when a runtime
jar is requested?)
Pat Mc.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
