wtp committer faq

frequently asked questions and answers

About the FAQ

For problems with this FAQ please open a bug report .

Table of Contents

Generaltop

  1. Who do we contact in order to get commiter passwords reset?

    You need to contact the Eclipse webmaster at webmaster@eclipse.org.


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

    You can change your password using the committer tools available at https://dev.eclipse.org/committers/.


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

    There are three ways you can set up a workspace to either develop WTP or develop on the WTP base:

    1. 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. For a quick connection, paste :pserver:anonymous@dev.eclipse.org:/cvsroot/webtools into your CVS Repositories view.
      1. Download and install the WTP build you want to work with from the WTP downloads page.
      2. Create a new workspace using your installed version of WTP.
      3. Check-out any plug-ins you need to modify from the WTP CVS repository.
    2. Check-out the latest version of all the WTP plug-ins using the WTP project set. (This will extract all of the WTP plug-ins from the HEAD branch.) This method is useful if you want the most up-to-date version of the WTP plug-ins.
      1. Download the WTP team project set file from http://www.eclipse.org/webtools/development/team_project_set/wtp.psf.
      2. In your Eclipse workbench, select File->Import->Team Project Set. Select the WTP team project set file you downloaded and click Finish.

        *note: It may take a while for all the WTP plug-ins to be checked-out into your workspace.
    3. Check-out WTP plug-in Versions from a specific build. This method is useful if you want to extend or test a specific version of WTP.

      *note: this method requires that you have the Eclipse Releng plug-in installed. For information about this plug-in see the FAQ entry Is there a tool for releasing changes?.
      1. Launch Eclipse and create a simple project in your workspace.
      2. On the WTP downloads page, select the WTP build for which you want to check-out all the plug-ins. On the top of the page for the specific download, select map files and save the file as wtp.map in your simple project.

        *note: you may need to refresh your workspace for the file to be visible in it.
      3. Right click on the map file and select Team > Load Map projects. The plug-in versions from the build will be checked-out into your workspace.

        *note: It may take a while for all of the WTP plug-ins to be downloaded to your workspace.

    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.

    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 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 do 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 target milestone for a bug?

    Check with your subproject lead, as they usually have the Bugzilla edit privileges to add them.


