Skip to main content
Jump to: navigation, search

Mylyn/Contributor Reference

< Mylyn
Revision as of 22:31, 24 July 2006 by (Talk | contribs) (JIRA)

Also see: helpwanted bugs discussion bugs eclipse dev


  • Use the latest verison of Mylar for development.
  • Follow coding conventions.
  • Use Bugzilla priorities to make weekly planning transparent: P1: must do this week, P2: should do this week, P3: consider for this target milestone, P4/5: requires user input.

Workspace setup

Get the latest Eclipse milestone release, and associate J2SE-1.5 with your installed JRE via the Execution Environments preference page. Then import one or more the project sets via Import -> Team Project Set. To check out manually or use seperate projects view the contents of the .psf file(s):

Optional installs:

Running tests

Each component has it's own All<Component>Tests suite.

  • Add the following to the test configuration under Arguments -> VM Arguments: -enableassertions -Xmx384M
  • Add a file to org.eclipse.mylar.bugzilla.tests, and define "username: xxx" and "password: yyy" in it. Email for a username and password.

To run the AllTests suite follow the above steps and

  • Check out all of the connector project sets.
  • Check out org.eclipse.mylar.tests

Building Connectors


  • Create a working set that excludes org.tigris.jira plug-ins so that you have no warnings in the Problems list.
  • Refer to the JIRA Dahsboard doc for troubleshooting.


Working bootstrapped

Working bootstrapped (i.e. self-hosted) makes eating your own dog food easier and avoids having to update to dev builds:

  • Set up a fresh workspace launched from an Eclipse that does not have Mylar installed, and check out Mylar into it.
  • Create a new Launch Configuration, point it at your workspace, and work in that. Note that the launching workspace will typically consume very little memory.
  • Whenever your changes make it into HEAD close your runtime workspace, update from CVS, and then re-launch. It is possible to run in debug mode so that the changes apply to the workspace immediately after synch, but this can cause problems with the running workspace if classes change or go missing.

Contributing patches

All contributions to Mylar including patches should be made by using Mylar in order to ensure that we eat our our own dog food. A task context should be attached to each patch to make applying and evolving it easier.

  • Each patch should correspond to a single bug report, and a single patch should be made for each set of changes to be reviewed.
  • With few exceptions patches should be accompanied by a JUnit test, and in general unit tests are one of the most valuable and long-lived contributions. If you are having trouble writing a test (e.g. trickiness verifying what happens in the UI) comment on the corresponding bug report so that we can point you at similar test cases or consider extending the test harness if needed.
  • Minimize the amount of changes to existing code to make review easier.
  • Synchronize often to ensure you have the latest code. Once you start modifying resources, put the Synchronize view in Outgoing mode and press the Change Set button so that Mylar tracks the context for the patch.
  • Before creating a new JUnit test class class check the components test suite for similar test cases (e.g. AllTasklistTests).
  • Set the formatter by importing org.eclipse.mylar/developer/javaFormatterSettings.xml into Window -> Preferences -> Java -> Code Style -> Formatter. Format code using Eclipse's formatter (Ctrl+Shift+F) and ensure that no have been added.
  • Add an @author tag to each class that you create.
  • Ensure that there is no console output. For logging errors use MylarStatusHandler.

To submit:

  • Ensure there are no build errors, warnings, and that org.eclipse.mylar.tests.AllTests passes.
  • Synchronize using Incoming mode and ensure that there are no conflicts, and merge them locally if there are.
  • Right click the task context change set (or the project containing the patch--patches should be made for a project, not a file), press Team -> Create Patch, and make the file suffix ".txt".
  • Attach the patch to the bug report, and indicate in the comment what testing was done to validate it (e.g. unit test coverage, manual tests performed).
  • Attach the task context to the bug report.

Building a distribution

  • Using PDE Build support to create a Mylar distribution from HEAD, using a plain Eclipse 3.2
    • org.eclipse.mylar-feature/feature.xml -> Overview -> change version number to current date (e.g. 0.4.7.v20060125-0800)
      • On Plug-ins tab -> Versions... -> Force feature version into plug-in and fragment manifests
      • Repeat above for org.eclipse.mylar-bugzilla-feature.xml
    • org.eclipse.mylar-site/e3.2/site.xml
      • Delete old features (grayed out)
      • Add new mylar-bugzilla and mylar features
      • Hit Build All (if this fails restart Eclipse and try again)
  • To install, add the path of org.eclipse.mylar-site/e3.2/site.xml as a local update site
  • Bugzilla support can be built independently of the Mylar UI by checking out the following projects mylar.bugzilla.core, mylar.bugzilla.ui, mylar.tasklist, mylar.core

Merging and building the 3.1 branch:

  • Right-click the, mylar.ide, and mylar.xml project, Team -> Switch to Another Branch..., then Refresh the Branches and select e_3_1
  • The list of files that should not be overwritten is in: org.eclipse.mylar-site/merge.text


  • Instructions are in org.eclipse.mylar-site/release.txt

Web site authoring

  • Create a new CVS location:
  • Check out www/mylar as a project
  • To push documentation from org.eclipse.mylar.doc to the web site use the targets in mylar/build.xml

Back to the top