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 "Mylyn/Contributor Reference"

(Sandbox)
(Experimental tools)
Line 156: Line 156:
 
* '''Interest Level Decorator''': displays the floating point interest level of elements.  Enable via ''Decorators'' preference page.
 
* '''Interest Level Decorator''': displays the floating point interest level of elements.  Enable via ''Decorators'' preference page.
  
== Experimental tools ==
+
=== Experimental tools ===
  
 
The following experimental views can be opened via the ''Mylar Sandbox'' view category.
 
The following experimental views can be opened via the ''Mylar Sandbox'' view category.

Revision as of 23:41, 3 January 2007


Also see: helpwanted bugs discussion bugs eclipse dev

Conventions

All contributions to Mylar need to be made using Mylar since it links source changes to tasks and contexts, making open development and collaboration easier. Using Mylar ensures that:

  • All Bugzilla reports have a corresponding task context, making them easy to reopen or pick up by you and by others.
  • All commits correspond to a single Bugzilla report, making it easy to navigate from changes to bugs.

Also see: Eclipse coding conventions, User Interface Guidelines, Eating your own dog food

The [Eclipse Charter] explains how people get commit rights.

Bugzilla

  • Any user-reported bug should be resolved by one of: code improvements, documentation/FAQ improvements, or being marked a duplicate of another bug. All but the last require attaching a context.
  • Be judicious in marking bugs for LATER, because this typically communicates that the bug will never be resolved. Do this only if the bug does not fit in with the current scope of the project but is related to the mission. Otherwise mark P4/P5 and "helpwanted" to encourage a contribution that is not part of our current prioritization and plan.

Communication

Mylar committers are required to follow these guidelines. Our philosophy is that the user is always right, even if it takes time to figure out how or why they are right. Our project thrives on the feedback of users, whether they are seasoned experts or newbies. Feedback defines how the tool should work, how it should be simplified, and how it should evolve.

  • All user feedback contains information, and it is the responsibility of committers to turn that information into actions. This can mean improving the implementation, simplifying the workflow, clarifying the documentation, or noting a duplicate request. Making the actions we take clear helps communicate this philosophy to our growing user community and encourages high-quality feedback.
  • If users do not provide enough information or do not take the time to provide accurate information, they should be prompted to provide the necessary details. If they do not do so in a timely manner, the feedback is incomplete and can be resolved without taking action.
  • Always show respect to users, whether they are making correct or incorrect assumptions about the tool. When they are making incorrect assumptions it is because we have not done our job well enough, or because the platforms we build on are making it hard for us to do our job well enough. Identifying those cases is important so that we can provide feedback to those platforms and find work-arounds.
  • Never turn user feedback or discussion away by being condescending, short, or insulting. Forms of humor that work for face-to-face communication, such as sarcasm, should be avoided because they result in misinterpretation, especially when there is a language or cultural barrier. Use of emoticons is not a work-around.
  • Review public communication before sending. Things that are not meant to be intentionally disrespectful can come across that way. When reviewing try to shorten in order to show respect for your audience's time.

Workspace setup

First, install Eclipse and get it configured for developing Java 5 applications.

Then save and import one or more the project sets (listed below) via File -> Import -> Team Project Set. To check out manually or use seperate projects, view the contents of the .psf file(s).

If you using the headless frameworks only, you can import use the following project set:

Optional installs for committers:

Note that you will need a Subversion client (e.g. install Subclipse) in order to import the Tigris dependencies (needed for Jira), and you will need to download Jira if you want to run the tests in org.eclipse.mylar.tests. You do not need Jira to run the tests in org.eclipse.mylar.java.tests.

Running tests

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

  • Add a credentials.properties file to org.eclipse.mylar.context.tests and put the following into it:
   user: <user>
   pass: <pass>
  • For <user> use "tests<at sign>mylar.eclipse.org". For <pass> use "<project's name lowercase>test". If you have any trouble making this work email mylar-dev@eclipse.org.
  • Add the following to the test configuration under Arguments -> VM Arguments: -enableassertions -Xmx384M

To run the AllTests suite follow the above steps and

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

Manual Tests

  • Some features of Mylar must be tested manually. The manual tests can be found on the Mylar Testing page.
  • Component owners are responsible for maintaining their respective manual tests and ensuring they are covered two days prior to release.

Building Connectors

Trac

JIRA

  • 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.

Self-hosting

Self-hosting, also known as working bootstrapped (i.e. self-hosted) makes eating your own dog food easier and avoids having to update to dev builds.

