Skip to main content

wtp committer faq

frequently asked questions and answers

About the FAQ

For problems with this FAQ please open a bug report .

Table of Contents

General

  1. How do I change my dev.eclipse.org password?

    You can change your password using accounts.eclipse.org. Use the menu to Edit your Account and then go to the Account Settings tab.

  2. Who do we contact in order to get my password reset?

    Use the How do I reset my dev.eclipse.org password? link at the sign-in page for accounts.eclipse.org.

  3. How can I set up a workspace for WTP development/extension?

    There are multiple ways you can set up a workspace to either develop WTP or develop on the WTP base:
    1. The most popular method is to install WTP and check-out only the plug-ins you are interested in, from the Branch you are interested in. This method is useful if you are only working with a subset of WTP functionality or extending WTP.
      1. Download and install a working WTP build from the instructions.
      2. Create a new workspace using your installed version of WTP.
      3. Clone the relevant git repository (see the list).
      4. The projects in our repositories are IDE-first, and include the .project files so they can be used immediately as Plug-in and Feature projects. Import the intended project into your workspace from the Git Repositories View.

    All three options require compiling some or all of WTP within your workspace, so your Plug-in Development Target Platform should contain the corresponding WTP prerequisites.

  4. What is the correct usage of severity when opening a WTP bug?

    Although this is somewhat of a judgement call, you should use the standard definitions found here.

    CRITICAL severity is typically reserved for defects that either crash the IDE or irretrievably destroy the user's data.

    Component owners should double check open Blocker/Critical/Major bugs to make sure they are accurately described.

    Although a user may feel strongly about their favourite bug, we should still classify it correctly. We do have some leeway in assigning it a priority, i.e. if we feel that a bug should be fixed, we can up its priority. P1 should be reserved for release-defining functions, .i.e we stop ship if P1's are not fixed.


  5. How do I help users assign WTP bugs to the correct component?

    When users assign a WTP bug to the wrong component, you should assign it to the correct component, resetting it to the default assignee, and paste in the following message as a comment: 
      		
Thank you for reporting this bug. I have assigned to the correct component.
For guidance on how to select the correct component in future bug reports, please refer to:
https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Web+Tools .

  6. How can I know when new bugs are reported?

    Your Bugzilla Preferences link (see the bottom of any Bugzilla page once logged in) allows you to specify a 'watch list' of user emails to be copied on. Most components have an inbox address that you can watch. You can also query Bugzilla with the correct inbox address as the Assignee and subscribe to the results as an RSS feed from the results page using the 'Feed' link at the bottom.

  7. What do I do if I don't see the right Version to report a bug against, or target milestone for marking a bug fixed?

    Check with your project lead, as they usually have the Bugzilla privileges to add them using the COMMITTER TOOLS panel on accounts.eclipse.org.

