Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Linux Tools Project/Releng"
(→Linux Tools Release Engineering Procedures) |
(→Adding a new component) |
||
Line 2: | Line 2: | ||
== Adding a new component == | == Adding a new component == | ||
+ | Like most Eclipse projects, our build process is feature-driven. A top-level dummy feature, org.eclipse.linuxtools.all, acts as a container which lists all of our sub-project's top-level features. These then cascade down into their plugins and the whole thing gets wrapped up into our update site and zips. In order for a new component to be built, it needs to fit into the hierarchy somewhere. When adding a new top-level sub-project feature (sub-features of existing features should get added to their containing feature), follow these steps: | ||
+ | |||
+ | === Code-level checklist === | ||
+ | |||
+ | # Create your feature and containing plugins | ||
+ | ## Name the feature(s) org.eclipse.linuxtools.mycoolstuff-feature (replacing "mycoolstuff", obviously) | ||
+ | ## Name the plugin(s) org.eclipse.linuxtools.mycoolstuff.core, org.eclipse.linuxtools.mycoolstuff.ui, etc. | ||
+ | ## Ensure your packages are all in the org.eclipse.linuxtools namespace (and in the .mycoolstuff.core, .mycoolstuff.ui packages where appropriate) | ||
+ | # Create your JUnit test plugins | ||
+ | ## Use JUnit 3 and not JUnit 4 | ||
+ | ## Name your test plugin the same as your functional plugin but with a ".tests" tacked onto the end | ||
+ | ## Create a test.xml for use in the automated builds (see an example [http://dev.eclipse.org/viewcvs/index.cgi/oprofile/trunk/org.eclipse.linuxtools.oprofile.ui.tests/test.xml?revision=21771&root=Technology_LINUXTOOLS&view=markup here]) | ||
+ | |||
+ | === SVN-level checklist === | ||
+ | |||
+ | # If this is a new sub-project, create a directory to contain it, like "oprofile" or "autotools" | ||
+ | # Ensure that the standard directory structure of "branches", "tags", and "trunk" exists under your containing directory | ||
+ | # Check your features and plugins into SVN under trunk | ||
+ | # Create a tag called "initial-checkin" which is a snapshot of your initial work | ||
+ | |||
+ | === Build-related checklist === | ||
+ | |||
+ | # Add any new top-level feature to [http://dev.eclipse.org/viewcvs/index.cgi/releng/trunk/org.eclipse.linuxtools.all/?root=Technology_LINUXTOOLS org.eclipse.linuxtools.all] | ||
+ | ## If you are adding a new sub-feature, ensure it is in a containing feature which itself is a part of the org.eclipse.linuxtools.all tree | ||
+ | # If your sub-project has dependencies outside the existing ones (BIRT, EMF, DTP, CDT), notify Andrew Overholt | ||
+ | ## Hopefully this will have been caught in the CQ (legal review) | ||
+ | ## Add dependency zips to [http://wiki.eclipse.org/index.php?title=Linux_Tools_Project/Releng&action=edit§ion=2 build.properties] | ||
+ | # Ensure your [http://wiki.eclipse.org/index.php/Execution_Environments BREEs] are correct in your plugin MANIFEST.MF files | ||
+ | # Add your test feature to the [http://dev.eclipse.org/viewcvs/index.cgi/releng/trunk/org.eclipse.linuxtools.test-feature/?root=Technology_LINUXTOOLS org.eclipse.linuxtools.test] feature | ||
+ | ## Alternatively, add to an existing test feature that is already in the org.eclipse.linuxtools.test feature hierarchy | ||
+ | # Add new features to our update site's multiple [http://dev.eclipse.org/viewcvs/index.cgi/releng/trunk/org.eclipse.linuxtools.updatesite/?root=Technology_LINUXTOOLS site.xml files] | ||
+ | ## Be sure to add dependency sites to [http://dev.eclipse.org/viewcvs/index.cgi/releng/trunk/org.eclipse.linuxtools.updatesite/updates/associateSites.xml?root=Technology_LINUXTOOLS&view=log associateSites.xml] | ||
+ | # Add all new features, plugins, and fragments to our [http://dev.eclipse.org/viewcvs/index.cgi/releng/trunk/org.eclipse.linuxtools.releng/maps/?root=Technology_LINUXTOOLS map file] ([http://dev.eclipse.org/viewcvs/index.cgi/releng/branches/Galileo/org.eclipse.linuxtools.releng/maps/?root=Technology_LINUXTOOLS Galileo branch] has a separate one so please add it here, too) | ||
+ | # Modify or create a new PSF file and put it [http://dev.eclipse.org/viewcvs/index.cgi/releng/trunk/org.eclipse.linuxtools.releng/psfs/?root=Technology_LINUXTOOLS here] | ||
== Galileo or Ganymede? == | == Galileo or Ganymede? == |
Revision as of 11:15, 1 April 2009
Contents
Linux Tools Release Engineering Procedures
Adding a new component
Like most Eclipse projects, our build process is feature-driven. A top-level dummy feature, org.eclipse.linuxtools.all, acts as a container which lists all of our sub-project's top-level features. These then cascade down into their plugins and the whole thing gets wrapped up into our update site and zips. In order for a new component to be built, it needs to fit into the hierarchy somewhere. When adding a new top-level sub-project feature (sub-features of existing features should get added to their containing feature), follow these steps:
Code-level checklist
- Create your feature and containing plugins
- Name the feature(s) org.eclipse.linuxtools.mycoolstuff-feature (replacing "mycoolstuff", obviously)
- Name the plugin(s) org.eclipse.linuxtools.mycoolstuff.core, org.eclipse.linuxtools.mycoolstuff.ui, etc.
- Ensure your packages are all in the org.eclipse.linuxtools namespace (and in the .mycoolstuff.core, .mycoolstuff.ui packages where appropriate)
- Create your JUnit test plugins
- Use JUnit 3 and not JUnit 4
- Name your test plugin the same as your functional plugin but with a ".tests" tacked onto the end
- Create a test.xml for use in the automated builds (see an example here)
SVN-level checklist
- If this is a new sub-project, create a directory to contain it, like "oprofile" or "autotools"
- Ensure that the standard directory structure of "branches", "tags", and "trunk" exists under your containing directory
- Check your features and plugins into SVN under trunk
- Create a tag called "initial-checkin" which is a snapshot of your initial work
- Add any new top-level feature to org.eclipse.linuxtools.all
- If you are adding a new sub-feature, ensure it is in a containing feature which itself is a part of the org.eclipse.linuxtools.all tree
- If your sub-project has dependencies outside the existing ones (BIRT, EMF, DTP, CDT), notify Andrew Overholt
- Hopefully this will have been caught in the CQ (legal review)
- Add dependency zips to build.properties
- Ensure your BREEs are correct in your plugin MANIFEST.MF files
- Add your test feature to the org.eclipse.linuxtools.test feature
- Alternatively, add to an existing test feature that is already in the org.eclipse.linuxtools.test feature hierarchy
- Add new features to our update site's multiple site.xml files
- Be sure to add dependency sites to associateSites.xml
- Add all new features, plugins, and fragments to our map file (Galileo branch has a separate one so please add it here, too)
- Modify or create a new PSF file and put it here
Galileo or Ganymede?
At present (2009-04-01), we are currently targetting Ganymede (2008 / 3.4.x) as we have existing users that we wish to support. As soon as Galileo is released, we will switch over to full-time Galileo-based development. In the meantime, we run automated builds and tests against both Ganymede and Galileo dependencies.
What does this mean for me, a contributor/committer?
If your code needs to have Galileo-specific functionality, create a 'Galileo' branch and commit the work there. Until we fully switch over to Galileo-based development, trunk should remain Ganymede-specific. Of course, it would be incredibly beneficial if you as a plugin developer could try some non-JUnit usage testing with Galileo dependencies :)
Adding a new feature to the build
- add the feature to the org.eclipse.linuxtools.all feature.xml
Building locally
- check out releng/{trunk,branches/Galileo}/org.eclipse.linuxtools.releng
- right-click on build.xml and run it as an ant build
Adding a new test plugin to those that are run during the automated build
- Create test plugin(s) (ex. org.eclipse.linuxtools.mycoolfeature.ui.tests)
- Add a test.xml like the other suites (this is used when the automated build is run)
- Ensure test.xml and any resources are listed in build.properties
- Check your plugin(s) into SVN
- If you are adding an entire test feature, add it to the included features in org.eclipse.linuxtools.test-feature
- If it's just a single test plugin (or more than one), add it/them to the included plugins in org.eclipse.linuxtools.test-feature
- Ensure the test plugin(s) do not get packed in the including feature.xml (ie. don't have "unpack=false" in the relevant plugin section of feature.xml)
- Add the test plugin(s) to the list of those to be run in testing.properties in org.eclipse.linuxtools.releng
- Add the test plugin(s)/feature(s) to the map file (be sure to update both the Galileo branch and trunk)
- Add the test plugin(s)/feature(s) to your sub-project's PSF (again, be sure to update both Galileo branch and trunk)
- Verify that your tests are built/run with a local build (see instructions on this page)
The next time a build happens, your test plugin(s) will be built and run. If you need a build pushed sooner than the next 6 hour mark when our scheduled builds happen, speak with Andrew Overholt.