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 "Linux Tools Project/Getting Involved"

(Plugin Hacking)
 
(36 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 +
{{Linux_Tools}}
 
Getting involved in the Linux Tools project is easy and new contributors are always welcome!  Many committers hang out on #eclipse-linux on Freenode and we all  
 
Getting involved in the Linux Tools project is easy and new contributors are always welcome!  Many committers hang out on #eclipse-linux on Freenode and we all  
 
monitor our mailing list, [https://dev.eclipse.org/mailman/listinfo/linuxtools-dev linuxtools-dev@eclipse.org].
 
monitor our mailing list, [https://dev.eclipse.org/mailman/listinfo/linuxtools-dev linuxtools-dev@eclipse.org].
 
= General Information =
 
A good guide to fixing Eclipse bugs can be found in [http://www.eclipse.org/articles/article.php?file=Article-How-to-Fix-a-Bug-in-Eclipse/index.html this article] by Remy Suen.
 
  
 
== Getting Code ==
 
== Getting Code ==
Our code is all maintained in the Eclipse Foundation Subversion server.  It is best to check out the code directly into Eclipse.  To do so, install either [http://subclipse.tigris.org/ Subclipse] ([http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA installation instructions]) (most committers use this) or [http://www.eclipse.org/subversive/ Subversive] ([http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php installation instructions]).  Once that is installed and functioning, check out our code using the following [[PSF|project set file]]:
+
Our code is all maintained in GitHub.  It is best to check out the code directly into Eclipse.  To do so, install [http://eclipse.org/egit/ EGit], clone the repository (https://github.com/eclipse-linuxtools/org.eclipse.linuxtools) and import the projects.
 +
 
 +
Be sure to select "Import existing projects".
  
http://dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/releng/trunk/org.eclipse.linuxtools.releng/psfs/linuxtools.psf
+
== Submitting "Patches" ==
  
# Save the PSF file to your computer
+
Patches are expected to come as GitHub PRs. See [https://docs.github.com/en/enterprise-cloud@latest/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request for details].
# In Eclipse, select File -> Import -> Team -> Team Project Set
+
# Give the location where you saved the .psf file
+
# The checkout will proceed
+
  
 
== Automated Builds ==
 
== Automated Builds ==
We use the [https://build.eclipse.org/ Eclipse Hudson server] to run continuous integration builds when SVN changes occur.  Every 6 hours we poll for SVN changes and if they have occurred, we run a full build using [http://wiki.eclipse.org/Common_Build_Infrastructure Dash Athena] and run all unit tests.  See [http://wiki.eclipse.org/Linux_Tools_Project/Releng#Building_locally instructions for building locally] for how to perform a full local build; note that this is normally not necessary for most developers.  More information on our automated build process is available on our [http://wiki.eclipse.org/Linux_Tools_Project/Releng release engineering page]. The unit tests results and output of the build including logs can be seen on our Hudson job pages:
+
We use the [https://ci.eclipse.org/ Eclipse Jenkins server] to run continuous integration builds when changes are pushed to our Git repository.  See [http://wiki.eclipse.org/Linux_Tools_Project/Releng#Building_locally instructions for building locally] for how to perform a full local build.  More information on our automated build process is available on our [http://wiki.eclipse.org/Linux_Tools_Project/Releng release engineering page]. The unit tests results and output of the build including logs can be seen on our Hudson job pages:
  
* https://build.eclipse.org/hudson/job/cbi-linuxtools-Galileo/
+
https://ci.eclipse.org/linuxtools/job/linuxtools/job/master/
* https://build.eclipse.org/hudson/job/cbi-linuxtools-Helios/
+
  
 
= Ways to get involved =
 
= Ways to get involved =
Line 25: Line 21:
 
== Plugin Hacking ==
 
== Plugin Hacking ==
 
Eclipse plugins are written in Java and developed using Eclipse itself.  It is easy to get started.
 
Eclipse plugins are written in Java and developed using Eclipse itself.  It is easy to get started.
 +
 +
[[Linux_Tools_Project/Contributor_Guide|You can find the Contributor Guide with links to setting up your development environment here]]
  
 
# Ensure you have the Eclipse Plugin Development Environment installed
 
# Ensure you have the Eclipse Plugin Development Environment installed
 
# See "Getting Code" section above and check out plugin source code
 
# See "Getting Code" section above and check out plugin source code
# If you have errors (little red 'x's), resolve them by either installing plugin dependencies or checking out the source for these dependencies into Eclipse
+
# If you have errors (little red 'x's) before ever having made changes to code, it means that you are missing plugin dependencies. Resolve them by setting your Target Platform to the one packaged with Linux Tools (see [[#Target_Platform | Target Platform]]). Alternatively, you can manually install the dependencies ("C/C++ Development Tools" is good starting points) or check out the source for all of these dependencies into Eclipse
## Hop on #eclipse-linux (Freenode) or email linuxtools-dev@eclipse.org if you have trouble
+
 
# Verify that the plugins work by running them:
 
# Verify that the plugins work by running them:
 
## Right-click on any of the plugins and select Run As -> Eclipse Application to launch a second instance of Eclipse (aka 'runtime workbench')
 
## Right-click on any of the plugins and select Run As -> Eclipse Application to launch a second instance of Eclipse (aka 'runtime workbench')
 
## By default, Eclipse will run all plugins in your workspace PLUS all plugins that are running the host Eclipse workbench
 
## By default, Eclipse will run all plugins in your workspace PLUS all plugins that are running the host Eclipse workbench
 
## Ensure menu items and general plugin functionality are present and correct in your runtime workbench
 
## Ensure menu items and general plugin functionality are present and correct in your runtime workbench
 +
## If something is missing, perhaps modify the run configuration that got created for you (Run->Run Configurations under Eclipse Application) to only have the plugins you care about (Plug-ins tab; add dependencies with "Add Required Plug-ins")
 +
## "Validate Plug-Ins" is a good button to press to see if you have issues
 +
## Email linuxtools-dev@eclipse.org if you have trouble
 
# Make changes, debug, set breakpoints, etc.
 
# Make changes, debug, set breakpoints, etc.
  
Line 42: Line 42:
  
 
''Time commitment'':  as much or as little as possible
 
''Time commitment'':  as much or as little as possible
 +
 +
=== Target Platform ===
 +
Eclipse offers the ability to set target platforms, which will download a specific environment to run your plugins, without having to "pollute" your Eclipse install. Linux Tools ships target definition files, which is the recommended way of installing its dependencies.
 +
 +
To set the target platform for the Linux Tools plugins:
 +
* Open the "org.eclipse.linuxtools.target" project, if it is not already open.
 +
* In the Preferences menu (Window->Preferences), select Plug-in Development->Target Platform. This will show a list of all available target definitions.
 +
* Check the box next to the Linux Tools target definition (linuxtools-e4.24, at the time of this writing), and click "Apply" or "OK".
 +
 +
Eclipse will now download the required dependencies, which may take some time the first time.
  
 
== Unit Tests ==
 
== Unit Tests ==
One area that is great for new contributors to help with is writing unit tests.  Right-clicking on a plugin that has "test" in its name and selecting Run As -> JUnit Plugin Test will run that plugin's unit tests.  They should all pass.  We can always use more tests written and they are a good way to learn the code.  A tool such as [http://www.eclemma.org/ EclEmma] can be used to determine unit test coverage and those plugins with low percentages are the best places to start.
+
One area that is great for new contributors to help with is writing and stabilizing unit tests and [https://wiki.eclipse.org/SWTBot/UsersGuide SWTBot] tests.  Right-clicking on a plugin that has "test" in its name and selecting Run As -> JUnit Plugin Test (or Run As -> SWTBot Test, if the plugin contains at least one SWTBot test) will run that plugin's tests.  They should all pass.  We can always use more tests written and they are a good way to learn the code.  A tool such as [http://www.eclemma.org/ EclEmma] can be used to determine unit test coverage and those plugins with low percentages are the best places to start.
  
 
''Helpful knowledge and skills'':
 
''Helpful knowledge and skills'':
 
* Eclipse plugin development
 
* Eclipse plugin development
 
* Java
 
* Java
 +
* JUnit and SWTBot
 
* Underlying tool experience if developing an Eclipse plugin to interact with an existing tool
 
* Underlying tool experience if developing an Eclipse plugin to interact with an existing tool
 
''Time commitment'':  a few hours per week
 
 
== eclipse-build (building the Eclipse SDK) ==
 
One aspect of our project is to increase the quality and quantity of Eclipse technology in Linux distributions.  A key aspect of this is the building of the Eclipse SDK.  We call our efforts here "eclipse-build".  Our work is kept in our SVN repository:
 
 
Be sure to use Subclipse or Subversive from within Eclipse to generate patches directly against SVN trunk.
 
 
''Helpful knowledge and skills'':
 
* ant
 
* p2
 
* OSGi
 
* PDE Build
 
  
 
''Time commitment'':  a few hours per week
 
''Time commitment'':  a few hours per week
  
 
== Release Engineering ==
 
== Release Engineering ==
Our automated builds are generally in good shape.  Project committers usually fix build problems quickly but there are always things we could do to make the builds more useful to developers.  Adding tools to the automated builds such as [http://pmd.sourceforge.net/ PMD], [http://findbugs.sourceforge.net/ FindBugs], [http://emma.sourceforge.net/ EMMA], etc. can really help developers find problemsThese can be done as part of Athena itself or simply enabled in our builds. [http://intellectualcramps.blogspot.com/ Dave Carver's blog] has some entries on his work in this area with other Eclipse projects.  More information is available on our [[Linux Tools Project/Releng|releng]] page.
+
Our automated builds are generally in good shape.  Project committers usually fix build problems quickly but there are always things we could do to make the builds more useful to developers.  Now that we are using [http://www.eclipse.org/tycho/ Tycho], it should be relatively simple to add such analysis toolsContact our mailing list linuxtools-dev@eclipse.org if you are interested in helping in this area.
  
When it comes time for a release, many tasks are necessary:  branching, tracking bugs, tagging SVN, running builds, verifying results, etc.  Help in this area is always appreciated.  If you see traffic on the mailing list indicating that a release is pending (these are listed in our [http://www.eclipse.org/projects/project-plan.php?projectid=technology.linux-distros project plan]), or notice that a planned release date is upcoming, email the list announcing your availability and how you can help.
+
When it comes time for a release, many tasks are necessary:  branching, tracking bugs, tagging, running builds, verifying results, etc.  Help in this area is always appreciated.  If you see traffic on the mailing list indicating that a release is pending (these are listed in our [http://www.eclipse.org/projects/project-plan.php?projectid=technology.linux-distros project plan]), or notice that a planned release date is upcoming, email the list announcing your availability and how you can help.
  
 
''Helpful knowledge and skills'':
 
''Helpful knowledge and skills'':
* [http://wiki.eclipse.org/Common_Build_Infrastructure Dash Athena]
+
* [http://www.eclipse.org/tycho/ Tycho]
* PDE Build
+
 
* Java
 
* Java
 
* p2
 
* p2
* ant
 
  
 
''Time commitment'':  varies per level but not very much
 
''Time commitment'':  varies per level but not very much
  
 
== Documentation ==
 
== Documentation ==
A few of our plugins have user guides:
+
Some of our plugins have [[Linux_Tools_Project/User_Guides | user guides]].  These are generated using [[Mylyn/WikiText | Mylyn WikiText]] ([http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.mylyn.wikitext.help.ui%2Fhelp%2FMylyn+WikiText+User+Guide.html Wiki Text User Guide]).  There are build-helper.xml files in the various doc plugins (ex. [http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/valgrind/org.eclipse.linuxtools.valgrind.doc/build-helper.xml Valgrind's build-helper.xml]) which can be modified (to reflect local Eclipse installation paths) and used to generate the HTML and fetch any new images which can then be committed to the git repo. A quick guide of how to build this Valgrind example can be found [[Linux_Tools_Project/Building_Valgrind_Doc | here]].
  
* [[Linux_Tools_Project/OProfile/User_Guide | OProfile]]
+
We could use more of them and a probably a nice guide to tie them all together.  It would also be nice to gather screenshots for the documentation upon each release.
* [[Linux_Tools_Project/Valgrind/User_Guide | Valgrind]]
+
* [[Linux_Tools_Project/SpecfileEditor/User_Guide | Specfile Editor]]
+
* [[Linux_Tools_Project/ChangeLog/User_Guide | ChangeLog]]
+
 
+
We could use more of them and a probably a nice guide to tie them all together.  It would also be nice to write use SWTBot to generate screenshots for the documentation upon each release (this is {{bug|272038}}).
+
  
 
''Helpful knowledge and skills'':
 
''Helpful knowledge and skills'':
Line 101: Line 92:
 
Our project can always use more users.  Users who provide constructive criticism and suggestions are very welcome.  Bugs should be filed via this URL:
 
Our project can always use more users.  Users who provide constructive criticism and suggestions are very welcome.  Bugs should be filed via this URL:
  
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools
+
https://github.com/eclipse-linuxtools/org.eclipse.linuxtools/issues
  
We have regular (up to 3 or 4 times per day) automated builds which are available for installation via our nightly update site:
+
[[Linux_Tools_Project/Manual Testing]] is also performed at the very least in the weeks and days prior to a release.
  
http://download.eclipse.org/technology/linuxtools/updates-nightly
+
We have regular automated builds which are available for installation via our nightly p2 repository:
 +
 
 +
http://download.eclipse.org/linuxtools/updates-nightly
  
 
''Helpful knowledge and skills'':
 
''Helpful knowledge and skills'':
  
 
* Installing and updating Eclipse plugins from an update site
 
* Installing and updating Eclipse plugins from an update site
* Bugzilla
+
* Communication via email
* Communication via Bugzilla, email/IRC
+
 
* Expected functionality of plugins
 
* Expected functionality of plugins
 
* (Sometimes) Underlying tool knowledge
 
* (Sometimes) Underlying tool knowledge
 
* (Sometimes) Running Eclipse plugins from within Eclipse workbench
 
* (Sometimes) Running Eclipse plugins from within Eclipse workbench
 
''Time committment'':  a few hours per week
 
 
== Bug Triage ==
 
Sometimes bugs are filed against the wrong component or are stuck in a state requiring more information or clarification.  Other times, bugs have been fixed but have not been marked as such in Bugzilla.  Ensuring patches which are accepted have the ''iplog'' flag set to "+" and verifying that the Version and "Target Milestone" are set correctly are ways one can help.  Helping to move the bug process along is of great help to the project.  All open project bugs can be seen [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Linux%20Tools here]
 
 
 
''Helpful knowledge and skills'':
 
 
* Bugzilla
 
* Communication via Bugzilla, email/IRC
 
* Expected functionality of plugins
 
  
 
''Time committment'':  a few hours per week
 
''Time committment'':  a few hours per week
  
 
== Web and Wiki ==
 
== Web and Wiki ==
Our [http://www.eclipse.org/linuxtools website] and [http://wiki.eclipse.org/Linux_Tools_Project wiki pages] can always use beautification, clarification, and general editing.  One good example that could use cleanup is our [http://wiki.eclipse.org/Linux_Tools_Project/Releng release engineering] page.  The website can be checked out of [[CVS]] by using [http://dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/releng/trunk/org.eclipse.linuxtools.releng/psfs/linuxtoolswebsite.psf this PSF]. For assistance with using this project set file, see [[PSF]].
+
Our [http://www.eclipse.org/linuxtools website] and [http://wiki.eclipse.org/Linux_Tools_Project wiki pages] can always use beautification, clarification, and general editing.  One good example that could use cleanup is our [http://wiki.eclipse.org/Linux_Tools_Project/Releng release engineering] page.  The website can be checked out of [[CVS]] by using [http://www.eclipse.org/linuxtools/project-info/linuxtoolswebsite.psf this PSF]. For assistance with using this project set file, see [[PSF]].
  
 
Patches for the website can be submitted [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools&component=Website here].
 
Patches for the website can be submitted [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Linux%20Tools&component=Website here].

Latest revision as of 13:57, 11 April 2022

Linux Tools
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse Source

Getting involved in the Linux Tools project is easy and new contributors are always welcome! Many committers hang out on #eclipse-linux on Freenode and we all monitor our mailing list, linuxtools-dev@eclipse.org.

Getting Code

Our code is all maintained in GitHub. It is best to check out the code directly into Eclipse. To do so, install EGit, clone the repository (https://github.com/eclipse-linuxtools/org.eclipse.linuxtools) and import the projects.

Be sure to select "Import existing projects".

Submitting "Patches"

Patches are expected to come as GitHub PRs. See for details.

Automated Builds

We use the Eclipse Jenkins server to run continuous integration builds when changes are pushed to our Git repository. See instructions for building locally for how to perform a full local build. More information on our automated build process is available on our release engineering page. The unit tests results and output of the build including logs can be seen on our Hudson job pages:

https://ci.eclipse.org/linuxtools/job/linuxtools/job/master/

Ways to get involved

Plugin Hacking

Eclipse plugins are written in Java and developed using Eclipse itself. It is easy to get started.

You can find the Contributor Guide with links to setting up your development environment here

  1. Ensure you have the Eclipse Plugin Development Environment installed
  2. See "Getting Code" section above and check out plugin source code
  3. If you have errors (little red 'x's) before ever having made changes to code, it means that you are missing plugin dependencies. Resolve them by setting your Target Platform to the one packaged with Linux Tools (see Target Platform). Alternatively, you can manually install the dependencies ("C/C++ Development Tools" is good starting points) or check out the source for all of these dependencies into Eclipse
  4. Verify that the plugins work by running them:
    1. Right-click on any of the plugins and select Run As -> Eclipse Application to launch a second instance of Eclipse (aka 'runtime workbench')
    2. By default, Eclipse will run all plugins in your workspace PLUS all plugins that are running the host Eclipse workbench
    3. Ensure menu items and general plugin functionality are present and correct in your runtime workbench
    4. If something is missing, perhaps modify the run configuration that got created for you (Run->Run Configurations under Eclipse Application) to only have the plugins you care about (Plug-ins tab; add dependencies with "Add Required Plug-ins")
    5. "Validate Plug-Ins" is a good button to press to see if you have issues
    6. Email linuxtools-dev@eclipse.org if you have trouble
  5. Make changes, debug, set breakpoints, etc.

Helpful knowledge and skills:

  • Eclipse plugin development
  • Java
  • Underlying tool experience if developing an Eclipse plugin to interact with an existing tool

Time commitment: as much or as little as possible

Target Platform

Eclipse offers the ability to set target platforms, which will download a specific environment to run your plugins, without having to "pollute" your Eclipse install. Linux Tools ships target definition files, which is the recommended way of installing its dependencies.

To set the target platform for the Linux Tools plugins:

  • Open the "org.eclipse.linuxtools.target" project, if it is not already open.
  • In the Preferences menu (Window->Preferences), select Plug-in Development->Target Platform. This will show a list of all available target definitions.
  • Check the box next to the Linux Tools target definition (linuxtools-e4.24, at the time of this writing), and click "Apply" or "OK".

Eclipse will now download the required dependencies, which may take some time the first time.

Unit Tests

One area that is great for new contributors to help with is writing and stabilizing unit tests and SWTBot tests. Right-clicking on a plugin that has "test" in its name and selecting Run As -> JUnit Plugin Test (or Run As -> SWTBot Test, if the plugin contains at least one SWTBot test) will run that plugin's tests. They should all pass. We can always use more tests written and they are a good way to learn the code. A tool such as EclEmma can be used to determine unit test coverage and those plugins with low percentages are the best places to start.

Helpful knowledge and skills:

  • Eclipse plugin development
  • Java
  • JUnit and SWTBot
  • Underlying tool experience if developing an Eclipse plugin to interact with an existing tool

Time commitment: a few hours per week

Release Engineering

Our automated builds are generally in good shape. Project committers usually fix build problems quickly but there are always things we could do to make the builds more useful to developers. Now that we are using Tycho, it should be relatively simple to add such analysis tools. Contact our mailing list linuxtools-dev@eclipse.org if you are interested in helping in this area.

When it comes time for a release, many tasks are necessary: branching, tracking bugs, tagging, running builds, verifying results, etc. Help in this area is always appreciated. If you see traffic on the mailing list indicating that a release is pending (these are listed in our project plan), or notice that a planned release date is upcoming, email the list announcing your availability and how you can help.

Helpful knowledge and skills:

Time commitment: varies per level but not very much

Documentation

Some of our plugins have user guides. These are generated using Mylyn WikiText (Wiki Text User Guide). There are build-helper.xml files in the various doc plugins (ex. Valgrind's build-helper.xml) which can be modified (to reflect local Eclipse installation paths) and used to generate the HTML and fetch any new images which can then be committed to the git repo. A quick guide of how to build this Valgrind example can be found here.

We could use more of them and a probably a nice guide to tie them all together. It would also be nice to gather screenshots for the documentation upon each release.

Helpful knowledge and skills:

  • command of the written English language
  • MediaWiki syntax
  • Minor graphics editing

Time committment: a few hours per week

Testing and Bug Filing

Our project can always use more users. Users who provide constructive criticism and suggestions are very welcome. Bugs should be filed via this URL:

https://github.com/eclipse-linuxtools/org.eclipse.linuxtools/issues

Linux_Tools_Project/Manual Testing is also performed at the very least in the weeks and days prior to a release.

We have regular automated builds which are available for installation via our nightly p2 repository:

http://download.eclipse.org/linuxtools/updates-nightly

Helpful knowledge and skills:

  • Installing and updating Eclipse plugins from an update site
  • Communication via email
  • Expected functionality of plugins
  • (Sometimes) Underlying tool knowledge
  • (Sometimes) Running Eclipse plugins from within Eclipse workbench

Time committment: a few hours per week

Web and Wiki

Our website and wiki pages can always use beautification, clarification, and general editing. One good example that could use cleanup is our release engineering page. The website can be checked out of CVS by using this PSF. For assistance with using this project set file, see PSF.

Patches for the website can be submitted here.

Helpful knowledge and skills:

  • Web design
  • Command of the written English language
  • MediaWiki syntax
  • Minor graphics editing

Time committment: a few hours per week (more if desired)

Back to the top