Build/Git

  1. Where are the source code repositories for the webtools project?

    The source code repositories that contain the code for the webtools project are hosted on GitHub:
    webtools.common
    webtools.dali
    webtools.javaee
    webtools.jsf
    webtools.servertools
    webtools.sourceediting
    webtools.webservices
    webtools.jsdt
    The website and repositories for release engineering are hosted on the GitLab from the Eclipse Foundation:
    Webtools Website
    Webtools Releng
    Webtools Releng Aggregator

  2. Where can I find more information about Git?

    This wiki page was used as a reference point when migrating WTP from CVS to Git.

  3. Is there a tool for releasing changes?

    Not in the traditional sense. We use ci.eclipse.org/webtools for Continuous Integration. It does contain a Job for publishing builds for milestones and releases.

  4. How do I release my changes?

    Releases are performed by members of the releng team, using the output of the WTP-CI_master job.

  5. What do I need to do before releasing changes?

    It depends. If you're releasing an isolated fix, you're probably safe to run the JUnit tests for the plug-in and, if all pass, release your fix. If you're making a breaking provisional API change (remember, you cannot make breaking API changes) you should announce the change to the WTP dev list advising what has changed, why, and how existing consumers of the provisional API can adapt their plug-ins to the change.

    It is also good practice to use a current WTP development build when making changes so as prevent compilation failures. Catching compilation or unit test failures is a poor use of the build system's processing time.


  6. How do I add a new plug-in to WTP?

    Follow this procedure closely. Mistakes will likely cause a build breakage.
    There are three tasks to add a new plug-in to WTP:
    1. Add your new plug-in to the correct git repository. See Where are the source code repositories for the webtools project?
    2. Add your plug-in to the appropriate feature.xml. Features are typically in their own directory. For example, for Common you can find features under the top-level features directory. Your plug-in will need its requirements to be provided in the feature or that feature's dependencies.
    3. A feature entry will look like the following:
      <plugin
    id="org.eclipse.wst.common.uriresolver"
    download-size="0"
    install-size="0"
    version="0.0.0"/>
    4. Create a pom.xml for the new plug-in. Use another plug-in from the same feature for guidance.
    5. After you've added your plug-in to the feature, commit and push the changes.
    6. Send a note to the WTP release engineering mailing list mentioning the plug-in's addition. It is possible that the build process itself may require updates to accommodate the addition, such as touchups to releng-specific BVTs.

Source Code

  1. What copyrights should we use?

    Commits should always be covered under the EPL.

    The copyright statement required in each source file takes one of these two forms, differing only in the year stated on the first line of text.
    New files you commit are copyrighted by yourself or your employer according to your Eclipse Contributor Agreement and any employment agreements you may operate under, and licensed to everyone under EPL 2.0--including to WTP.

    • If the file's year of invention and last year of modification are the same.
      Example:
      /*******************************************************************************
 * Copyright (c) 2021 <original author>
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License 2.0
 * which accompanies this distribution, and is available at
 * https://www.eclipse.org/legal/epl-2.0/
 *
 * SPDX-License-Identifier: EPL-2.0
 *
 * Contributors:
 *     <original author> - initial API and implementation
 *
 *******************************************************************************/
    • If the file's year of invention and most recent year of modification are different...
      Example:
      /*******************************************************************************
 * Copyright (c) 2021, <modification year> <original author> <and others (if a new person is making modifications)> 
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License 2.0
 * which accompanies this distribution, and is available at
 * https://www.eclipse.org/legal/epl-2.0/
 *
 * SPDX-License-Identifier: EPL-2.0
 *
 * Contributors:
 *     <original author> - initial API and implementation
 *     <additional author if new> - bug reference or description of change
 *
 *******************************************************************************/

  2. Is there a tool to update the copyright?

    org.eclipse.releng.tools plug-in from Eclipse build download site allows you to fix copyrights. It should not needed as developers should check the top of every modified file for the current year before committing/merging changes.

  3. What are the package naming conventions?

    See the WTP project naming conventions

  4. What comment should I use when declaring public provisional API?

    It's best to avoid any "provisional APIs" for the sake of future binary compatibility. Make it public or leave it private.

    The following comment should be placed in each provisional API class description:

    * 
    
* Note: This class/interface is part of an interim API that is still under development and expected to
* change significantly before reaching stability. It is being made available at this early stage to solicit feedback
* from pioneering adopters on the understanding that any code that uses this API will almost certainly be broken
* (repeatedly) as the API evolves.
*


  5. What is the proper use of Javadoc @since tags?

    When you add a package or class to the API, include a single package or class level @since tag, e.g. @since 1.0.

    When you add a method to an existing API class, add a method level @since tag.

    These rules minimize the number of @since tags you need to include. The reference for the use of Javadoc in general is available here.


Website

  1. Who maintains the WTP website?

    The WTP website is maintained by the WTP Committers.

    Problems and requests should be submitted by opening a bug report.

  2. How do I update the WTP website?

    The web site is itself hosted within a git repository, whose page can be found here. Updates pushed to it are not made live immediately, but periodically published within a matter of minutes.


WTP Logo Banner

Back to the top