Build/CVStop

  1. What is the CVS info for the webtools project?

    server : dev.eclipse.org
    path : /cvsroot/webtools


  2. How do I add my plug-in to the WTP CVS repository?

    1. On your plug-in project select Team->Share Project... context menu.
    2. Choose existing repository location (or create a new one if you haven't) for dev.eclipse.org:/cvsroot/webtools
    3. On the next page, if you know exactly where the plug-in should be located in the repository, then select the "Use specified module name" radio button and type in the full path. However, to be safe, it's recommended browsing the repository to obtain the correct path, and then adding the module name. Here is an example:

      Select the "Use an existing module".
      Browse and then select the folder where you want your new plug-in to reside.



      Notice that the text field is filled in with the path. Reselect the "Use specified module name:" radio button, and append your plug-in's name.




  3. Where can I find more information about CVS?

    The WTP CVS respository page contains links to useful CVS documentation including how to use Eclipse with CVS.


  4. Is there a tool for releasing changes?

    Yes. The releng tool plug-in is available from the Eclipse Project download page. Each version of Eclipse contains its own releng tool plug-in. Select the version of Eclipse you're using. The releng tool plug-in is found at the bottom of the page.


  5. How do I release my changes?

    1. Commit your changes to the CVS repository. (For information about CVS and committing see the FAQ entry Where can I find more information about CVS?). Commits for bug fixes should contain the bug number and summary for future reference, e.g. "[269600] Improve Code Folding performance".
    2. Check-out the appropriate releng project using the correct branch from the CVS repository. Each WTP subproject has its own releng project, containing the map files for its features and bundles.
    3. *note: It is strongly recommended that you use the releng tool to release your changes.

      You now have to tag your source files and update the corresponding map entries. Although you can do this manually, it is much easier and less error prone to use the releng tool. (See FAQ entry Is there a tool for releasing changes?)

      1. Select the plug-in you want to release. Right click on it and select Team->Release as shown below.

      2. Select the releng project as the map project. Click Next.
      3. If not already selected, select the plug-ins you want to release. Click Next.
      4. The page displays the changes between the last released version of the plug-in and what is currently in your workspace. Anything that is changed locally and not checked into the CVS branch will not be properly tagged. Review the changes. If everything is correct, click Next.
      5. Enter the tag you want to use to release the changes. WTP uses tags of the form vYYYYMMDDHHMM, based on the tagging time as expressed in Universal Coordinated Time. Click Next.
      6. The page displays the changes to the map files. Review the changes. If everything is correct, click Next.
      7. Enter a comment for the release operation and click Finish. The comment used will be displayed with the map file as part of the build output, so it's suggested to use a combination of the commit comments for the fixes being released.



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




  7. 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. Commit your new plug-in to the CVS repository. See How do I add my plug-in to the WTP CVS repository?

    2. Add your plug-in to the appropriate feature. Features are located under the subproject's assembly component. For example, for WST you can find features at wst/components/assembly/features.

      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"/>

      After you've added your plug-in to the feature, commit the changes and release the feature.

    3. Add your plug-in to the appropriate map file. Map files are located in the releng component. A map file entry will look like the following:

      plugin@org.eclipse.wst=v20050718_2336,:pserver:anonymous@dev.eclipse.org:/home/webtools,,wst/components/assembly/plugins/org.eclipse.wst

      After updating the map file commit it to the repository.

    4. Your plug-in is now in the repository, included in a feature, and included in a map. Now release your plug-in.

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




  8. How do I jar my plug-in?

    First of all, jarring is not an option for every plug-in. If your plug-in contains multiple jars you can't jar your plug-in.

    There are a three steps to jarring your plug-in:

    1. Update your plug-in's build.properties file to include the source.. and output.. keys as well as "." for bin.includes and src.includes as follows:

      source.. = src/
      output.. = bin/
      bin.includes = plugin.xml,\
                     META-INF/,\
                     .,\
                     plugin.properties,\
                     about.html
      src.includes = exsd/,\
                     .,\
                     build.properties
    2. Update your plug-in's manifest (MANIFEST.MF) by removing the line beginning with "Bundle-ClassPath".
    3. Update the feature entry for your plug-in to include the unpack=false attribute.

      <plugin
          id="org.eclipse.wst.common.uriresolver"
          download-size="0"
          install-size="0"
          version="0.0.0"
          unpack="false"/>




  9. How do I delete folders from the CVS repository?

    First of all, folders should not normally be deleted from the CVS repository. The repository is meant to contain the history of WTP development. That said, you may have reason to delete a folder such as you committed a folder with the incorrect name, or committed to the wrong location. In these cases:

    1. Delete the content from the folder. The content will show up in the Web view under the attic folder.
    2. Commit an obsolete.txt file in the folder. The file should contain the reasons why the folder is obsolete.
    3. Request that the Eclipse webmaster delete the folder. Requests can be made by sending the webmaster an e-mail to webmaster@eclipse.org.




Source Codetop

  1. What copyrights should we use?

    The copyright statement takes one of these two forms, differing only in the year stated on the first line of text.
    IBM copyrights below are examples only and won't apply to everyone in the community. New files you commit should be attributed to yourself or your employer according to your Committer Agreement and any employment agreements you may operate under.

    • If the file's year of invention and last year of modification are the same.
      Example:
      /*******************************************************************************
      * Copyright (c) 2005 IBM Corporation and others.
      * All rights reserved. This program and the accompanying materials
      * are made available under the terms of the Eclipse Public License v1.0
      * which accompanies this distribution, and is available at
      * http://www.eclipse.org/legal/epl-v10.html
      *
      * Contributors:
      * IBM Corporation - initial API and implementation
      *******************************************************************************/
    • If the file's year of invention and most recent year of modification are different...
      Example:
      /*******************************************************************************
      * Copyright (c) 2001,2005 IBM Corporation and others.
      * All rights reserved. This program and the accompanying materials
      * are made available under the terms of the Eclipse Public License v1.0
      * which accompanies this distribution, and is available at
      * http://www.eclipse.org/legal/epl-v10.html
      *
      * Contributors:
      * IBM Corporation - initial API and implementation
      *******************************************************************************/
      • Commits should always be covered under the EPL.



  2. Is there a tool to update the copyright?

    org.eclipse.releng.tools plug-in from Eclipse download site allows you to fix copyrights.


  3. What are the package naming conventions?

    See the WTP project naming conventions


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

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

    * <p>
    * <b>Note:</b> 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.
    * </p>

    See the WST Server core plug-in for an example.




  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.




Websitetop

  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?

    There are two ways:

    1. Check-out the whole website (www/webtools), make your changes, and run the website build script (build.xml) in the webtools folder. This will build the whole site and is useful if you need to make changes in more than one module (see below). The downside is the website is big and can take a while to download.
    2. The website is broken up into self contained modules such as community, faq, people, and plans. Check-out the module you want to make changes to (such as www/webtools/plans), make your changes, run the build script (build.xml) included in the module, and commit your changes.
    3. More recently, the switch to a Phoenix-enabled site has made much of this unnecessary.




  3. What is the CVS info for the webtools website?

    The WTP website is located in the cvs root for the Eclipse website in the www/webtools folder.

    server : dev.eclipse.org
    path : /cvsroot/org.eclipse


  4. Why do I see a javax.net.ssl.SSLHandshakeException when building the website?

    The WTP website requires access to Eclipse's bugzilla system in order to build the plans section. If you see the following error:

    javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found

    when building the site and using a Sun JRE you should update your JRE to at least Sun JRE 1.4.2_09.



WTP Logo Banner