faq/CommitterFAQ.xml - www.eclipse.org/webtools - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <faq xmlns="http://www.eclipse.org/webtools/faq"
          xmlns:faq="http://www.eclipse.org/webtools/faq"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.eclipse.org/webtools/faq schemas/faq.xsd"
          name="wtp committer faq">
   <category name="General"/>
   <category name="Build/Git"/>
   <category name="Source Code"/>
   <category name="Website"/>
   <entry id="git_1" category="Build/Git">
     <question>Where are the source code repositories for the webtools project?</question>
 	<answer>
 	WTP's source code repositories are hosted on Eclipse.org and accessed through Gerrit. The following pages allow browsing the repositories and list the current cloning URLs at the bottom of the respective pages:<br/>
 	<a href="https://git.eclipse.org/c/gerrit/webtools-common/webtools.common.git">webtools.common</a><br/>
 	<a href="https://git.eclipse.org/c/gerrit/dali/webtools.dali.git">webtools.dali</a><br/>
 	<a href="https://git.eclipse.org/c/gerrit/jeetools/webtools.javaee.git">webtools.javaee</a><br/>
 	<a href="https://git.eclipse.org/c/gerrit/jsdt/webtools.jsdt.git">webtools.jsdt</a><br/>
 	<a href="https://git.eclipse.org/c/jsf/webtools.jsf.git">webtools.jsf</a><br/>
 	<a href="https://git.eclipse.org/c/gerrit/servertools/webtools.servertools.git">webtools.servertools</a><br/>
 	<a href="https://git.eclipse.org/c/gerrit/sourceediting/webtools.sourceediting.git">webtools.sourceediting</a><br/>
 	<a href="https://git.eclipse.org/c/gerrit/webservices/webtools.webservices.git">webtools.webservices</a><br/>
 	</answer>
   </entry>
   <entry id="website_1" category="Website">
     <question>Who maintains the WTP website?</question>
     <answer>
 	  The WTP website is maintained by the WTP Committers.<br/>
       <br/>
       Problems and requests should be submitted by opening a <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Web%20Tools&amp;component=website">bug report</a>.
     </answer>
   </entry>
   <entry id="website_2" category="Website">
     <question>How do I update the WTP website?</question>
     <answer>
     	<p>
 	  		The web site is itself hosted within a git repository, whose page can be found <a href="https://git.eclipse.org/c/www.eclipse.org/webtools.git/">here</a>. Updates pushed to it are not made live immediately, but periodically published within a matter of minutes.
 	  	</p>
     </answer>
   </entry>
   <entry id="general_1" category="General">
     <question>How do I change my dev.eclipse.org password?</question>
     <answer>
 	  You can change your password using <a href="http://accounts.eclipse.org">accounts.eclipse.org</a>. Use the menu to Edit your Account and then go to the Account Settings tab.
     </answer>
   </entry>
   <entry id="general_2" category="General">
     <question>Who do we contact in order to get my password reset?</question>
     <answer>
  Use the <em>How do I reset my dev.eclipse.org password?</em> link at the sign-in page for
  <a href="http://accounts.eclipse.org">accounts.eclipse.org</a>
  .
     </answer>
   </entry>
   <entry id="general_3" category="General">
 		<question>How can I set up a workspace for WTP development/extension?</question>
 		<answer>
 			<p>
 				There are multiple ways you can set up a workspace to either develop WTP or
 				develop on the WTP base:
 				<ol>
 					<li>
 						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.
 						<ol>
 							<li>
 								Download and install a working WTP build
 								from the <a href="https://wiki.eclipse.org/WTP_FAQ#How_do_I_install_WTP.3F" target="_top">instructions</a>.
 							</li>
 							<li>
 								Create a new workspace using your installed version of WTP.
 							</li>
 							<li>
 								Clone the relevant git repository (see <a href="#git_1">the list</a>).
 							</li>
 							<li>
 								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.
 							</li>
 						</ol>
 					</li>
                     <!--
 					<li>
 						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.
 						<ol>
 							<li>
 								Download the WTP team project set file from <a href="http://www.eclipse.org/webtools/development/team_project_set/wtp.psf" target="_top">http://www.eclipse.org/webtools/development/team_project_set/wtp.psf</a>.
 							</li>
 							<li>
 								In your Eclipse workbench, select File->Import->Team Project Set. Select the WTP
 								team project set file you downloaded and click Finish.<br/>
 								<br/>
 								*note: It may take a while for
 								all the WTP plug-ins to be checked-out into your workspace.
 							</li>
 						</ol>
 					</li>
 					<li>
 						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.<br/>
 						<br/>
 						*note: this method requires that you have the Eclipse Releng plug-in installed. For information
 						about this plug-in see the FAQ entry <a href="#git_3">Is there a tool for releasing changes?</a>.
 						<ol>
 							<li>
 								Launch Eclipse and create a simple project in your workspace.
 							</li>
 							<li>
 								On the <a href="http://download.eclipse.org/webtools/downloads/" target="_top">WTP downloads page</a>,
 								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.<br/>
 								<br/>
 								*note: you may need to refresh your workspace for the file to be visible in it.
 							</li>
 							<li>
 								Right click on the map file and select <b>Team > Load Map projects</b>. The plug-in versions from the
 								build will be checked-out into your workspace.<br/><br/>
 								*note: It may take a while for all of the WTP plug-ins to be downloaded to your workspace.
 							</li>
 						</ol>
 					</li>
                     -->
 				</ol>
 				<br/>
 				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.
 			</p>
 		</answer>
 	</entry>
   <entry id="source_1" category="Source Code">
     <question>What copyrights should we use? </question>
     <answer>
       <p>Commits should always be covered under the EPL.</p>
       <p>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.<br/>
       New files <b>you</b> 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.</p>
 	  <ul>
 		<li>If the file's year of invention and last year of modification are the same.<br/>
 		  Example:<br/>
 <pre>
 /*******************************************************************************
  * Copyright (c) 2021 &lt;original author&gt;
  * 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:
  *     &lt;original author&gt; - initial API and implementation
  *
  *******************************************************************************/
 </pre>

         </li>
 		<li>If the file's year of invention and most recent year of modification are
 		  different...<br/>
 		  Example:<br/>
 <pre>
 /*******************************************************************************
  * Copyright (c) 2021, &lt;modification year&gt; &lt;original author&gt; &lt;and others (if a new person is making modifications)&gt;
  * 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:
  *     &lt;original author&gt; - initial API and implementation
  *     &lt;additional author if new&gt; - bug reference or description of change
  *
  *******************************************************************************/
 </pre>
         </li>
       </ul>
     </answer>
   </entry>
   <entry id="source_2" category="Source Code">
     <question>Is there a tool to update the copyright?</question>
     <answer>
       <B>org.eclipse.releng.tools </B>plug-in from
       <a href="https://download.eclipse.org/eclipse/downloads/">Eclipse build download site</a>
       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.
     </answer>
   </entry>
   <entry id="source_3" category="Source Code">
     <question>What are the package naming conventions?</question>
     <answer>
       See the <a href="../development/guidelines/naming-conventions.html">WTP project naming
 	  conventions</a>
     </answer>
   </entry>
   <entry id="git_2" category="Build/Git">
     <question>Where can I find more information about Git?</question>
     <answer>
 		<a href="https://wiki.eclipse.org/WTP_Git_Migration_Home">This wiki page</a> was used as a reference point when migrating WTP from CVS to Git.
     </answer>
   </entry>
   <entry id="git_3" category="Build/Git">
     <question>Is there a tool for releasing changes?</question>
     <answer>
  Not in the traditional sense. We use
  <a href="https://ci.eclipse.org/webtools">ci.eclipse.org/webtools</a>
  for Continuous Integration. It does contain a Job for publishing builds for
  milestones and releases.
     </answer>
   </entry>
   <entry id="git_4" category="Build/Git">
     <question>How do I release my changes?</question>
     <answer>
 		Releases are performed by members of the releng team, using the output of the WTP-CI_master job.
     </answer>
   </entry>
   <entry id="git_5" category="Build/Git">
     <question>What do I need to do before releasing changes?</question>
     <answer>
     	<p>
 			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.
 		</p>
 		<p>
 			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.
 		</p>
     </answer>
   </entry>
   <entry id="git_6" category="Build/Git">
     <question>How do I add a new plug-in to WTP?</question>
     <answer>
     	<p>
     		<b>Follow this procedure closely. Mistakes will likely cause a build breakage.</b><br/>
     		There are three tasks to add a new plug-in to WTP:
     		<ol>
     			<li>
     				Add your new plug-in to the correct git repository. See <a href="#git_1">Where are the source code repositories for the webtools project?</a>
     			</li>
     			<li>
     					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 <code>features</code> <a href="https://git.eclipse.org/c/gerrit/webtools-common/webtools.common.git/tree/features">directory</a>.
               <b>Your plug-in will need its requirements to be provided in the feature or that feature's dependencies.</b>
     			</li>
     			<li>
     					A feature entry will look like the following:<br />
                         <pre>
     					<plugin
          				    id="org.eclipse.wst.common.uriresolver"
          				    download-size="0"
          				    install-size="0"
          				    version="0.0.0"/>
                         </pre>
     			</li>
     			<li>
          				Create a pom.xml for the new plug-in. Use another plug-in from the same feature for guidance.
     			</li>
                 <li>
                       After you've added your plug-in to the feature, commit and push the changes.
                 </li>
     			<li>Send a note to the WTP <a href="mailto:wtp-releng@eclipse.org">release engineering</a> 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.
     			</li>
     		</ol>
     	</p>
     </answer>
   </entry>
   <entry id="source_4" category="Source Code">
     <question>What comment should I use when declaring public provisional API?</question>
     <answer>
     <p>It's best to avoid any "provisional APIs" for the sake of future binary compatibility. Make it public or leave it private.
     </p>
     	<p>
     		The following comment should be placed in each provisional API class description:<br />
     		<br />
         <pre>
 * <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>
       </pre>
  		</p>
     </answer>
   </entry>
   <entry id="source_5" category="Source Code">
     <question>What is the proper use of Javadoc @since tags?</question>
     <answer>
     	<p>
 			When you add a package or class to the API, include a single package or class level @since tag, e.g. @since 1.0.
 		</p>
 		<p>
 			When you add a method to an existing API class, add a method level @since tag.
 		</p>
 		<p>
 			These rules minimize the number of @since tags you need to include. The
 			reference for the use of Javadoc in general is available
 			<a href="http://java.sun.com/j2se/javadoc/writingdoccomments/ " target="_top">here</a>.
  		</p>
     </answer>
   </entry>
   <entry id="general_4" category="General">
     <question>What is the correct usage of severity when opening a WTP bug?</question>
     <answer>
     	<p>
 			Although this is somewhat of a judgement call, you should use the standard
 			definitions found <a href="https://bugzilla.readthedocs.io/en/5.0/using/understanding.html" target="_top">here</a>.
 		</p>
  		<p>CRITICAL severity is typically reserved for defects that either crash the IDE or irretrievably destroy the user's data.</p>
 		<p>
 			Component owners should double check open Blocker/Critical/Major bugs to
 			make sure they are accurately described.
  		</p>
  		<p>
 			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.
  		</p>
     </answer>
   </entry>
   <entry id="general_components" category="General">
   	<question>
   		How do I help users assign WTP bugs to the correct component?
   	</question>
   	<answer>
   		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:
 <pre>
 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 .
 </pre>
   	</answer>
   </entry>
   <entry id="general_targets" category="General">
   	<question>
   		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?
   	</question>
   	<answer>
   		Check with your project lead, as they usually have the Bugzilla privileges to add them using the COMMITTER TOOLS panel on <a href="https://accounts.eclipse.org">accounts.eclipse.org</a>.
   	</answer>
   </entry>
   <entry id="general_newbugs" category="General">
   	<question>
   		How can I know when new bugs are reported?
   	</question>
   	<answer>
   		Your Bugzilla <a href="https://bugs.eclipse.org/bugs/userprefs.cgi">Preferences</a> 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.
   	</answer>
   </entry>
 </faq>
	<?xml version="1.0" encoding="UTF-8"?>
	<faq xmlns="http://www.eclipse.org/webtools/faq"
	xmlns:faq="http://www.eclipse.org/webtools/faq"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.eclipse.org/webtools/faq schemas/faq.xsd"
	name="wtp committer faq">
	<category name="General"/>
	<category name="Build/Git"/>
	<category name="Source Code"/>
	<category name="Website"/>
	<entry id="git_1" category="Build/Git">
	<question>Where are the source code repositories for the webtools project?</question>
	<answer>
	WTP's source code repositories are hosted on Eclipse.org and accessed through Gerrit. The following pages allow browsing the repositories and list the current cloning URLs at the bottom of the respective pages:<br/>
	<a href="https://git.eclipse.org/c/gerrit/webtools-common/webtools.common.git">webtools.common</a><br/>
	<a href="https://git.eclipse.org/c/gerrit/dali/webtools.dali.git">webtools.dali</a><br/>
	<a href="https://git.eclipse.org/c/gerrit/jeetools/webtools.javaee.git">webtools.javaee</a><br/>
	<a href="https://git.eclipse.org/c/gerrit/jsdt/webtools.jsdt.git">webtools.jsdt</a><br/>
	<a href="https://git.eclipse.org/c/jsf/webtools.jsf.git">webtools.jsf</a><br/>
	<a href="https://git.eclipse.org/c/gerrit/servertools/webtools.servertools.git">webtools.servertools</a><br/>
	<a href="https://git.eclipse.org/c/gerrit/sourceediting/webtools.sourceediting.git">webtools.sourceediting</a><br/>
	<a href="https://git.eclipse.org/c/gerrit/webservices/webtools.webservices.git">webtools.webservices</a><br/>
	</answer>
	</entry>
	<entry id="website_1" category="Website">
	<question>Who maintains the WTP website?</question>
	<answer>
	The WTP website is maintained by the WTP Committers.<br/>
	<br/>
	Problems and requests should be submitted by opening a <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Web%20Tools&component=website">bug report</a>.
	</answer>
	</entry>
	<entry id="website_2" category="Website">
	<question>How do I update the WTP website?</question>
	<answer>
	<p>
	The web site is itself hosted within a git repository, whose page can be found <a href="https://git.eclipse.org/c/www.eclipse.org/webtools.git/">here</a>. Updates pushed to it are not made live immediately, but periodically published within a matter of minutes.
	</p>
	</answer>
	</entry>
	<entry id="general_1" category="General">
	<question>How do I change my dev.eclipse.org password?</question>
	<answer>
	You can change your password using <a href="http://accounts.eclipse.org">accounts.eclipse.org</a>. Use the menu to Edit your Account and then go to the Account Settings tab.
	</answer>
	</entry>
	<entry id="general_2" category="General">
	<question>Who do we contact in order to get my password reset?</question>
	<answer>
	Use the <em>How do I reset my dev.eclipse.org password?</em> link at the sign-in page for
	<a href="http://accounts.eclipse.org">accounts.eclipse.org</a>
	.
	</answer>
	</entry>
	<entry id="general_3" category="General">
	<question>How can I set up a workspace for WTP development/extension?</question>
	<answer>
	<p>
	There are multiple ways you can set up a workspace to either develop WTP or
	develop on the WTP base:
	<ol>
	<li>
	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.
	<ol>
	<li>
	Download and install a working WTP build
	from the <a href="https://wiki.eclipse.org/WTP_FAQ#How_do_I_install_WTP.3F" target="_top">instructions</a>.
	</li>
	<li>
	Create a new workspace using your installed version of WTP.
	</li>
	<li>
	Clone the relevant git repository (see <a href="#git_1">the list</a>).
	</li>
	<li>
	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.
	</li>
	</ol>
	</li>
	<!--
	<li>
	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.
	<ol>
	<li>
	Download the WTP team project set file from <a href="http://www.eclipse.org/webtools/development/team_project_set/wtp.psf" target="_top">http://www.eclipse.org/webtools/development/team_project_set/wtp.psf</a>.
	</li>
	<li>
	In your Eclipse workbench, select File->Import->Team Project Set. Select the WTP
	team project set file you downloaded and click Finish.<br/>
	<br/>
	*note: It may take a while for
	all the WTP plug-ins to be checked-out into your workspace.
	</li>
	</ol>
	</li>
	<li>
	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.<br/>
	<br/>
	*note: this method requires that you have the Eclipse Releng plug-in installed. For information
	about this plug-in see the FAQ entry <a href="#git_3">Is there a tool for releasing changes?</a>.
	<ol>
	<li>
	Launch Eclipse and create a simple project in your workspace.
	</li>
	<li>
	On the <a href="http://download.eclipse.org/webtools/downloads/" target="_top">WTP downloads page</a>,
	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.<br/>
	<br/>
	*note: you may need to refresh your workspace for the file to be visible in it.
	</li>
	<li>
	Right click on the map file and select <b>Team > Load Map projects</b>. The plug-in versions from the
	build will be checked-out into your workspace.<br/><br/>
	*note: It may take a while for all of the WTP plug-ins to be downloaded to your workspace.
	</li>
	</ol>
	</li>
	-->
	</ol>
	<br/>
	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.
	</p>
	</answer>
	</entry>
	<entry id="source_1" category="Source Code">
	<question>What copyrights should we use? </question>
	<answer>
	<p>Commits should always be covered under the EPL.</p>
	<p>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.<br/>
	New files <b>you</b> 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.</p>
	<ul>
	<li>If the file's year of invention and last year of modification are the same.<br/>
	Example:<br/>
	<pre>
	/*******************************************************************************
	* 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
	*
	*******************************************************************************/
	</pre>

	</li>
	<li>If the file's year of invention and most recent year of modification are
	different...<br/>
	Example:<br/>
	<pre>
	/*******************************************************************************
	* 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
	*
	*******************************************************************************/
	</pre>
	</li>
	</ul>
	</answer>
	</entry>
	<entry id="source_2" category="Source Code">
	<question>Is there a tool to update the copyright?</question>
	<answer>
	<B>org.eclipse.releng.tools </B>plug-in from
	<a href="https://download.eclipse.org/eclipse/downloads/">Eclipse build download site</a>
	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.
	</answer>
	</entry>
	<entry id="source_3" category="Source Code">
	<question>What are the package naming conventions?</question>
	<answer>
	See the <a href="../development/guidelines/naming-conventions.html">WTP project naming
	conventions</a>
	</answer>
	</entry>
	<entry id="git_2" category="Build/Git">
	<question>Where can I find more information about Git?</question>
	<answer>
	<a href="https://wiki.eclipse.org/WTP_Git_Migration_Home">This wiki page</a> was used as a reference point when migrating WTP from CVS to Git.
	</answer>
	</entry>
	<entry id="git_3" category="Build/Git">
	<question>Is there a tool for releasing changes?</question>
	<answer>
	Not in the traditional sense. We use
	<a href="https://ci.eclipse.org/webtools">ci.eclipse.org/webtools</a>
	for Continuous Integration. It does contain a Job for publishing builds for
	milestones and releases.
	</answer>
	</entry>
	<entry id="git_4" category="Build/Git">
	<question>How do I release my changes?</question>
	<answer>
	Releases are performed by members of the releng team, using the output of the WTP-CI_master job.
	</answer>
	</entry>
	<entry id="git_5" category="Build/Git">
	<question>What do I need to do before releasing changes?</question>
	<answer>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	</answer>
	</entry>
	<entry id="git_6" category="Build/Git">
	<question>How do I add a new plug-in to WTP?</question>
	<answer>
	<p>
	<b>Follow this procedure closely. Mistakes will likely cause a build breakage.</b><br/>
	There are three tasks to add a new plug-in to WTP:
	<ol>
	<li>
	Add your new plug-in to the correct git repository. See <a href="#git_1">Where are the source code repositories for the webtools project?</a>
	</li>
	<li>
	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 <code>features</code> <a href="https://git.eclipse.org/c/gerrit/webtools-common/webtools.common.git/tree/features">directory</a>.
	<b>Your plug-in will need its requirements to be provided in the feature or that feature's dependencies.</b>
	</li>
	<li>
	A feature entry will look like the following:<br />
	<pre>
	<plugin
	id="org.eclipse.wst.common.uriresolver"
	download-size="0"
	install-size="0"
	version="0.0.0"/>
	</pre>
	</li>
	<li>
	Create a pom.xml for the new plug-in. Use another plug-in from the same feature for guidance.
	</li>
	<li>
	After you've added your plug-in to the feature, commit and push the changes.
	</li>
	<li>Send a note to the WTP <a href="mailto:wtp-releng@eclipse.org">release engineering</a> 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.
	</li>
	</ol>
	</p>
	</answer>
	</entry>
	<entry id="source_4" category="Source Code">
	<question>What comment should I use when declaring public provisional API?</question>
	<answer>
	<p>It's best to avoid any "provisional APIs" for the sake of future binary compatibility. Make it public or leave it private.
	</p>
	<p>
	The following comment should be placed in each provisional API class description:<br />
	<br />
	<pre>
	* <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>
	</pre>
	</p>
	</answer>
	</entry>
	<entry id="source_5" category="Source Code">
	<question>What is the proper use of Javadoc @since tags?</question>
	<answer>
	<p>
	When you add a package or class to the API, include a single package or class level @since tag, e.g. @since 1.0.
	</p>
	<p>
	When you add a method to an existing API class, add a method level @since tag.
	</p>
	<p>
	These rules minimize the number of @since tags you need to include. The
	reference for the use of Javadoc in general is available
	<a href="http://java.sun.com/j2se/javadoc/writingdoccomments/ " target="_top">here</a>.
	</p>
	</answer>
	</entry>
	<entry id="general_4" category="General">
	<question>What is the correct usage of severity when opening a WTP bug?</question>
	<answer>
	<p>
	Although this is somewhat of a judgement call, you should use the standard
	definitions found <a href="https://bugzilla.readthedocs.io/en/5.0/using/understanding.html" target="_top">here</a>.
	</p>
	<p>CRITICAL severity is typically reserved for defects that either crash the IDE or irretrievably destroy the user's data.</p>
	<p>
	Component owners should double check open Blocker/Critical/Major bugs to
	make sure they are accurately described.
	</p>
	<p>
	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.
	</p>
	</answer>
	</entry>
	<entry id="general_components" category="General">
	<question>
	How do I help users assign WTP bugs to the correct component?
	</question>
	<answer>
	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:
	<pre>
	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 .
	</pre>
	</answer>
	</entry>
	<entry id="general_targets" category="General">
	<question>
	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?
	</question>
	<answer>
	Check with your project lead, as they usually have the Bugzilla privileges to add them using the COMMITTER TOOLS panel on <a href="https://accounts.eclipse.org">accounts.eclipse.org</a>.
	</answer>
	</entry>
	<entry id="general_newbugs" category="General">
	<question>
	How can I know when new bugs are reported?
	</question>
	<answer>
	Your Bugzilla <a href="https://bugs.eclipse.org/bugs/userprefs.cgi">Preferences</a> 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.
	</answer>
	</entry>
	</faq>