Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Common Build Infrastructure/Getting Started/FAQ/Plugin Health And Best Practices"

(New page: {{:DocumentationGuidelines/DraftHeader}} Below are some tips for keeping your plugins & features healthy so that your builds stay green: * clean up all the warnings/errors that PDE provi...)
 
Line 9: Line 9:
 
* when defining a requirement on a bundle (or package) I prefer '''Require-Bundle''', since it's easier for me to deduce from which file to resolve the dependency when building. You may prefer '''Import-Package''' - YMMV.
 
* when defining a requirement on a bundle (or package) I prefer '''Require-Bundle''', since it's easier for me to deduce from which file to resolve the dependency when building. You may prefer '''Import-Package''' - YMMV.
  
* if you must define a dependency VERSION, set a range like bundle-version="[2.0.0,3.0.0)" instead of bundle-version="2.0.0", so that the qualifier can be added and not break the build.
+
* if you must define a dependency VERSION, set a range like '''bundle-version="[2.0.0,3.0.0)"''' instead of '''bundle-version="2.0.0"''', so that the qualifier can be added and not break the build.
  
 
* make sure that all new plugins are included in the runtime (or SDK) feature, ideally WITHOUT a version number (so that the version can be generated)
 
* make sure that all new plugins are included in the runtime (or SDK) feature, ideally WITHOUT a version number (so that the version can be generated)
Line 15: Line 15:
 
* make sure that features declare the plugins on which they depend (PDE can generate this list for you)
 
* make sure that features declare the plugins on which they depend (PDE can generate this list for you)
  
* make sure that ALL the files you need to ship are included in the build.properties file; build.properties itself should be included in the src.includes; you can use wildcards (build.* or plugin.*) if you'd like
+
* make sure that ALL the files you need to ship are included in the '''build.properties''' file; '''build.properties''' itself should be included in the src.includes; you can use wildcards (build.* or plugin.*) if you'd like
  
* make sure that the bin/ folder in your plugin is EXCLUDED from svn; this folder should NOT be checked in, ever
+
* make sure that the bin/ folder in your plugin is EXCLUDED from CVS or SVN; this folder should NOT be checked in, ever
  
* make sure that your plugin's manifest declares "Bundle-ClassPath: ." or nothing; you should ideally not build nested jars if you can avoid it. This improves performance when installing and running the plugin. As such your build.properties should have "source.." instead of "source.somejar.jar"
+
* make sure that your plugin's manifest declares "'''Bundle-ClassPath: .'''" or nothing; you should ideally not build nested jars if you can avoid it. This improves performance when installing and running the plugin. As such your build.properties should have "'''source..'''" instead of "'''source.somejar.jar'''"
  
* if you want to generate a source plugin or feature, make sure you add a directive to the build.properties of the containing feature (usually the SDK feature or test), eg:
+
* if you want to generate a source plugin or feature, make sure you add a directive to the '''build.properties''' of the containing feature (usually the SDK feature or test), eg:
  
 
  generate.plugin@org.foo.ui.test.source=org.foo.ui.test
 
  generate.plugin@org.foo.ui.test.source=org.foo.ui.test

Revision as of 13:28, 5 January 2010

Warning2.png
Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.


Below are some tips for keeping your plugins & features healthy so that your builds stay green:

  • clean up all the warnings/errors that PDE provides
  • make sure all plugins have x.y.z.qualifier as their version instead of x.y.z
  • when defining a requirement on a bundle (or package) I prefer Require-Bundle, since it's easier for me to deduce from which file to resolve the dependency when building. You may prefer Import-Package - YMMV.
  • if you must define a dependency VERSION, set a range like bundle-version="[2.0.0,3.0.0)" instead of bundle-version="2.0.0", so that the qualifier can be added and not break the build.
  • make sure that all new plugins are included in the runtime (or SDK) feature, ideally WITHOUT a version number (so that the version can be generated)
  • make sure that features declare the plugins on which they depend (PDE can generate this list for you)
  • make sure that ALL the files you need to ship are included in the build.properties file; build.properties itself should be included in the src.includes; you can use wildcards (build.* or plugin.*) if you'd like
  • make sure that the bin/ folder in your plugin is EXCLUDED from CVS or SVN; this folder should NOT be checked in, ever
  • make sure that your plugin's manifest declares "Bundle-ClassPath: ." or nothing; you should ideally not build nested jars if you can avoid it. This improves performance when installing and running the plugin. As such your build.properties should have "source.." instead of "source.somejar.jar"
  • if you want to generate a source plugin or feature, make sure you add a directive to the build.properties of the containing feature (usually the SDK feature or test), eg:
generate.plugin@org.foo.ui.test.source=org.foo.ui.test

or

generate.feature@org.foo.source.feature=org.foo.feature

When adding a new plugin:

  • make sure that you add the new plugin it to the releng/maps/*.map, the releng/psfs/*.psf, and the feature manifest (feature.xml) that contains it that new feature (usually the runtime feature). If your project has per-plugin source plugins, add another directive in the containing feature's build.properties to generate that new source plugin

Copyright © Eclipse Foundation, Inc. All Rights Reserved.