The following is an example of how to set up a bootstrap workspace, using Eclipse 3.3 on Windows and a C:/Dev workspace directory as an example.

  • Create a new directory for your build workspace, e.g.: C:/Dev/build-3.3
  • Launch Eclipse with this workspace, e.g.: C:\Apps\eclipse-3.3\eclipse.exe -data C:\Dev\build-3.3
  • Check out Mylar from CVS into this workspace, see #Workspace setup
  • Create a new Launch Configuration:
    • SelectRun -> Run... -> create a new Eclipse Application.
    • Call the application Mylar Bootstrap.
    • On the Main tab, set the Location (e.g. C:/Dev/workspace).
      • You can use an existing workspace that you used Mylar with, or
      • You can create a new directory. If you create a new directory, you will need to check out the Mylar source code as above.
  • Launching with this launch configuration will give you a second workbench with Mylar. This workbench will be created based on the target platform (the workbench you're launching from) and the plugins in C:/Dev/build-3.3.
  • Do your development in the runtime workspace (C:/Dev/build-3.3).
  • Whenever your changes make it into HEAD that you would like to use, close your runtime workspace (C:/Dev/workspace), update from CVS in the build workspace (C:/Dev/build-3.3), and then re-launch your runtime workspace.

Notes:

  • The launching workspace will typically consume very little memory.
  • Working in bootstrap mode means you have the source code checked out at least twice, once to bootstrap Mylar, and once to actually develop.
  • You must have two distinct workspaces, you can't bootstrap into the same workspace as you launch from.
  • 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. This is because the hot-swap virtual machine can only change method bodies, not class definitions.

Contributing patches

Creating:

  • Each patch should correspond to a single bug report, and a single patch should be made for each set of changes to be reviewed.
  • A task context should be attached to each patch to make applying and evolving it easier.
  • 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/mylar-settings-formatter.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 or make significant modification to, placed below any existing author tags and indicating the bug, e.g.: @author Rob Elves (bug 160315)
  • Ensure that there is no console output. For logging errors use MylarStatusHandler.

Submitting:

  • Ensure there are no build errors, warnings, and that org.eclipse.mylar.tests.AllTests passes.
  • Do not include binary files such as GIF icons in the patch, they need to be attached separately.
  • 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).
  • Indicate any changes made to the existing UI in the comment (e.g. reordering of menu actions).
  • 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 org.eclipse.mylar.java, 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

Deploying:

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

Web site authoring

  • Create a new CVS location: dev.eclipse.org:/cvsroot/org.eclipse
  • 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

Sandbox

The sandbox is a location in CVS that contributors use for experimenting with features that are not part of the standard Mylar release. These include experimental connectors and bridges, experimental UI features, and developer tools. Sandbox tools:

  • Can be made available for download in the dev builds under the Sandbox (Experimental) category.
  • Can have dependencies on libraries that need to be installed locally, i.e. are not checked in and not redistributed. This means that you may need to download additional libraries for some sandbox plug-ins to compile.
  • Follow the same conventions as the other Mylar components.

Dev tools

  • Introspect Object (action): displays the class and other relevant information (e.g. degree-of-interest, task synchronization state) of any object visible in the workbench. Appears at the end of the context menu for any view that accepts an object contributions.
  • Interest Level Decorator: displays the floating point interest level of elements. Enable via Decorators preference page.

Experimental tools

The following experimental views can be opened via the Mylar Sandbox view category.

  • Context Search: automatically finds and displays elements that are structurally related to landmarks in the active . These elements become part of the task context and have a predicted degree-of-interest.
  • Context Hierarchy: displays the Java hierarchy of all landmark elements.

Tips and Tricks

Code

  • For error handling use MylarStatusHandler.
  • When using String.toLowerCase(), use String.toLowerCase(Locale.ENGLISH) to ensure locale safety (see bug 168652).

Bugzilla

  • Query setup: If you are added to the cc list on a report that is not picked up by your usual queries it may go unnoticed. One trick is to create a query for ALL products except the product you usually work in (and hence have queries for) and set the cc field of the query to your id. Now you will be notified of anybody adding you to the cc of a product you don't usually monitor.

JDT

  • Including Platform plug-ins in search: Java search (Ctrl+H > Java Search) will include all plugins in your Plugin-in Dependencies. If you want to search other plugins as well, open the Plug-ins view, right click on the desired plugin(s) and choose 'Add to Java Search'. That plugin will now always be included in your java searches.

Debugging

  • Plug-ins fail to load: verify that plug-in dependencies are met via the Validate Plug-in Set button on the launch configuration Plug-ins tab.
  • Startup failure: If you get an IStartup failure message or a ClassNotFoundException on startup this is often the result of some step in the activation of the plug-in failing.
    • Attempt to find the earliest exception thrown within the in the plug-in's activation process. For example, this could occur in TasksUiPlugin.start() or TasksUiPlugin.<init>.
    • If the cause of the failure is not straightforward, the problem could be due to a class loading race condition. This can sometimes be verified by trying a different VM like IBM's or BEA's and checking if that resolves the problem. If this is the case, please file a bug.

Back to the top