https://wiki.eclipse.org/api.php?action=feedcontributions&user=Thanh.ha.eclipse.org&feedformat=atomEclipsepedia - User contributions [en]2024-03-28T23:37:53ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=Evangelism/Simultaneous_Release_Parties&diff=365453Evangelism/Simultaneous Release Parties2014-06-20T11:44:37Z<p>Thanh.ha.eclipse.org: /* Sign Up */</p>
<hr />
<div>== Ottawa==<br />
<br />
===Sign Up===<br />
<br />
Please add your names here, just so we'll know how many are coming.<br />
<br />
* Edouard Poitras<br />
* Olivier Thomann<br />
* Paul Webster<br />
* Doug Schaefer<br />
* Thanh Ha<br />
<br />
=== Details === <br />
<br />
We've got a small tab that we'll use to buy a few beers or pepsi's and some finger foods.<br />
<br />
====Date/Time ====<br />
June 25 @ 14:00hr<br />
<br />
====Location====<br />
[http://www.royaloakpubs.com/centrepointe.html Royal Oak on Centrepointe]<br />
<br />
====Questions====<br />
Email emo@eclipse.org</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=Building_C/C%2B%2B_at_Eclipse&diff=363474Building C/C++ at Eclipse2014-05-23T20:13:47Z<p>Thanh.ha.eclipse.org: /* Using Hudson (HIPP) */</p>
<hr />
<div>Projects can currently build C and C++ code on the following platforms:<br />
<br />
== Linux x86_64 ==<br />
<br />
=== Using Hudson (HIPP) ===<br />
Projects can request their own instance of Hudson (called HIPP) which operates within the security context of their project (meaning the Hudson instance can OPTIONALLY write to the project's Git repos and downloads area for easy build artifact publishing.)<br />
<br />
The tools available are:<br />
* Hudson 3.0.1-b2<br />
* make, cc, gcc, as typically found on modern Linux systems<br />
* bash, sh, tsh, as typically found on modern Linux systems<br />
* most other associated build tools available on Linux systems<br />
<br />
'''Example: ''' the TCF project operates a HIPP instance, and has a Linux agent build job which invokes 'cc'. The latest build log is available here, which demonstrates the usage of Hudson invoking a shell script, which invokes make and cc: https://hudson.eclipse.org/tcf/job/tcf-agent-x86Linux-master/lastBuild/console<br />
<br />
=== Using build.eclipse.org ===<br />
Committers with SSH access can use the shell service on build.eclipse.org. It is a server running SuSE Linux Entreprise 11 with a host of C/C++ build tools, such amake, cc and gcc.<br />
<br />
<br />
== Windows x86_64 ==<br />
There are plans to deploy Windows HIPP (Hudson) slaves. The current plan is to deploy a dedicated Virtual Machine for each project, running:<br />
<br />
- one Windows flavour (likely Windows 7 Professional)<br />
- MS Visual Studio<br />
- PowerShell<br />
<br />
We are still in the early stages of planning, and requirements gathering is happening in this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=415757<br />
<br />
== Mac OS X ==<br />
We do not have requirements for building C/C++ code on Mac. Please file a bug against Eclipse Foundation/Community/Hudson.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP_Readiness_For_CBI&diff=362848WTP Readiness For CBI2014-05-16T18:23:45Z<p>Thanh.ha.eclipse.org: </p>
<hr />
<div>This wiki page captures the the readiness of WTP projects to move from PDE to CBI builds. <br />
<br />
'''Instructions: ''' Find your project in the table below and mark each task and overall readiness with either a "checkmark" or "cross". The Comment column is meant to capture differences, or overall comments in each projects analysis of build artifacts. <br />
<br />
The Build comparison should be done using same day builds (I used 5/8 builds) [https://bugs.eclipse.org/bugs/show_bug.cgi?id=420889 This bug is driving this task]<br />
<br />
Smoketests should be done on a recent build (like 5/8) - [https://hudson.eclipse.org/webtools/job/cbi-build/ builds are located here] - I used the repository<br />
<br />
Your vote in the below table will not trigger any immediate action. The information collected will be used for further discussions and plans on using the CBI output in the Luna aggregation builds.<br />
<br />
[[Image:Checkmark.gif]] = I feel comfortable moving to CBI for Luna release<br />
[[Image:Fail.gif]] = I don't feel comfortable moving to CBI yet - more work to be done<br />
[[Image:Questionmark.gif]]= Readiness status pending<br />
<br />
{| cellpadding="5" border="3"<br />
|-<br />
! Project Lead <br />
! Build Comparison<br />
! CBI Build Smoketest <br />
! Overall Readiness <br />
! Comments<br />
|-<br />
! colspan="5" | ''Common Tools''<br />
|-<br />
| Carl Anderson <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
|-<br />
! colspan="5" | ''Dali''<br />
|-<br />
| Neil Hauge <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
|<br />
|-<br />
! colspan="5" | ''EJB Tools''<br />
|-<br />
| Kaloyan Raev <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br><br />
|-<br />
! colspan="5" | ''Java EE Tools''<br />
|-<br />
| Chuck Bridgham <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| Other than changes in size because of jar signing... The one major difference in CBI is the generation of xxx.userdoc.feature.source jar's - these are a waste - and should be removed (bug 434890), but doesn't prevent moving forward.<br />
|-<br />
! colspan="5" | ''JavaScript Development Tools''<br />
|-<br />
| Christopher Jaun <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
|-<br />
! colspan="5" | ''JavaServer Faces''<br />
|-<br />
| Raghunathan Srinivasan <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| Source features (''org.eclipse.jsf.feature.source'', ''org.eclipse.jst.jsf.apache.trinidad.tagsupport.feature.source'', ''org.eclipse.jst.webpageeditor.feature.source'') contain '''build.properties''' in CBI, where they did not in legacy build.<br />
Extra plug-in in CBI: ''org.eclipse.jst.jsf.doc.user.source''.<br />
<br />
These should be investigated, but are not reason to prevent moving to CBI.<br />
|-<br />
! colspan="5" | ''Release Engineering''<br />
|-<br />
| Carl Anderson <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
|-<br />
! colspan="5" | ''Server Tools''<br />
|-<br />
| Elson Yuen <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]]<br />
| [[Image:Questionmark.gif]] <br />
| JUnit not running yet.<br />
|-<br />
! colspan="5" | ''Source Editing''<br />
|-<br />
| Nick Sandonato <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| Extra plugins in CBI build (Bug 435092):<br />
org.eclipse.jst.jsp.ui.infopop.source,<br />
org.eclipse.wst.dtd.ui.infopop.source,<br />
org.eclipse.wst.dtdeditor.doc.user.source,<br />
org.eclipse.wst.html.ui.infopop.source,<br />
org.eclipse.wst.sse.doc.user.source,<br />
org.eclipse.wst.sse.ui.infopop.source,<br />
org.eclipse.wst.standard.schemas.source,<br />
org.eclipse.wst.xml.ui.infopop.source<br />
|-<br />
! colspan="5" | ''Web Services Tools''<br />
|-<br />
| Keith Chong <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
<br />
'''Web Services and WSDL''' ( [[Image:Questionmark.gif]] , [[Image:Questionmark.gif]] , [[Image:Questionmark.gif]] )<br />
<br />
Build comparison - TBD<br />
<br />
Failing test: org.eclipse.wst.validation.test<br />
<br />
Failing test: org.eclipse.wst.wsi.tests.internal.BasicProfileAnalyzerTest.testReportWriterIsClosedAfterReportIsFinished<br />
<br />
<br />
'''JAX-WS sub-component''' ( [[Image:Checkmark.gif]] , [[Image:Checkmark.gif]] , [[Image:Checkmark.gif]] )<br />
<br />
Extra feature included in CBI build (Bug 435094):<br />
<br />
org.eclipse.jst.ws.jaxws_userdoc.feature.source<br />
<br />
Other source features in CBI build contain an additional file: build.properties<br />
org.eclipse.jst.ws.cxf.feature.source<br />
org.eclipse.jst.ws.jaxws.dom.feature.source<br />
org.eclipse.jst.ws.jaxws.feature.source<br />
<br />
Differences in jars files sizes between PDE and CBI because of jar signing.<br />
<br />
One failing test:<br />
org.eclipse.jst.ws.jaxws.dom.runtime.tests.annotations.AnnotationFactoryTest.testRemoveAnnotationsIMethod <br />
<br />
Same NPE error reported in that test also thrown in these two:<br />
org.eclipse.wst.server.ui.tests.dialog.DialogsTestCase.testDeleteServerDialog<br />
org.eclipse.wst.common.snippets.tests.providers.TextProviderTests.testTextSnippetCreation<br />
<br />
|}<br />
<br />
[[Category:Eclipse_Web_Tools_Platform_Project|Eclipse_Web_Tools_Platform_Project]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP_Readiness_For_CBI&diff=362847WTP Readiness For CBI2014-05-16T18:05:15Z<p>Thanh.ha.eclipse.org: </p>
<hr />
<div>This wiki page captures the the readiness of WTP projects to move from PDE to CBI builds. <br />
<br />
'''Instructions: ''' Find your project in the table below and mark each task and overall readiness with either a "checkmark" or "cross". The Comment column is meant to capture differences, or overall comments in each projects analysis of build artifacts. <br />
<br />
The Build comparison should be done using same day builds (I used 5/8 builds) [https://bugs.eclipse.org/bugs/show_bug.cgi?id=420889 This bug is driving this task]<br />
<br />
Smoketests should be done on a recent build (like 5/8) - [https://hudson.eclipse.org/webtools/job/cbi-build/ builds are located here] - I used the repository<br />
<br />
Your vote in the below table will not trigger any immediate action. The information collected will be used for further discussions and plans on using the CBI output in the Luna aggregation builds.<br />
<br />
[[Image:Checkmark.gif]] = I feel comfortable moving to CBI for Luna release<br />
[[Image:Fail.gif]] = I don't feel comfortable moving to CBI yet - more work to be done<br />
[[Image:Questionmark.gif]]= Readiness status pending<br />
<br />
{| cellpadding="5" border="3"<br />
|-<br />
! Project Lead <br />
! Build Comparison<br />
! CBI Build Smoketest <br />
! Overall Readiness <br />
! Comments<br />
|-<br />
! colspan="5" | ''Common Tools''<br />
|-<br />
| Carl Anderson <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
|-<br />
! colspan="5" | ''Dali''<br />
|-<br />
| Neil Hauge <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
|<br />
|-<br />
! colspan="5" | ''EJB Tools''<br />
|-<br />
| Kaloyan Raev <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br><br />
|-<br />
! colspan="5" | ''Java EE Tools''<br />
|-<br />
| Chuck Bridgham <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| Other than changes in size because of jar signing... The one major difference in CBI is the generation of xxx.userdoc.feature.source jar's - these are a waste - and should be removed (bug 434890), but doesn't prevent moving forward.<br />
|-<br />
! colspan="5" | ''JavaScript Development Tools''<br />
|-<br />
| Christopher Jaun <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
|-<br />
! colspan="5" | ''JavaServer Faces''<br />
|-<br />
| Raghunathan Srinivasan <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| Source features (''org.eclipse.jsf.feature.source'', ''org.eclipse.jst.jsf.apache.trinidad.tagsupport.feature.source'', ''org.eclipse.jst.webpageeditor.feature.source'') contain '''build.properties''' in CBI, where they did not in legacy build.<br />
Extra plug-in in CBI: ''org.eclipse.jst.jsf.doc.user.source''.<br />
<br />
These should be investigated, but are not reason to prevent moving to CBI.<br />
|-<br />
! colspan="5" | ''Release Engineering''<br />
|-<br />
| Carl Anderson <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
|-<br />
! colspan="5" | ''Server Tools''<br />
|-<br />
| Elson Yuen <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]]<br />
| [[Image:Questionmark.gif]] <br />
| JUnit not running yet.<br />
|-<br />
! colspan="5" | ''Source Editing''<br />
|-<br />
| Nick Sandonato <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| [[Image:Checkmark.gif]] <br />
| Extra plugins in CBI build (Bug 435092):<br />
org.eclipse.jst.jsp.ui.infopop.source,<br />
org.eclipse.wst.dtd.ui.infopop.source,<br />
org.eclipse.wst.dtdeditor.doc.user.source,<br />
org.eclipse.wst.html.ui.infopop.source,<br />
org.eclipse.wst.sse.doc.user.source,<br />
org.eclipse.wst.sse.ui.infopop.source,<br />
org.eclipse.wst.standard.schemas.source,<br />
org.eclipse.wst.xml.ui.infopop.source<br />
|-<br />
! colspan="5" | ''Web Services Tools''<br />
|-<br />
| Keith Chong <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| [[Image:Questionmark.gif]] <br />
| <br />
<br />
'''Web Services and WSDL''' ( [[Image:Questionmark.gif]] , [[Image:Questionmark.gif]] , [[Image:Questionmark.gif]] )<br />
<br />
Build comparison - TBD<br />
<br />
Failing test: org.eclipse.wst.validation.test<br />
<br />
Failing test: org.eclipse.wst.wsi.tests.internal.BasicProfileAnalyzerTest.testReportWriterIsClosedAfterReportIsFinished<br />
<br />
<br />
'''JAX-WS sub-component''' ( [[Image:Checkmark.gif]] , [[Image:Checkmark.gif]] , [[Image:Checkmark.gif]] )<br />
<br />
Extra feature included in CBI build:<br />
<br />
org.eclipse.jst.ws.jaxws_userdoc.feature.source<br />
<br />
Other source features in CBI build contain an additional file: build.properties<br />
org.eclipse.jst.ws.cxf.feature.source<br />
org.eclipse.jst.ws.jaxws.dom.feature.source<br />
org.eclipse.jst.ws.jaxws.feature.source<br />
<br />
Differences in jars files sizes between PDE and CBI because of jar signing.<br />
<br />
One failing test:<br />
org.eclipse.jst.ws.jaxws.dom.runtime.tests.annotations.AnnotationFactoryTest.testRemoveAnnotationsIMethod <br />
<br />
Same NPE error reported in that test also thrown in these two:<br />
org.eclipse.wst.server.ui.tests.dialog.DialogsTestCase.testDeleteServerDialog<br />
org.eclipse.wst.common.snippets.tests.providers.TextProviderTests.testTextSnippetCreation<br />
<br />
|}<br />
<br />
[[Category:Eclipse_Web_Tools_Platform_Project|Eclipse_Web_Tools_Platform_Project]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP_2014-05-01&diff=361721WTP 2014-05-012014-05-01T14:01:17Z<p>Thanh.ha.eclipse.org: /* Other business - Long term tracking items */</p>
<hr />
<div>== WTP Development Status Meeting ==<br />
<br />
<br />
<small>Remember, any committer can add an agenda item. Typically, short announcements or news items go in the "Announcements" section at the beginning. Longer items or issues requiring discussion should go in the "Other business" section at end.</small><br />
<br />
=== Announcements And Special Reports ===<br />
<br />
=== WTP Calendar ===<br />
<br />
(Weekly Google Calendar)<br />
<br />
<googlecalendar width="640" height="500" title="WTP Calendar">23u09qluqisen61r5r585ke1uc@group.calendar.google.com</googlecalendar><br />
<br />
<br><br />
<br />
For Luna overall dates, see the [http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York Simultaneous Release Calendar]<br />
<br />
<br><br />
<br />
== Release / Build status ==<br />
<br />
=== WTP 3.6: Luna ===<br />
<br />
* [[WTP_Smoke_Test_Results| Smoke Test Results]]<br />
* [https://projects.eclipse.org/projects/webtools/releases/3.6.0 Luna Release record]<br />
* [http://www.eclipse.org/projects/project-plan.php?planurl=/webtools/standard-project-plans/luna/wtp-plan.xml WTP Luna Project Plan]<br />
* [http://projects.eclipse.org/projects/webtools Webtools project site]<br />
* [https://wiki.eclipse.org/WTP_3.6_Ramp_down_Plan_for_Luna Luna Ramp down Plan]<br />
* We must fix [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433700 bug 433700] and all of the license update bugs that block it for RC1<br />
<br />
<br />
==== 3.6.0 Schedule ====<br />
<br />
:M7 05/02 (for delivery to Luna+2 on 05/06)(after this build, begin PMC +1)<br />
:RC1 05/16 (for delivery to Luna+2 on 05/20)(after this build, still PMC +1)<br />
:RC2 05/23 (for delivery to Luna+2 on 05/27)(after this build, begin PMC +2)<br />
:RC3 05/30 (for delivery to Luna+2 on 06/03)(after this build, begin PMC +3)<br />
:RC4 06/06 (for delivery to Luna+2 on 06/10) [Final build]<br />
:Luna GA 06/26<br />
<br />
==== Luna Schedule(From Eclipse Luna Simultaneous_Release_Plan) ====<br />
<br />
Elapsed Weeks <br />
End Date Span from +0 for RC0 for EPP avail<br />
M1 Friday, August 23, 2013 08/09 to 08/23 6 8 (from previous release GA)<br />
M2 Friday, October 04 09/20 to 10/04 6 6 (from M1)<br />
M3 Friday, November 15 11/01 to 11/15 6 6 (from M2)<br />
M4 Friday, December 20 12/13 to 12/20 6 5 (from M3) (shift from 2 week window to 1 week window)<br />
M5 Friday, January 31, 2014 01/24 to 01/31 6 6 (from M4) (plan to "lose" a week for end-of-year holidays)<br />
M6 Friday, March 14 03/07 to 03/14 6 6 (from M5) <br />
<br />
EclipseCon! (03/17 to 03/20) <br />
<br />
M7 Friday, May 09 05/02 to 05/09 8 8 (from M6) (extra week(s) for EclipseCon)<br />
RC1 Friday, May 23 05/16 to 05/23 2 2 (from M7)<br />
RC2 Friday, May 30 05/23 to 05/30 1 1 (from RC1)<br />
RC3 Friday, June 06 05/30 to 06/06 1 1 (from RC2)<br />
RC4 Friday, June 13 06/06 to 06/13 1 1 (from RC3)<br />
<br />
Quiet week, June 16 to June 20<br />
(no builds during "quiet week", assumed all code is done by end of RC4 <br />
<br />
Release Wednesday, June 25, 2014<br />
<br />
<br />
See "references" <ref>Our plan dates are on 'Friday' of the week. But, we produce and test the build on Thursday of the week, and ideally declare on Thursday. The dates in the Google Web Tools group calendar are for 'Thursdays' since that's a calendar for committers. We give ourselves the buffer to Friday, as our "public" date, that others can pick up our build, just in case a regression is found on Thursday and we have to respin and retest. [Technically, some might say, we still have till the following Tuesday or Wednesday for some "Simultaneous Release" due dates ... but it's hard to do much in that window, without disrupting everyone ... so we'll not use that buffer, except for the worst emergencies.]</ref> for detailed explanation of what these dates mean. See also the [http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Schedule Overall Luna Schedule].<br />
<br />
== Bug and Feature Highlights ==<br />
<br />
=== Focus on Quality ===<br />
<br />
*Improve:<br />
:*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+EE+Config&product=Java+Server+Faces&product=JSDT&product=Libra&product=Pave&product=Web+Tools&product=WTP+Common+Tools&product=WTP+Datatools&product=WTP+EJB+Tools&product=WTP+Java+EE+Tools&product=WTP+Releng&product=WTP+ServerTools&product=WTP+Source+Editing&product=WTP+Webservices&product=WTP+Website&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Major or higher severity bugs by project] (This week - 130, last week - 129)<br />
::*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+EE+Config&product=Java+Server+Faces&product=JSDT&product=Libra&product=Pave&product=Web+Tools&product=WTP+Common+Tools&product=WTP+Datatools&product=WTP+EJB+Tools&product=WTP+Java+EE+Tools&product=WTP+Releng&product=WTP+ServerTools&product=WTP+Source+Editing&product=WTP+Webservices&product=WTP+Website&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&target_milestone=future&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap Targeted to Future (candidates for severity downgrade?)] (Total - 68, last week - 68)<br />
<br />
*Triage:<br />
:*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+Server+Faces&product=JSDT&product=Libra&product=Pave&product=Web+Tools&product=WTP+Common+Tools&product=WTP+Datatools&product=WTP+EJB+Tools&product=WTP+Incubator&product=WTP+Java+EE+Tools&product=WTP+Releng&product=WTP+ServerTools&product=WTP+Source+Editing&product=WTP+Webservices&product=WTP+Website&target_milestone=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_severity=enhancement&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=2000-01-01&chfieldto=-7d&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=attachments.ispatch&type0-0-0=equals&value0-0-0=1&field0-1-0=attachments.isobsolete&type0-1-0=equals&value0-1-0=0 Untargeted bugs and enhancements with patches attached over 7 days old] (This week - 58, Last week - 53)<br />
:*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&target_milestone=---&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=nowords&keywords=helpwanted&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailtype1=regexp&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2000-01-01&chfieldto=-7d&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=attachments.ispatch&type0-0-0=noop&value0-0-0=%7C%2C Untargeted severity "Major" and higher bugs opened over 7 days ago] (This week - 61, Last week - 61) <br />
:*Options:<br />
::*Target to a specific release or "future" if planning to fix but not in the next release<br />
::*Adjust severity as appropriate<br />
<br />
=== Release Bug Review ===<br />
<br />
:[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=target_milestone&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&target_milestone=0.4&target_milestone=3.6&target_milestone=3.6+M1&target_milestone=3.6+M2&target_milestone=3.6+M3&target_milestone=3.6+M4&target_milestone=3.6+M5&target_milestone=3.6+M6&target_milestone=3.6+M7&target_milestone=3.4&target_milestone=3.4+M1&target_milestone=3.4+M2&target_milestone=3.4+M3&target_milestone=3.4+M4&target_milestone=3.4+M5&target_milestone=3.4+M6&target_milestone=3.4+M7&format=table&action=wrap Bugs targeted to WTP Luna]<br />
<br />
=== Blockers, Hot-Bugs, Hot-Features ===<br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_severity=blocker;bug_severity=critical;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;classification=WebTools Blocker and Critical]<br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=WebTools&email1=&email2=&emailtype1=substring&emailtype2=substring&field0-0-0=noop&keywords=&keywords_type=allwords&longdesc=&longdesc_type=allwordssubstr&query_format=advanced&short_desc=hotbug%20hotbug_request&short_desc_type=anywordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type0-0-0=noop&value0-0-0=&votes=&order=product%2Cchangeddate%20DESC%2Ctarget_milestone%2Cbug_severity%2Cpriority%2Cpriority%2Cbug_severity%2Cbug_severity%2Cassigned_to%2Cstatus_whiteboard%2Ctarget_milestone%2Ctarget_milestone%2Ccomponent%2Cvotes%20DESC%2Cbug_id Hotbugs] <ref>[[WTP/Hotbug_Policy| Hotbug Policy]]</ref><br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=WebTools&f1=keywords&list_id=8318772&o1=notsubstring&query_format=advanced&short_desc=hotfeature%20hotfeature_request&short_desc_type=anywordssubstr&v1=helpwanted Hotfeatures] <ref>[[WTP/Hotfeature_Policy| Hotfeature Policy]]</ref><br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=WebTools&keywords=helpwanted%2C%20&keywords_type=anywords&list_id=8318787&query_format=advanced&short_desc=hotfeature%20hotfeature_request&short_desc_type=anywordssubstr Hotfeatures - triaged with helpwanted]<br />
<br />
== Project scrum section ==<br />
<br />
*Each project answers<br />
** What are you working on? <br />
** What are you planning for next week?<br />
<br />
==== WTP Common Tools ====<br />
*This week: Fixed [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433907 Common license update bug]<br />
*Next week: TBD<br />
<br />
==== Dali Java Persistence Tools ====<br />
<br />
==== WTP EJB & Java EE Tools ====<br />
*This week: not much<br />
*Next week: Fix [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433922 License update bug]<br />
<br />
==== JavaScript Development Tools ====<br />
<br />
==== JavaServer Faces ====<br />
<br />
==== Server Tools ====<br />
<br />
==== WTP Source Editing ====<br />
<br />
==== Web Services Tools ====<br />
<br />
==== Releng ====<br />
*This week: Opened [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433700 bug 433700] to address the Eclipse license update issue, updated build prereqs<br />
*Next week: Declare M7<br />
*Found workarounds for some build issues by setting "org.eclipse.sdk.ide" or "org.eclipse.jst.enterprise_sdk.feature" as dependencies. Not ideal but gets us moving forward if there is no time to investigate more specific dependencies.<br />
<br />
==== VJET ====<br />
<br />
<br />
==== Any others? ====<br />
<br />
<br />
== Other business - Long term tracking items ==<br />
<br />
* Historically - WTP hasn't published an endgame "plan" - but this [http://www.eclipse.org/eclipse/development/plans/freeze_plan_4_4.php Endgame plan from the platform] is a good reminder of testing/planning activities that is appropriate for your projects.<br />
<br />
* Time to review [http://help.eclipse.org/kepler/index.jsp Help documentation] - We were late publishing last year, with almost no updates. - We will publish on time this year, and should update stale, outdated content. - Please review.<br />
<br />
*[http://wiki.eclipse.org/WTP/Build/CBI_Build CBI] -<br />
** [https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=target_milestone&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=blocked&o1=equals&v1=412211&f2=noop&o2=noop&v2=&format=table&action=wrap All open CBI bugs]<br />
** WTP HIPP Instance (https://hudson.eclipse.org/webtools/)<br />
** Please continue to react to CBI defects asap to continue momentum<br />
** Goal for M7 - continuous builds happening, progress towards build replacement<br />
** Goal for 3.6 final - replace the CruiseControl build with the CBI build for declares<br />
** [[CBI| Eclipse Common Build Infrastructure home]]<br />
<br />
== References ==<br />
<br />
<references/><br />
<br />
Also, see <br />
<br />
* [http://wiki.eclipse.org/WTP_Git_Workflows WTP Git Usage/Discussion page]<br />
<br />
* [http://wiki.eclipse.org/New_Help_for_Old_Friends_IX New Help for Old Friends]<br />
<br />
* [[WTP_Provisional_API_Reduction| Provisional API]]<br />
<br />
: [http://wiki.eclipse.org/Team_thoughts_on_continuous_improvement_35 Kepler release retrospective]<br />
<br />
: [http://www.eclipse.org/projects/project-plan.php?projectid=webtools Standard Format Plans]<br />
<br />
: [[WTP_3.5.x_Maintenance| WTP 3.5.x maintenance release plan]]<br />
<br />
: [[WTP_How_to:_Branching_Policy_and_Practices| how/when to branch code?]] <br />
<br />
: [http://www.eclipse.org/projects/ip_log_selector.php IP Logs selector]<br />
<br />
: See also the [[WTP Meeting Archive-Reference Page]].</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP_2014-05-01&diff=361720WTP 2014-05-012014-05-01T14:00:00Z<p>Thanh.ha.eclipse.org: /* Releng */</p>
<hr />
<div>== WTP Development Status Meeting ==<br />
<br />
<br />
<small>Remember, any committer can add an agenda item. Typically, short announcements or news items go in the "Announcements" section at the beginning. Longer items or issues requiring discussion should go in the "Other business" section at end.</small><br />
<br />
=== Announcements And Special Reports ===<br />
<br />
=== WTP Calendar ===<br />
<br />
(Weekly Google Calendar)<br />
<br />
<googlecalendar width="640" height="500" title="WTP Calendar">23u09qluqisen61r5r585ke1uc@group.calendar.google.com</googlecalendar><br />
<br />
<br><br />
<br />
For Luna overall dates, see the [http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York Simultaneous Release Calendar]<br />
<br />
<br><br />
<br />
== Release / Build status ==<br />
<br />
=== WTP 3.6: Luna ===<br />
<br />
* [[WTP_Smoke_Test_Results| Smoke Test Results]]<br />
* [https://projects.eclipse.org/projects/webtools/releases/3.6.0 Luna Release record]<br />
* [http://www.eclipse.org/projects/project-plan.php?planurl=/webtools/standard-project-plans/luna/wtp-plan.xml WTP Luna Project Plan]<br />
* [http://projects.eclipse.org/projects/webtools Webtools project site]<br />
* [https://wiki.eclipse.org/WTP_3.6_Ramp_down_Plan_for_Luna Luna Ramp down Plan]<br />
* We must fix [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433700 bug 433700] and all of the license update bugs that block it for RC1<br />
<br />
<br />
==== 3.6.0 Schedule ====<br />
<br />
:M7 05/02 (for delivery to Luna+2 on 05/06)(after this build, begin PMC +1)<br />
:RC1 05/16 (for delivery to Luna+2 on 05/20)(after this build, still PMC +1)<br />
:RC2 05/23 (for delivery to Luna+2 on 05/27)(after this build, begin PMC +2)<br />
:RC3 05/30 (for delivery to Luna+2 on 06/03)(after this build, begin PMC +3)<br />
:RC4 06/06 (for delivery to Luna+2 on 06/10) [Final build]<br />
:Luna GA 06/26<br />
<br />
==== Luna Schedule(From Eclipse Luna Simultaneous_Release_Plan) ====<br />
<br />
Elapsed Weeks <br />
End Date Span from +0 for RC0 for EPP avail<br />
M1 Friday, August 23, 2013 08/09 to 08/23 6 8 (from previous release GA)<br />
M2 Friday, October 04 09/20 to 10/04 6 6 (from M1)<br />
M3 Friday, November 15 11/01 to 11/15 6 6 (from M2)<br />
M4 Friday, December 20 12/13 to 12/20 6 5 (from M3) (shift from 2 week window to 1 week window)<br />
M5 Friday, January 31, 2014 01/24 to 01/31 6 6 (from M4) (plan to "lose" a week for end-of-year holidays)<br />
M6 Friday, March 14 03/07 to 03/14 6 6 (from M5) <br />
<br />
EclipseCon! (03/17 to 03/20) <br />
<br />
M7 Friday, May 09 05/02 to 05/09 8 8 (from M6) (extra week(s) for EclipseCon)<br />
RC1 Friday, May 23 05/16 to 05/23 2 2 (from M7)<br />
RC2 Friday, May 30 05/23 to 05/30 1 1 (from RC1)<br />
RC3 Friday, June 06 05/30 to 06/06 1 1 (from RC2)<br />
RC4 Friday, June 13 06/06 to 06/13 1 1 (from RC3)<br />
<br />
Quiet week, June 16 to June 20<br />
(no builds during "quiet week", assumed all code is done by end of RC4 <br />
<br />
Release Wednesday, June 25, 2014<br />
<br />
<br />
See "references" <ref>Our plan dates are on 'Friday' of the week. But, we produce and test the build on Thursday of the week, and ideally declare on Thursday. The dates in the Google Web Tools group calendar are for 'Thursdays' since that's a calendar for committers. We give ourselves the buffer to Friday, as our "public" date, that others can pick up our build, just in case a regression is found on Thursday and we have to respin and retest. [Technically, some might say, we still have till the following Tuesday or Wednesday for some "Simultaneous Release" due dates ... but it's hard to do much in that window, without disrupting everyone ... so we'll not use that buffer, except for the worst emergencies.]</ref> for detailed explanation of what these dates mean. See also the [http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Schedule Overall Luna Schedule].<br />
<br />
== Bug and Feature Highlights ==<br />
<br />
=== Focus on Quality ===<br />
<br />
*Improve:<br />
:*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+EE+Config&product=Java+Server+Faces&product=JSDT&product=Libra&product=Pave&product=Web+Tools&product=WTP+Common+Tools&product=WTP+Datatools&product=WTP+EJB+Tools&product=WTP+Java+EE+Tools&product=WTP+Releng&product=WTP+ServerTools&product=WTP+Source+Editing&product=WTP+Webservices&product=WTP+Website&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Major or higher severity bugs by project] (This week - 130, last week - 129)<br />
::*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+EE+Config&product=Java+Server+Faces&product=JSDT&product=Libra&product=Pave&product=Web+Tools&product=WTP+Common+Tools&product=WTP+Datatools&product=WTP+EJB+Tools&product=WTP+Java+EE+Tools&product=WTP+Releng&product=WTP+ServerTools&product=WTP+Source+Editing&product=WTP+Webservices&product=WTP+Website&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&target_milestone=future&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap Targeted to Future (candidates for severity downgrade?)] (Total - 68, last week - 68)<br />
<br />
*Triage:<br />
:*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+Server+Faces&product=JSDT&product=Libra&product=Pave&product=Web+Tools&product=WTP+Common+Tools&product=WTP+Datatools&product=WTP+EJB+Tools&product=WTP+Incubator&product=WTP+Java+EE+Tools&product=WTP+Releng&product=WTP+ServerTools&product=WTP+Source+Editing&product=WTP+Webservices&product=WTP+Website&target_milestone=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_severity=enhancement&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=2000-01-01&chfieldto=-7d&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=attachments.ispatch&type0-0-0=equals&value0-0-0=1&field0-1-0=attachments.isobsolete&type0-1-0=equals&value0-1-0=0 Untargeted bugs and enhancements with patches attached over 7 days old] (This week - 58, Last week - 53)<br />
:*[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_severity&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&target_milestone=---&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=nowords&keywords=helpwanted&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailtype1=regexp&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2000-01-01&chfieldto=-7d&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=attachments.ispatch&type0-0-0=noop&value0-0-0=%7C%2C Untargeted severity "Major" and higher bugs opened over 7 days ago] (This week - 61, Last week - 61) <br />
:*Options:<br />
::*Target to a specific release or "future" if planning to fix but not in the next release<br />
::*Adjust severity as appropriate<br />
<br />
=== Release Bug Review ===<br />
<br />
:[https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=target_milestone&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&target_milestone=0.4&target_milestone=3.6&target_milestone=3.6+M1&target_milestone=3.6+M2&target_milestone=3.6+M3&target_milestone=3.6+M4&target_milestone=3.6+M5&target_milestone=3.6+M6&target_milestone=3.6+M7&target_milestone=3.4&target_milestone=3.4+M1&target_milestone=3.4+M2&target_milestone=3.4+M3&target_milestone=3.4+M4&target_milestone=3.4+M5&target_milestone=3.4+M6&target_milestone=3.4+M7&format=table&action=wrap Bugs targeted to WTP Luna]<br />
<br />
=== Blockers, Hot-Bugs, Hot-Features ===<br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_severity=blocker;bug_severity=critical;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;classification=WebTools Blocker and Critical]<br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=WebTools&email1=&email2=&emailtype1=substring&emailtype2=substring&field0-0-0=noop&keywords=&keywords_type=allwords&longdesc=&longdesc_type=allwordssubstr&query_format=advanced&short_desc=hotbug%20hotbug_request&short_desc_type=anywordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type0-0-0=noop&value0-0-0=&votes=&order=product%2Cchangeddate%20DESC%2Ctarget_milestone%2Cbug_severity%2Cpriority%2Cpriority%2Cbug_severity%2Cbug_severity%2Cassigned_to%2Cstatus_whiteboard%2Ctarget_milestone%2Ctarget_milestone%2Ccomponent%2Cvotes%20DESC%2Cbug_id Hotbugs] <ref>[[WTP/Hotbug_Policy| Hotbug Policy]]</ref><br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=WebTools&f1=keywords&list_id=8318772&o1=notsubstring&query_format=advanced&short_desc=hotfeature%20hotfeature_request&short_desc_type=anywordssubstr&v1=helpwanted Hotfeatures] <ref>[[WTP/Hotfeature_Policy| Hotfeature Policy]]</ref><br />
<br />
:[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=WebTools&keywords=helpwanted%2C%20&keywords_type=anywords&list_id=8318787&query_format=advanced&short_desc=hotfeature%20hotfeature_request&short_desc_type=anywordssubstr Hotfeatures - triaged with helpwanted]<br />
<br />
== Project scrum section ==<br />
<br />
*Each project answers<br />
** What are you working on? <br />
** What are you planning for next week?<br />
<br />
==== WTP Common Tools ====<br />
*This week: Fixed [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433907 Common license update bug]<br />
*Next week: TBD<br />
<br />
==== Dali Java Persistence Tools ====<br />
<br />
==== WTP EJB & Java EE Tools ====<br />
*This week: not much<br />
*Next week: Fix [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433922 License update bug]<br />
<br />
==== JavaScript Development Tools ====<br />
<br />
==== JavaServer Faces ====<br />
<br />
==== Server Tools ====<br />
<br />
==== WTP Source Editing ====<br />
<br />
==== Web Services Tools ====<br />
<br />
==== Releng ====<br />
*This week: Opened [https://bugs.eclipse.org/bugs/show_bug.cgi?id=433700 bug 433700] to address the Eclipse license update issue, updated build prereqs<br />
*Next week: Declare M7<br />
*Found workarounds for some build issues by setting "org.eclipse.sdk.ide" or "org.eclipse.jst.enterprise_sdk.feature" as dependencies. Not ideal but gets us moving forward if there is no time to investigate more specific dependencies.<br />
<br />
==== VJET ====<br />
<br />
<br />
==== Any others? ====<br />
<br />
<br />
== Other business - Long term tracking items ==<br />
<br />
* Historically - WTP hasn't published an endgame "plan" - but this [http://www.eclipse.org/eclipse/development/plans/freeze_plan_4_4.php Endgame plan from the platform] is a good reminder of testing/planning activities that is appropriate for your projects.<br />
<br />
* Time to review [http://help.eclipse.org/kepler/index.jsp Help documentation] - We were late publishing last year, with almost no updates. - We will publish on time this year, and should update stale, outdated content. - Please review.<br />
<br />
*[http://wiki.eclipse.org/WTP/Build/CBI_Build CBI] -<br />
** [https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=target_milestone&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=blocked&o1=equals&v1=412211&f2=noop&o2=noop&v2=&format=table&action=wrap All open CBI bugs]<br />
** Created new Hudson instance for WTP<br />
** Please continue to react to CBI defects asap to continue momentum<br />
** Goal for M7 - continuous builds happening, progress towards build replacement<br />
** Goal for 3.6 final - replace the CruiseControl build with the CBI build for declares<br />
** [[CBI| Eclipse Common Build Infrastructure home]]<br />
<br />
== References ==<br />
<br />
<references/><br />
<br />
Also, see <br />
<br />
* [http://wiki.eclipse.org/WTP_Git_Workflows WTP Git Usage/Discussion page]<br />
<br />
* [http://wiki.eclipse.org/New_Help_for_Old_Friends_IX New Help for Old Friends]<br />
<br />
* [[WTP_Provisional_API_Reduction| Provisional API]]<br />
<br />
: [http://wiki.eclipse.org/Team_thoughts_on_continuous_improvement_35 Kepler release retrospective]<br />
<br />
: [http://www.eclipse.org/projects/project-plan.php?projectid=webtools Standard Format Plans]<br />
<br />
: [[WTP_3.5.x_Maintenance| WTP 3.5.x maintenance release plan]]<br />
<br />
: [[WTP_How_to:_Branching_Policy_and_Practices| how/when to branch code?]] <br />
<br />
: [http://www.eclipse.org/projects/ip_log_selector.php IP Logs selector]<br />
<br />
: See also the [[WTP Meeting Archive-Reference Page]].</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP/Build/CBI_Build&diff=361123WTP/Build/CBI Build2014-04-24T16:43:18Z<p>Thanh.ha.eclipse.org: /* Build */</p>
<hr />
<div>= WTP CBI Build =<br />
<br />
== Git clone the repo ==<br />
<br />
The repo for WTP's aggregator can be found here:<br />
<br />
http://git.eclipse.org/c/webtools/webtools.releng.aggregator.git/<br />
<br />
You can git clone the repo by running:<br />
<pre><br />
git clone --recursive git://git.eclipse.org/gitroot/webtools/webtools.releng.aggregator.git<br />
</pre><br />
<br />
== Build WTP with CBI ==<br />
<br />
=== Setup ===<br />
<br />
In order to build WTP you are required to setup BREE libraries. This means configuring a toolchains.xml file in your ~/.m2/toolchains.xml file.<br />
<br />
Specifically for J2SE-1.4 you will require a copy of IBMJava2-142-SR13FP10.<br />
<br />
The one I'm using is as follows:<br />
<br />
<pre><br />
<toolchains><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>J2SE-1.4</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/ibm/IBMJava2-142-SR13FP10/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>J2SE-1.5</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.5.0_22/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>JavaSE-1.6</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.6.0_45/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>JavaSE-1.7</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.7.0_25/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
</toolchains><br />
</pre><br />
<br />
=== Build ===<br />
<br />
To build WTP simply navigate to the directory where you cloned the repo and run:<br />
<br />
<pre><br />
mvn clean verify -Pbree-libs<br />
</pre><br />
<br />
<br />
Note: Due to some current issues with JSF unit tests in WTP build. You need to tell Maven to ignore test failures by passing these parameters: '''-Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true'''</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP/Build/CBI_Build&diff=361122WTP/Build/CBI Build2014-04-24T16:43:02Z<p>Thanh.ha.eclipse.org: /* Build */</p>
<hr />
<div>= WTP CBI Build =<br />
<br />
== Git clone the repo ==<br />
<br />
The repo for WTP's aggregator can be found here:<br />
<br />
http://git.eclipse.org/c/webtools/webtools.releng.aggregator.git/<br />
<br />
You can git clone the repo by running:<br />
<pre><br />
git clone --recursive git://git.eclipse.org/gitroot/webtools/webtools.releng.aggregator.git<br />
</pre><br />
<br />
== Build WTP with CBI ==<br />
<br />
=== Setup ===<br />
<br />
In order to build WTP you are required to setup BREE libraries. This means configuring a toolchains.xml file in your ~/.m2/toolchains.xml file.<br />
<br />
Specifically for J2SE-1.4 you will require a copy of IBMJava2-142-SR13FP10.<br />
<br />
The one I'm using is as follows:<br />
<br />
<pre><br />
<toolchains><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>J2SE-1.4</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/ibm/IBMJava2-142-SR13FP10/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>J2SE-1.5</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.5.0_22/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>JavaSE-1.6</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.6.0_45/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>JavaSE-1.7</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.7.0_25/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
</toolchains><br />
</pre><br />
<br />
=== Build ===<br />
<br />
To build WTP simply navigate to the directory where you cloned the repo and run:<br />
<br />
<pre><br />
mvn clean verify -Pbree-libs<br />
</pre><br />
<br />
<br />
Note: Due to some current issues with JSF unit tests in WTP build. You need to tell Maven to ignore test failures by passing these parameters: -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=Gerrit&diff=360881Gerrit2014-04-21T17:35:17Z<p>Thanh.ha.eclipse.org: /* IP Review */</p>
<hr />
<div>This wiki page desribes how to contribute to the Eclipse project via Gerrit hosted at https://git.eclipse.org/r<br />
<br />
Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. For more information about Gerrit, please see http://code.google.com/p/gerrit/.<br />
<br />
<br />
== Enabling Gerrit for your Eclipse.org Project ==<br />
<br />
* File [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Git&short_desc=Enable%20Gerrit%20for%20%3Cmy%20project%3E a bug] and specify for which project you'd like to enable Gerrit<br />
* Ask your Project Lead to +1 the request<br />
* Select a date for project committers to update their repo URLs<br />
* Choose one of the two options:<br />
** I want project committers use Gerrit code review exclusively for my project. Everything must be reviewed -- no direct access to the main repo should be available.<br />
** I want project committers to be able to bypass the Gerrit code review system and push changes directly to the git repo. '''Please note that this will have to be done via the 'new' Gerrit URLs(SSH and HTTPS). The original dev.eclipse.org SSH URLs will become inactive once Gerrit is enabled.'''<br />
<br />
:<font size="-1">(see {{bug|413753}} for a third option -- Eclipse Platform projects keep direct access to the Git repo)</font><br />
<br />
*'''Note''': If you're adding all of your code repos to Gerrit, you will lose control of the 'container' for your project(/gitroot/projectname), as Webmaster will give the container to the Gerrit user. This means that you will not be able to create new repos via the initrepo command, instead you will have to contact Webmaster(via a bug).<br />
<br />
== User Account ==<br />
* In order to contribute you need an [https://dev.eclipse.org/site_login/createaccount.php Eclipse user account] and agree to the Contributor License Agreement (CLA). If you are an Eclipse committer you already have one.<br />
<br />
To sign the CLA Log into the Eclipse projects [[Forges|forge]] (you will need to create an account with the Eclipse Foundation if you have not already done so); click on "Contributor License Agreement"; and Complete the form. Be sure to use the same email address when you register for the account that you intend to use on Git commit records.<br />
<br />
== Gerrit setup ==<br />
<br />
===Gerrit Web UI=== <br />
Logon to the Gerrit Web UI at <code>https://git.eclipse.org/r/</code> using the email address you registered with your Eclipse (and Bugzilla) account and your Eclipse password.<br />
<br />
===Git over SSH=== <br />
When accessing Gerrit over SSH from git or EGit use the username displayed [https://git.eclipse.org/r/#/settings/ here] and upload your public SSH key to Gerrit [https://git.eclipse.org/r/#/settings/ssh-keys here]. <br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* If you are '''absolutely certain''' you do not have keys already, you must create a public and private pair of SSH keys. It is strongly recommended that you [http://help.github.com/working-with-key-passphrases use a passphrase.]<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [http://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
===Gerrit push URL === <br />
<br />
Gerrit SSH URl: <pre style="width: 60em;">ssh://username@git.eclipse.org:29418/repository.git</pre><br />
<br />
{{Note|Gerrit SSH service versus SSH shell access| Gerrit's SSH service listens on port 29418 and isn't linked to the public keys on git.eclipse.org used for SSH shell access on port 22}}<br />
<br />
===Git over HTTPS=== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <pre style="width: 60em;">https://git.eclipse.org/r/p/repository.git</pre><br />
<br />
=== Be notified of upcoming changes ===<br />
<br />
Enabling Gerrit notifications is as important as enabling Bugzilla's ones when you are contributor on a project. Here is the place where you can subscribe to Gerrit notifications: https://git.eclipse.org/r/#/settings/projects<br />
<br />
== Doing Code Reviews with Gerrit ==<br />
<br />
After someone pushed a change you can start reviewing the changes.<br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in.<br />
*[https://git.eclipse.org/r/#/settings/projects Register to watch projects] if you want to be notified by email on new or updated changes pushed for review.<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs.<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*The [http://wiki.eclipse.org/EGit/User_Guide#EGit_Tutorial_.28EclipseCon_Europe_Nov_2011.29 EGit tutorial] walks you through the basic steps of working with Gerrit and EGit.<br />
* [http://www.vogella.com/articles/Gerrit/article.html Gerrit tutorial] by Lars Vogel<br />
<br />
=== Using Gerrit with the git command line ===<br />
*Upload your patch from Git to the target project, where <i>(project)</i> is the project specifier as per the Gerrit Web UI and may include a prefix, eg <i>cdt/org.eclipse.cdt.git</i>: <br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/(project).git HEAD:refs/for/master<br />
</pre><br />
For example:<br />
<pre style="width: 60em;">git push ssh://moberhuber@git.eclipse.org:29418/cdt/org.eclipse.cdt.git HEAD:refs/for/master<br />
</pre> <br />
<br />
==== Adding a dedicated remote ====<br />
<br />
Since git can have multiple remotes, you can define one to be used to refer to Gerrit to save typing. Inside a previously checked-out repository you can run: <br />
<pre>cd path/to/project<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/(project).git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit ===<br />
Eclipse will look for your private key in the SSH2 Home location specified in the General&gt;Network Connections&gt;SSH2 Preference Page. If your <code>id_rsa</code> private key makes use of the AES-128-CBC algorithm (view the file as text to confirm), Eclipse will need at least <code>com.jcraft.jsch 0.1.44</code> to make use of it.<br />
* [[EGit/User_Guide#Cloning_Remote_Repositories | Clone the repository]]<br />
* Afterwards open the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote "origin" in the Git Repositories view to [http://wiki.eclipse.org/EGit/User_Guide#Gerrit_Configuration configure pushing to the code review queue].<br />
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** Changes committed to your local clone can now be pushed to Gerrit using the ''review'' Remote. You will be prompted for your private key's passphrase if Eclipse is looking for it in the right place.<br />
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
<br />
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing<br />
<br />
=== Using the Mylyn Gerrit Connector ===<br />
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.<br />
<br />
It contains several useful features:<br />
* Cloning from Gerrit and automatic configuration<br />
** The wizards "Import Projects from Git" and "Clone Git Repository" will offer the possibility to browse the list of repositories on Gerrit servers and to clone selected repositories. After cloning the Gerrit configuration will be done automatically.<br />
* Importing Gerrit changes as Mylyn tasks<br />
* Fetching patch sets directly from the task editor<br />
* Reviewing changes in the task editor<br />
* Submitting changes from the task editor<br />
<br />
=== Bypassing code review ===<br />
In some cases it may be desirable to bypass code review. Your Gerrit-enabled project must be configured to allow bypassing code review. Please ask Webmaster if you are not sure.<br />
<br />
Please see [http://eclipsewebmaster.blogspot.ca/2013/11/using-gerrit-code-review-without-code.html Denis' blog post] outlining how to bypass code review.<br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre><br />
This will ask for a password. It is the password that you have to generate in the ''SSH Keys'' section of settings in your Gerrit account.<br />
<br />
You can alternatively [https://git.eclipse.org/r/tools/hooks/commit-msg download the file] or use curl to install it via https: <br />
<pre style="width: 60em;"><br />
# if you are behind a proxy you may need<br />
export https_proxy=https://<proxy-host>[:<proxy-port>]<br />
curl https://git.eclipse.org/r/tools/hooks/commit-msg > .git/hooks/commit-msg<br />
</pre> <br />
<br />
The [http://gerrit.googlecode.com/svn/documentation/2.1.2/cmd-hook-commit-msg.html hook] helps append a Change-Id to your commit message.<br />
<br />
EGit can also [[EGit/User_Guide#Committing_Changes | generate the Change-Id]] and can also be configured to [[EGit/User_Guide#Gerrit_Configuration | automatically include it]].<br />
<br />
== To create a new change ==<br />
<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/repository.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/repository.git HEAD:refs/for/master<br />
</pre> <br />
This works because Gerrit links the new commit to the prior change based upon the Change-Id footer in the commit message. (This is automatically generated by the commit-msg hook you installed above.) If you refuse to use the commit-msg hook, or don't have a Change-Id footer, you should read the Gerrit documentation on [https://git.eclipse.org/r/Documentation/user-changeid.html change-id lines] and [https://git.eclipse.org/r/Documentation/user-upload.html#push_replace replacing changes].<br />
<br />
'''Note:''' To be picked up by Gerrit, a Change-Id line must be in the bottom portion (last paragraph) of a commit message, and may be mixed together with the Signed-off-by, Acked-by, or other such footers. So if your Change-Id line is ignored it's probably not in the last paragraph :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
If you've got a large changeset, and you want to be able to do diffs between them via (command line) git instead of browsing on the web, then you can fetch the individual changes and then perform a diff. For example, [http://git.eclipse.org/r/2 http://git.eclipse.org/r/2] shows the 'download' section for each patchset. In this case, it looks like: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
Performing a <code>git pull</code> will both get the bits and merge them into your tree, which won't do what you want for comparison. So, in order to get the bits (but not merge), you need to do a <code>git fetch</code> instead. Let's say we want to diff the last two patches against each other rather than reviewing the entire patchset again: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
Git fetched data will stay around in your repository, but will be 'orphaned' if no references point to it. To clean up, you can run <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
Once you've pushed your commit to Gerrit for review, you can go to the web page (https://git.eclipse.org/r/) and see your changes. By clicking on the review, there's an option to add a reviewer by e-mail address; they'll then be sent a message indicating that they'd like your review on the item.<br />
<br />
== Code Review ==<br />
<br />
The code review category indicates your opinion on the quality of the code, and how well it fits within the purpose of the existing surrounding code. A +2 vote from any committer is required before submission can occur. A -2 vote from any committer will block submission. <br />
<br />
== IP Review ==<br />
<br />
Follow the rules given in [[Development_Resources/Handling_Git_Contributions#Gerrit|Handling Git Contributions received via Gerrit]].<br />
<br />
== Verifying Changes on Hudson using Gerrit Trigger Plugin ==<br />
<br />
You may use the [https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger Jenkins Gerrit Trigger Plugin] installed on [https://hudson.eclipse.org/sandbox/ sandbox Hudson] in order to run a Hudson job to verify each new patchset uploaded to Gerrit for code review. Hudson will then also vote on these changes using the "Verify" voting category.<br />
<br />
[[Image:Jgit.gerrit-reviewer.png]]<br />
<br />
[[Image:Jgit.gerrit-vote.png]]<br />
<br />
In order to setup a verification build job [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community file a bug in Bugzilla] on "Eclipse Foundation > Community" using component "Hudson sandbox" and ask the webmaster to create a new build job on sandbox Hudson. Then<br />
configure the new job following the description given on the [https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger plugin's home page].<br />
<br />
The configuration sections for the Git plugin and the Gerrit trigger plugin of the verification job used by the JGit project may serve as an example.<br />
<br />
====Configuration of Git plugin:====<br />
<br />
# Under Source Code Management select Git. Click on Advanced and change the '''Choosing Strategy''' to '''Gerrit Trigger'''.<br />
# Follow the settings depicted below:<br />
<br />
[[Image:Jgit.gerrit-git-config.png]]<br />
<br />
====Configuration of Gerrit trigger plugin:====<br />
<br />
[[Image:Jgit.gerrit-gerrit-config.png]]<br />
<br />
[[Category:Gerrit]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=Maven/Parent_POM&diff=357238Maven/Parent POM2014-03-04T14:27:31Z<p>Thanh.ha.eclipse.org: Replaced content with "The original content on this page is out of date. maven.eclipse.org was decommissioned per [http://bugs.eclipse.org/405750 Bug 405750]. repo.eclipse.org replaced maven.ecl..."</p>
<hr />
<div>The original content on this page is out of date. maven.eclipse.org was decommissioned per [http://bugs.eclipse.org/405750 Bug 405750]. repo.eclipse.org replaced maven.eclipse.org and details on the new service can be found at [[Services/Nexus]].</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=Maven&diff=357237Maven2014-03-04T14:26:57Z<p>Thanh.ha.eclipse.org: Replaced content with "The original content on this page is out of date. maven.eclipse.org was decommissioned per [http://bugs.eclipse.org/405750 Bug 405750]. repo.eclipse.org replaced maven.ecl..."</p>
<hr />
<div>The original content on this page is out of date. maven.eclipse.org was decommissioned per [http://bugs.eclipse.org/405750 Bug 405750]. repo.eclipse.org replaced maven.eclipse.org and details on the new service can be found at [[Services/Nexus]].</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=CBI/Projects&diff=354757CBI/Projects2014-01-16T14:56:15Z<p>Thanh.ha.eclipse.org: /* Projects that are using CBI today */</p>
<hr />
<div>==Projects that are using CBI today==<br />
<br />
===Eclipse (platform)===<br />
<br />
These are the repositories included:<br />
* eclipse.platform.runtime<br />
* maven-cbi-plugin<br />
* eclipse.platform<br />
* eclipse.platform.team<br />
* eclipse.jdt.core<br />
* eclipse.platform.ui<br />
* eclipse.platform.ua<br />
* eclipse.platform.releng.tychoeclipsebuilder<br />
* eclipse.platform.common<br />
* rt.equinox.bundles<br />
* eclipse.pde<br />
* rt.equinox.binaries<br />
* eclipse.platform.text<br />
* eclipse.platform.swt<br />
* eclipse-parent<br />
* eclipse.platform.releng<br />
* eclipse.platform.swt.binaries<br />
* eclipse.platform.resources<br />
* scripts<br />
* eclipse.platform.releng.eclipsebuilder<br />
* eclipse.jdt<br />
* rt.equinox.p2<br />
* eclipse.platform.debug<br />
* rt.equinox.framework<br />
* eclipse.pde.build<br />
* eclipse.pde.ui<br />
* eclipse.jdt.debug<br />
* eclipse.jdt.ui<br />
* rt.equinox.incubator<br />
* eclipse.platform.repository<br />
* eclipse.jdt.core.binaries<br />
<br />
===Mylyn===<br />
===CDT===<br />
===[[EGit]]===<br />
<br />
===[[JGit]]===<br />
<br />
=== Gyrex ===<br />
More details can be found at [[Gyrex/Contributor_Guide/Builds]]<br />
<br />
===Hudson===<br />
<br />
===Tycho===<br />
repositories:<br />
* org.eclipse.tycho<br />
* org.eclipse.tycho-demo<br />
* org.eclipse.tycho.extras<br />
<br />
===m2e===<br />
repositories:<br />
<br />
* m2e-core<br />
* org.eclipse.m2e.wtp<br />
<br />
===e4 ===<br />
<br />
org.eclipse.e4.tools<br />
<br />
=== GMF Tooling ===<br />
<br />
===Scout===<br />
repositories:<br />
* org.eclipse.scout-aggregator.git<br />
* org.eclipse.scout.rt.git<br />
* org.eclipse.scout.sdk.git<br />
<br />
=== SWTBot ===<br />
<br />
=== Nebula ===<br />
The Nebula build is using Tycho and Sonar. The build uses a continuous deployment strategy. <br />
<br />
After source code is checked into the Nebula repository, the build is started automatically. The unit tests are executed and the resulting archives are automatically signed. After the signing process, the repository is pushed to the final location on download.eclipse.org where they can be consumed.<br />
<br />
[[Nebula/Builds|Link to the Nebula build page.]]<br />
<br />
=== [[Linux_Tools_Project|Linux Tools]] ===<br />
<br />
=== Jubula ===<br />
git repository: [http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git org.eclipse.jubula.core.git]<br />
<br />
build@hudson.eclipse.org: [https://hudson.eclipse.org/hudson/job/jubula-nightly/ nightly]<br />
<br />
=== Orion ===<br />
<br />
http://www.eclipse.org/orion/<br />
<br />
=== EPP ===<br />
<br />
==Projects that are moving to CBI==<br />
<br />
===[[Stardust]]===<br />
<br />
===WTP===<br />
<br />
==Projects that are not moving to CBI==<br />
<br />
===Virgo===</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP/Build/CBI_Build&diff=350319WTP/Build/CBI Build2013-10-29T15:12:09Z<p>Thanh.ha.eclipse.org: /* Build WTP with CBI */</p>
<hr />
<div>= WTP CBI Build =<br />
<br />
== Git clone the repo ==<br />
<br />
The repo for WTP's aggregator can be found here:<br />
<br />
http://git.eclipse.org/c/webtools/webtools.releng.aggregator.git/<br />
<br />
You can git clone the repo by running:<br />
<pre><br />
git clone --recursive git://git.eclipse.org/gitroot/webtools/webtools.releng.aggregator.git<br />
</pre><br />
<br />
== Build WTP with CBI ==<br />
<br />
=== Setup ===<br />
<br />
In order to build WTP you are required to setup BREE libraries. This means configuring a toolchains.xml file in your ~/.m2/toolchains.xml file.<br />
<br />
Specifically for J2SE-1.4 you will require a copy of IBMJava2-142-SR13FP10.<br />
<br />
The one I'm using is as follows:<br />
<br />
<pre><br />
<toolchains><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>J2SE-1.4</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/ibm/IBMJava2-142-SR13FP10/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>J2SE-1.5</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.5.0_22/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>JavaSE-1.6</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.6.0_45/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
<toolchain><br />
<type>jdk</type><br />
<provides><br />
<id>JavaSE-1.7</id><br />
</provides><br />
<configuration><br />
<jdkHome>/opt/oracle/jdk1.7.0_25/jre</jdkHome><br />
</configuration><br />
</toolchain><br />
</toolchains><br />
</pre><br />
<br />
=== Build ===<br />
<br />
To build WTP simply navigate to the directory where you cloned the repo and run:<br />
<br />
<pre><br />
mvn clean verify -Pbree-libs<br />
</pre></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP/Build/CBI_Build&diff=350318WTP/Build/CBI Build2013-10-29T15:06:47Z<p>Thanh.ha.eclipse.org: /* Build WTP with CBI */</p>
<hr />
<div>= WTP CBI Build =<br />
<br />
== Git clone the repo ==<br />
<br />
The repo for WTP's aggregator can be found here:<br />
<br />
http://git.eclipse.org/c/webtools/webtools.releng.aggregator.git/<br />
<br />
You can git clone the repo by running:<br />
<pre><br />
git clone --recursive git://git.eclipse.org/gitroot/webtools/webtools.releng.aggregator.git<br />
</pre><br />
<br />
== Build WTP with CBI ==<br />
<br />
To build WTP simply navigate to the directory where you cloned the repo and run:<br />
<br />
<pre><br />
mvn clean verify -Pbree-libs<br />
</pre></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=WTP/Build/CBI_Build&diff=349902WTP/Build/CBI Build2013-10-24T17:38:52Z<p>Thanh.ha.eclipse.org: Created page with "= WTP CBI Build = == Git clone the repo == The repo for WTP's aggregator can be found here: http://git.eclipse.org/c/webtools/webtools.releng.aggregator.git/ You can g..."</p>
<hr />
<div>= WTP CBI Build =<br />
<br />
== Git clone the repo ==<br />
<br />
The repo for WTP's aggregator can be found here:<br />
<br />
http://git.eclipse.org/c/webtools/webtools.releng.aggregator.git/<br />
<br />
You can git clone the repo by running:<br />
<pre><br />
git clone --recursive git://git.eclipse.org/gitroot/webtools/webtools.releng.aggregator.git<br />
</pre><br />
<br />
== Build WTP with CBI ==<br />
<br />
To build WTP simply navigate to the directory where you cloned the repo and run:<br />
<br />
<pre><br />
mvn clean verify<br />
</pre></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=CBI&diff=349424CBI2013-10-18T13:33:45Z<p>Thanh.ha.eclipse.org: /* License Bundle */</p>
<hr />
<div>The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.<br />
<br />
==What is CBI==<br />
<br />
The core of CBI today is Maven with the Tycho plugins. The Tycho plugins teach Maven how to build (and consume) Eclipse plugins and OSGi bundles. This enables building Eclipse projects with "maven clean install" just as one would build other Maven projects.<br />
<br />
Common services such as the Jar signing facility, MacOS signing facility, and Windows signing facility are also included with CBI. Other tools and services may be included in the future as the need arises.<br />
<br />
Over time mature templates and common pom.xml files will be provided that set common values finely honed with experience.<br />
<br />
One might go so far as to include Git, Hudson, the build slaves, and Nexus (aka. the artifact repository & server side of Maven) as part of CBI since they are also common and crucial to builds.<br />
<br />
Gerrit, Bugzilla, and the Downloads site are closely related. Some might consider them part of CBI as well.<br />
<br />
<br />
===Who is using it?===<br />
<br />
There's a [http://wiki.eclipse.org/CBI/Projects list of projects] building with CBI available.<br />
<br />
The Eclipse Foundation would like to have more than 50% of projects building with CBI by end of 2013.<br />
<br />
==Initiative Goals==<br />
<br />
===Primary===<br />
* Make it really easy to contribute Eclipse projects<br />
** Make it really easy to copy & modify source<br />
** Make it really easy to build<br />
** Make it really easy to test<br />
** Make it really easy to post a change for review<br />
** Make it really easy to sign software<br />
<br />
===Secondary===<br />
* Get all Eclipse projects building their software on Eclipse Foundation hardware.<br />
* Enable the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program].<br />
* Make it easy for people to build custom Eclipse distributions.<br />
<br />
<br />
There is a strong link between CBI and the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program] which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.<br />
<br />
It is our hope that this project develops an offering that is compelling so that many projects will move to use it.<br />
<br />
==Next meeting==<br />
<br />
See the [http://wiki.eclipse.org/CBI/Conference conference bridge details]. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder. The dates the upcoming calls are as follows:<br />
* November 15th, 9am EST<br />
<br />
==Resources==<br />
* mailing list [https://dev.eclipse.org/mailman/listinfo/cbi-dev cbi-dev]<br />
<br />
===Bugs===<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=1.0;list_id=2249872 CBI 1.0]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=2.0;list_id=2249872 CBI 2.0]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap&product=CBI&list_id=38248 List of All Bugs] (Product = CBI)<br />
<br />
==Tutorials, News, and other resources==<br />
* [http://www.vogella.com/articles/EclipseTycho/article.html Tycho tutorial by Lars Vogel]<br />
* [http://www.fosslc.org/drupal/content/tycho-good-bad-and-ugly Video discussing JBoss tools use of Tycho]<br />
* [http://wiki.eclipse.org/CBI/Workshops Workshops being developed]<br />
* [http://www.vogella.com/blog/2012/10/08/building-eclipse-sdk-locally-with-maven/ Building Eclipse SDK locally with Maven]<br />
* [http://mickaelistria.wordpress.com/2012/10/08/sonar-at-eclipse-org/ Sonar at Eclipse.org !]<br />
* [http://youtu.be/KJUfLvXiTSw Tycho and CBI Adoption: Feedback from the trenches]<br />
* [http://www.bsiag.com/scout/?p=678 Eclipse Scout builds with CBI]<br />
<br />
==Eclipse platform CBI build==<br />
* [http://wiki.eclipse.org/Platform-releng/Platform_Build Eclipse Platform Build based on CBI] see the [[CBI/Eclipse Platform Build Roadmap]]<br />
<br />
==Preferred Build Technologies==<br />
<br />
===Hudson===<br />
<br />
* The Eclipse [http://hudson.eclipse.org Hudson instance]; and<br />
* Hudson projects using [https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/ Maven and Tycho].<br />
<br />
===Maven===<br />
<br />
Maven 3.0 drives the builds. Projects are expected to provide standard Maven 3.0 POM files for their builds. The builds should be built in such a way that they can be run on the local workstation, or on the Eclipse build server. Note that builds can only be signed on the Eclipse build server.<br />
<br />
* [[Maven/Parent POM|Parent Maven POM]] for Eclipse projects; <br />
* [[Minerva#Signing|Signing Builds]] using Maven; and<br />
* [[Maven|Maven repository support at Eclipse]].<br />
<br />
===Tycho===<br />
<br />
Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.<br />
<br />
Helpful links:<br />
<br />
* [[Tycho|Tycho project]] information, including [[Tycho/Demo Projects|demo projects]]; and<br />
* [http://waynebeaton.wordpress.com/2010/09/23/building-woolsey-with-maven-and-tycho/ Building Woolsey with Maven and Tycho]<br />
* [[Tycho/Reference_Card|Reference Card]]<br />
* [[Tycho/Packaging_Types|Packaging Types]]<br />
<br />
===Nexus===<br />
<br />
[[Services/Nexus]]<br />
<br />
===Signing tool===<br />
<br />
* [http://git.eclipse.org/c/cbi/org.eclipse.cbi.maven.plugins.git/tree/README Maven plugins for signing artifacts]<br />
* [http://wiki.eclipse.org/IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F On demand signing tool]<br />
<br />
==CBI License bundle==<br />
<br />
We offer a P2 repository containing the org.eclipse.license bundle which is located at:<br />
<br />
http://download.eclipse.org/cbi/updates/license/<br />
<br />
This URL is a composite P2 repo containing the license bundle.<br />
<br />
<br />
If you are using Tycho you can add the p2 repo to the <repositories> section of your pom.xml file. Something similar to this:<br />
<br />
<pre><br />
<repository><br />
<id>license-feature</id><br />
<url>http://download.eclipse.org/cbi/updates/license/</url><br />
<layout>p2</layout><br />
</repository><br />
</pre><br />
<br />
<br />
In any particular feature which you need the license you can use the usual feature.xml section:<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<feature<br />
id="org.eclipse.help"<br />
label="%featureName"<br />
version="2.0.0.qualifier"<br />
provider-name="%providerName"<br />
plugin="org.eclipse.help.base"<br />
license-feature="org.eclipse.license"<br />
license-feature-version="1.0.0.qualifier"> <br />
....<br />
</pre><br />
<br />
==Related Topics and Links==<br />
* [http://wiki.eclipse.org/EclipseLTS Long Term Support]<br />
* [http://wiki.eclipse.org/Build_Technologies List of Build Technologies]<br />
<br />
==FAQ==<br />
<br />
* See your [http://wiki.eclipse.org/CBI/FAQ Frequently Asked Question list]<br />
<br />
==Meeting Minutes==<br />
* [http://wiki.eclipse.org/CBI/Jan10_2012 January 10, 2012]<br />
* [http://wiki.eclipse.org/CBI/Jan24_2012 January 24, 2012]<br />
* [http://wiki.eclipse.org/CBI/Feb7_2012 February 7, 2012]<br />
* [http://wiki.eclipse.org/CBI/March6_2012 March 6, 2012]<br />
* [http://wiki.eclipse.org/CBI/Mar20_2012 March 20, 2012]<br />
* [http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012 Code Sprint #1, April 11, 2012] - in Ottawa, Canada<br />
* [http://wiki.eclipse.org/CBI/Apr17_2012 April 17, 2012]<br />
* [http://wiki.eclipse.org/CBI/May1_2012 May 1, 2012]<br />
* [http://wiki.eclipse.org/CBI/May15_2012 May 15, 2012]<br />
* [http://wiki.eclipse.org/CBI/May29_2012 May 29, 2012]<br />
* [http://wiki.eclipse.org/CBI/June12_2012 June 12, 2012]<br />
* [http://wiki.eclipse.org/CBI/June26_2012 June 26, 2012]<br />
* [http://wiki.eclipse.org/CBI/July25_2012 July 25, 2012]<br />
* [http://wiki.eclipse.org/CBI/November15_2012 November 15, 2012]<br />
* [http://wiki.eclipse.org/CBI/January8_2013 January 8, 2013]<br />
<br />
[[Category:CBI]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344729GitHub2013-07-30T17:34:56Z<p>Thanh.ha.eclipse.org: /* Step 2 - Delete old branches and tags that were renamed */</p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
<br />
== Migrating a GitHub repo to Eclipse Foundation GitHub organization ==<br />
<br />
=== Step 0 - Transfer repo from original location to Eclipse Organization ===<br />
<br />
=== Step 1 - Create new branches and tags with namespace /_old/ ===<br />
<br />
$ git --git-dir=new.git init<br />
$ git --git-dir=new.git fetch URL refs/heads/*:refs/heads/_old/* refs/tags/*:refs/tags/_old/*<br />
$ git --git-dir=new.git push --all URL<br />
<br />
Replace URL with the repository location on GitHub.<br />
<br />
=== Step 2 - Delete old branches and tags that were renamed ===<br />
<br />
# Verify that we are deleting the branches and tags we want to delete<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do echo :$line; done;<br />
$ git tag | cut -d/ -f2 | while read line; do echo :$line; done;<br />
<br />
# Actually delete the branches and tags<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
$ git tag | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
<br />
Deleting master branch will fail because it's the current branch.<br />
<br />
*** NOTE: we should probably not delete branch gh-pages... it's a github special page.... "grep -v gh-pages"?<br />
*** NOTE: should verify that we aren't deleting the new "_old" prefix branches during this process<br />
<br />
=== Step 3 - Push a new Eclipse Approved master ===<br />
<br />
$ git update-ref -d refs/heads/master<br />
$ git commit -m "New initial commit"<br />
$ git push origin master<br />
$ git push eclipse master<br />
<br />
=== Step 4 - refs replace ===<br />
<br />
$ git replace new_initial_commit old_history_last_commit<br />
$ git push origin refs/replace/commit_hash<br />
<br />
*** NOTE: End user mush additionally run (If they want the history): git fetch origin '+refs/replace/*:refs/replace/*'<br />
<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*<br />
<br />
<br />
== Forked repositories ==<br />
<br />
Forked repositories will have branches that no longer match with upstream due to upstream renaming all the branches to /_old/ prefix. The easiest way to resolve this issue is to refork upstream. However if this is not an option below lists the tasks that will need to be considered in each fork of the project.<br />
<br />
Fix master branch<br />
<br />
The fork’s master branch and upstream master branches will be different. To fix this the fork owner can rename their original master branch and push a new master branch based on the upstream project’s master.<br />
<br />
$ git branch -m master old_master<br />
$ git push origin old_master<br />
$ git checkout upstream/master<br />
$ git checkout -b master<br />
$ git push --force origin master<br />
<br />
WARNING: These command will backup master to old_master and then force pushes a brand new master to your GitHub repository.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344728GitHub2013-07-30T17:34:12Z<p>Thanh.ha.eclipse.org: /* Step 2 - Delete old branches and tags that were renamed */</p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
<br />
== Migrating a GitHub repo to Eclipse Foundation GitHub organization ==<br />
<br />
=== Step 0 - Transfer repo from original location to Eclipse Organization ===<br />
<br />
=== Step 1 - Create new branches and tags with namespace /_old/ ===<br />
<br />
$ git --git-dir=new.git init<br />
$ git --git-dir=new.git fetch URL refs/heads/*:refs/heads/_old/* refs/tags/*:refs/tags/_old/*<br />
$ git --git-dir=new.git push --all URL<br />
<br />
Replace URL with the repository location on GitHub.<br />
<br />
=== Step 2 - Delete old branches and tags that were renamed ===<br />
<br />
# Verify that we are deleting the branches we want to delete<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do echo :$line; done;<br />
<br />
# Actually delete the branches<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
# Delete tags if required<br />
$ git tag | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
<br />
Deleting master branch will fail because it's the current branch.<br />
<br />
*** NOTE: we should probably not delete branch gh-pages... it's a github special page.... "grep -v gh-pages"?<br />
*** NOTE: should verify that we aren't deleting the new "_old" prefix branches during this process<br />
<br />
=== Step 3 - Push a new Eclipse Approved master ===<br />
<br />
$ git update-ref -d refs/heads/master<br />
$ git commit -m "New initial commit"<br />
$ git push origin master<br />
$ git push eclipse master<br />
<br />
=== Step 4 - refs replace ===<br />
<br />
$ git replace new_initial_commit old_history_last_commit<br />
$ git push origin refs/replace/commit_hash<br />
<br />
*** NOTE: End user mush additionally run (If they want the history): git fetch origin '+refs/replace/*:refs/replace/*'<br />
<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*<br />
<br />
<br />
== Forked repositories ==<br />
<br />
Forked repositories will have branches that no longer match with upstream due to upstream renaming all the branches to /_old/ prefix. The easiest way to resolve this issue is to refork upstream. However if this is not an option below lists the tasks that will need to be considered in each fork of the project.<br />
<br />
Fix master branch<br />
<br />
The fork’s master branch and upstream master branches will be different. To fix this the fork owner can rename their original master branch and push a new master branch based on the upstream project’s master.<br />
<br />
$ git branch -m master old_master<br />
$ git push origin old_master<br />
$ git checkout upstream/master<br />
$ git checkout -b master<br />
$ git push --force origin master<br />
<br />
WARNING: These command will backup master to old_master and then force pushes a brand new master to your GitHub repository.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344727GitHub2013-07-30T17:30:36Z<p>Thanh.ha.eclipse.org: /* Step 2 - Delete old branches and tags that were renamed */</p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
<br />
== Migrating a GitHub repo to Eclipse Foundation GitHub organization ==<br />
<br />
=== Step 0 - Transfer repo from original location to Eclipse Organization ===<br />
<br />
=== Step 1 - Create new branches and tags with namespace /_old/ ===<br />
<br />
$ git --git-dir=new.git init<br />
$ git --git-dir=new.git fetch URL refs/heads/*:refs/heads/_old/* refs/tags/*:refs/tags/_old/*<br />
$ git --git-dir=new.git push --all URL<br />
<br />
Replace URL with the repository location on GitHub.<br />
<br />
=== Step 2 - Delete old branches and tags that were renamed ===<br />
<br />
# Verify that we are deleting the branches we want to delete<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do echo :$line; done;<br />
<br />
# Actually delete the branches<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
$ git tag | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
<br />
Deleting master branch will fail because it's the current branch.<br />
<br />
*** NOTE: we should probably not delete branch gh-pages... it's a github special page.... "grep -v gh-pages"?<br />
*** NOTE: should verify that we aren't deleting the new "_old" prefix branches during this process<br />
<br />
=== Step 3 - Push a new Eclipse Approved master ===<br />
<br />
$ git update-ref -d refs/heads/master<br />
$ git commit -m "New initial commit"<br />
$ git push origin master<br />
$ git push eclipse master<br />
<br />
=== Step 4 - refs replace ===<br />
<br />
$ git replace new_initial_commit old_history_last_commit<br />
$ git push origin refs/replace/commit_hash<br />
<br />
*** NOTE: End user mush additionally run (If they want the history): git fetch origin '+refs/replace/*:refs/replace/*'<br />
<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*<br />
<br />
<br />
== Forked repositories ==<br />
<br />
Forked repositories will have branches that no longer match with upstream due to upstream renaming all the branches to /_old/ prefix. The easiest way to resolve this issue is to refork upstream. However if this is not an option below lists the tasks that will need to be considered in each fork of the project.<br />
<br />
Fix master branch<br />
<br />
The fork’s master branch and upstream master branches will be different. To fix this the fork owner can rename their original master branch and push a new master branch based on the upstream project’s master.<br />
<br />
$ git branch -m master old_master<br />
$ git push origin old_master<br />
$ git checkout upstream/master<br />
$ git checkout -b master<br />
$ git push --force origin master<br />
<br />
WARNING: These command will backup master to old_master and then force pushes a brand new master to your GitHub repository.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344726GitHub2013-07-30T17:26:16Z<p>Thanh.ha.eclipse.org: </p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
<br />
== Migrating a GitHub repo to Eclipse Foundation GitHub organization ==<br />
<br />
=== Step 0 - Transfer repo from original location to Eclipse Organization ===<br />
<br />
=== Step 1 - Create new branches and tags with namespace /_old/ ===<br />
<br />
$ git --git-dir=new.git init<br />
$ git --git-dir=new.git fetch URL refs/heads/*:refs/heads/_old/* refs/tags/*:refs/tags/_old/*<br />
$ git --git-dir=new.git push --all URL<br />
<br />
Replace URL with the repository location on GitHub.<br />
<br />
=== Step 2 - Delete old branches and tags that were renamed ===<br />
<br />
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
$ git tag | cut -d/ -f2 | while read line; do git push origin :$line; done;<br />
<br />
Deleting master branch will fail because it's the current branch.<br />
<br />
*** NOTE: we should probably not delete branch gh-pages... it's a github special page.... "grep -v gh-pages"?<br />
*** NOTE: should verify that we aren't deleting the new "_old" prefix branches during this process<br />
<br />
=== Step 3 - Push a new Eclipse Approved master ===<br />
<br />
$ git update-ref -d refs/heads/master<br />
$ git commit -m "New initial commit"<br />
$ git push origin master<br />
$ git push eclipse master<br />
<br />
=== Step 4 - refs replace ===<br />
<br />
$ git replace new_initial_commit old_history_last_commit<br />
$ git push origin refs/replace/commit_hash<br />
<br />
*** NOTE: End user mush additionally run (If they want the history): git fetch origin '+refs/replace/*:refs/replace/*'<br />
<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*<br />
<br />
<br />
== Forked repositories ==<br />
<br />
Forked repositories will have branches that no longer match with upstream due to upstream renaming all the branches to /_old/ prefix. The easiest way to resolve this issue is to refork upstream. However if this is not an option below lists the tasks that will need to be considered in each fork of the project.<br />
<br />
Fix master branch<br />
<br />
The fork’s master branch and upstream master branches will be different. To fix this the fork owner can rename their original master branch and push a new master branch based on the upstream project’s master.<br />
<br />
$ git branch -m master old_master<br />
$ git push origin old_master<br />
$ git checkout upstream/master<br />
$ git checkout -b master<br />
$ git push --force origin master<br />
<br />
WARNING: These command will backup master to old_master and then force pushes a brand new master to your GitHub repository.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344725GitHub2013-07-30T17:20:52Z<p>Thanh.ha.eclipse.org: /* Forked repositories */</p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*<br />
<br />
<br />
== Forked repositories ==<br />
<br />
Forked repositories will have branches that no longer match with upstream due to upstream renaming all the branches to /_old/ prefix. The easiest way to resolve this issue is to refork upstream. However if this is not an option below lists the tasks that will need to be considered in each fork of the project.<br />
<br />
Fix master branch<br />
<br />
The fork’s master branch and upstream master branches will be different. To fix this the fork owner can rename their original master branch and push a new master branch based on the upstream project’s master.<br />
<br />
$ git branch -m master old_master<br />
$ git push origin old_master<br />
$ git checkout upstream/master<br />
$ git checkout -b master<br />
$ git push --force origin master<br />
<br />
WARNING: These command will backup master to old_master and then force pushes a brand new master to your GitHub repository.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344702GitHub2013-07-30T15:23:00Z<p>Thanh.ha.eclipse.org: /* End User required actions */</p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344701GitHub2013-07-30T15:22:21Z<p>Thanh.ha.eclipse.org: </p>
<hr />
<div>This page details the required actions to migrating a repo to Eclipse Foundation GitHub.<br />
<br />
== End User required actions ==<br />
<br />
If a user had previously cloned the repository before the move to their computer. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=GitHub&diff=344699GitHub2013-07-30T15:18:20Z<p>Thanh.ha.eclipse.org: New page: == End User required actions == If a user had previously cloned the repository before the move to their computer. The move will have caused a few issues to the user’s local repository. ...</p>
<hr />
<div>== End User required actions ==<br />
<br />
If a user had previously cloned the repository before the move to their computer. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.<br />
<br />
=== Update repository URLs ===<br />
<br />
The origin remote will need to be updated to point to the new URL.<br />
<br />
$ git remote set-url origin git@github.com:Eclipse/project.git<br />
<br />
=== Fix master branch ===<br />
<br />
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.<br />
<br />
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:<br />
<br />
$ git checkout origin/master<br />
$ git branch -m master old_master<br />
$ git checkout -b master<br />
<br />
Repeat these steps for any other additional branches that may have conflict.<br />
<br />
=== (Optional) Git Replace history ===<br />
<br />
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.<br />
<br />
$ git fetch origin refs/replace/*:refs/replace/*</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=CBI&diff=343874CBI2013-07-19T18:30:29Z<p>Thanh.ha.eclipse.org: /* Signing tool */</p>
<hr />
<div>The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.<br />
<br />
==What is CBI==<br />
<br />
The core of CBI today is Maven with the Tycho plugins. The Tycho plugins teach Maven how to build (and consume) Eclipse plugins and OSGi bundles. This enables building Eclipse projects with "maven clean install" just as one would build other Maven projects.<br />
<br />
Common services such as the Jar signing facility, MacOS signing facility, and Windows signing facility are also included with CBI. Other tools and services may be included in the future as the need arises.<br />
<br />
Over time mature templates and common pom.xml files will be provided that set common values finely honed with experience.<br />
<br />
One might go so far as to include Git, Hudson, the build slaves, and Nexus (aka. the artifact repository & server side of Maven) as part of CBI since they are also common and crucial to builds.<br />
<br />
Gerrit, Bugzilla, and the Downloads site are closely related. Some might consider them part of CBI as well.<br />
<br />
<br />
===Who is using it?===<br />
<br />
There's a [http://wiki.eclipse.org/CBI/Projects list of projects] building with CBI available.<br />
<br />
The Eclipse Foundation would like to have more than 50% of projects building with CBI by end of 2013.<br />
<br />
==Initiative Goals==<br />
<br />
===Primary===<br />
* Make it really easy to contribute Eclipse projects<br />
** Make it really easy to copy & modify source<br />
** Make it really easy to build<br />
** Make it really easy to test<br />
** Make it really easy to post a change for review<br />
** Make it really easy to sign software<br />
<br />
===Secondary===<br />
* Get all Eclipse projects building their software on Eclipse Foundation hardware.<br />
* Enable the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program].<br />
* Make it easy for people to build custom Eclipse distributions.<br />
<br />
<br />
There is a strong link between CBI and the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program] which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.<br />
<br />
It is our hope that this project develops an offering that is compelling so that many projects will move to use it.<br />
<br />
==Next meeting==<br />
<br />
See the [http://wiki.eclipse.org/CBI/Conference conference bridge details]. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder. The dates the upcoming calls are as follows:<br />
* November 15th, 9am EST<br />
<br />
==Resources==<br />
* mailing list [https://dev.eclipse.org/mailman/listinfo/cbi-dev cbi-dev]<br />
<br />
===Bugs===<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=1.0;list_id=2249872 CBI 1.0]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=2.0;list_id=2249872 CBI 2.0]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap&product=CBI&list_id=38248 List of All Bugs] (Product = CBI)<br />
<br />
==Tutorials, News, and other resources==<br />
* [http://www.vogella.com/articles/EclipseTycho/article.html Tycho tutorial by Lars Vogel]<br />
* [http://www.fosslc.org/drupal/content/tycho-good-bad-and-ugly Video discussing JBoss tools use of Tycho]<br />
* [http://wiki.eclipse.org/CBI/Workshops Workshops being developed]<br />
* [http://www.vogella.com/blog/2012/10/08/building-eclipse-sdk-locally-with-maven/ Building Eclipse SDK locally with Maven]<br />
* [http://mickaelistria.wordpress.com/2012/10/08/sonar-at-eclipse-org/ Sonar at Eclipse.org !]<br />
* [http://youtu.be/KJUfLvXiTSw Tycho and CBI Adoption: Feedback from the trenches]<br />
* [http://www.bsiag.com/scout/?p=678 Eclipse Scout builds with CBI]<br />
<br />
==Eclipse platform CBI build==<br />
* [http://wiki.eclipse.org/Platform-releng/Platform_Build Eclipse Platform Build based on CBI] see the [[CBI/Eclipse Platform Build Roadmap]]<br />
<br />
==Preferred Build Technologies==<br />
<br />
===Hudson===<br />
<br />
* The Eclipse [http://hudson.eclipse.org Hudson instance]; and<br />
* Hudson projects using [https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/ Maven and Tycho].<br />
<br />
===Maven===<br />
<br />
Maven 3.0 drives the builds. Projects are expected to provide standard Maven 3.0 POM files for their builds. The builds should be built in such a way that they can be run on the local workstation, or on the Eclipse build server. Note that builds can only be signed on the Eclipse build server.<br />
<br />
* [[Maven/Parent POM|Parent Maven POM]] for Eclipse projects; <br />
* [[Minerva#Signing|Signing Builds]] using Maven; and<br />
* [[Maven|Maven repository support at Eclipse]].<br />
<br />
===Tycho===<br />
<br />
Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.<br />
<br />
Helpful links:<br />
<br />
* [[Tycho|Tycho project]] information, including [[Tycho/Demo Projects|demo projects]]; and<br />
* [http://waynebeaton.wordpress.com/2010/09/23/building-woolsey-with-maven-and-tycho/ Building Woolsey with Maven and Tycho]<br />
* [[Tycho/Reference_Card|Reference Card]]<br />
* [[Tycho/Packaging_Types|Packaging Types]]<br />
<br />
===Nexus===<br />
<br />
[[Services/Nexus]]<br />
<br />
===Signing tool===<br />
<br />
* [http://git.eclipse.org/c/cbi/org.eclipse.cbi.maven.plugins.git/tree/README Maven plugins for signing artifacts]<br />
* [http://wiki.eclipse.org/IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F On demand signing tool]<br />
<br />
==Related Topics and Links==<br />
* [http://wiki.eclipse.org/EclipseLTS Long Term Support]<br />
* [http://wiki.eclipse.org/Build_Technologies List of Build Technologies]<br />
<br />
==FAQ==<br />
<br />
* See your [http://wiki.eclipse.org/CBI/FAQ Frequently Asked Question list]<br />
<br />
==Meeting Minutes==<br />
* [http://wiki.eclipse.org/CBI/Jan10_2012 January 10, 2012]<br />
* [http://wiki.eclipse.org/CBI/Jan24_2012 January 24, 2012]<br />
* [http://wiki.eclipse.org/CBI/Feb7_2012 February 7, 2012]<br />
* [http://wiki.eclipse.org/CBI/March6_2012 March 6, 2012]<br />
* [http://wiki.eclipse.org/CBI/Mar20_2012 March 20, 2012]<br />
* [http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012 Code Sprint #1, April 11, 2012] - in Ottawa, Canada<br />
* [http://wiki.eclipse.org/CBI/Apr17_2012 April 17, 2012]<br />
* [http://wiki.eclipse.org/CBI/May1_2012 May 1, 2012]<br />
* [http://wiki.eclipse.org/CBI/May15_2012 May 15, 2012]<br />
* [http://wiki.eclipse.org/CBI/May29_2012 May 29, 2012]<br />
* [http://wiki.eclipse.org/CBI/June12_2012 June 12, 2012]<br />
* [http://wiki.eclipse.org/CBI/June26_2012 June 26, 2012]<br />
* [http://wiki.eclipse.org/CBI/July25_2012 July 25, 2012]<br />
* [http://wiki.eclipse.org/CBI/November15_2012 November 15, 2012]<br />
* [http://wiki.eclipse.org/CBI/January8_2013 January 8, 2013]<br />
<br />
[[Category:CBI]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=CBI&diff=343872CBI2013-07-19T18:28:59Z<p>Thanh.ha.eclipse.org: /* Signing tool */</p>
<hr />
<div>The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.<br />
<br />
==What is CBI==<br />
<br />
The core of CBI today is Maven with the Tycho plugins. The Tycho plugins teach Maven how to build (and consume) Eclipse plugins and OSGi bundles. This enables building Eclipse projects with "maven clean install" just as one would build other Maven projects.<br />
<br />
Common services such as the Jar signing facility, MacOS signing facility, and Windows signing facility are also included with CBI. Other tools and services may be included in the future as the need arises.<br />
<br />
Over time mature templates and common pom.xml files will be provided that set common values finely honed with experience.<br />
<br />
One might go so far as to include Git, Hudson, the build slaves, and Nexus (aka. the artifact repository & server side of Maven) as part of CBI since they are also common and crucial to builds.<br />
<br />
Gerrit, Bugzilla, and the Downloads site are closely related. Some might consider them part of CBI as well.<br />
<br />
<br />
===Who is using it?===<br />
<br />
There's a [http://wiki.eclipse.org/CBI/Projects list of projects] building with CBI available.<br />
<br />
The Eclipse Foundation would like to have more than 50% of projects building with CBI by end of 2013.<br />
<br />
==Initiative Goals==<br />
<br />
===Primary===<br />
* Make it really easy to contribute Eclipse projects<br />
** Make it really easy to copy & modify source<br />
** Make it really easy to build<br />
** Make it really easy to test<br />
** Make it really easy to post a change for review<br />
** Make it really easy to sign software<br />
<br />
===Secondary===<br />
* Get all Eclipse projects building their software on Eclipse Foundation hardware.<br />
* Enable the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program].<br />
* Make it easy for people to build custom Eclipse distributions.<br />
<br />
<br />
There is a strong link between CBI and the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program] which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.<br />
<br />
It is our hope that this project develops an offering that is compelling so that many projects will move to use it.<br />
<br />
==Next meeting==<br />
<br />
See the [http://wiki.eclipse.org/CBI/Conference conference bridge details]. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder. The dates the upcoming calls are as follows:<br />
* November 15th, 9am EST<br />
<br />
==Resources==<br />
* mailing list [https://dev.eclipse.org/mailman/listinfo/cbi-dev cbi-dev]<br />
<br />
===Bugs===<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=1.0;list_id=2249872 CBI 1.0]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=2.0;list_id=2249872 CBI 2.0]<br />
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap&product=CBI&list_id=38248 List of All Bugs] (Product = CBI)<br />
<br />
==Tutorials, News, and other resources==<br />
* [http://www.vogella.com/articles/EclipseTycho/article.html Tycho tutorial by Lars Vogel]<br />
* [http://www.fosslc.org/drupal/content/tycho-good-bad-and-ugly Video discussing JBoss tools use of Tycho]<br />
* [http://wiki.eclipse.org/CBI/Workshops Workshops being developed]<br />
* [http://www.vogella.com/blog/2012/10/08/building-eclipse-sdk-locally-with-maven/ Building Eclipse SDK locally with Maven]<br />
* [http://mickaelistria.wordpress.com/2012/10/08/sonar-at-eclipse-org/ Sonar at Eclipse.org !]<br />
* [http://youtu.be/KJUfLvXiTSw Tycho and CBI Adoption: Feedback from the trenches]<br />
* [http://www.bsiag.com/scout/?p=678 Eclipse Scout builds with CBI]<br />
<br />
==Eclipse platform CBI build==<br />
* [http://wiki.eclipse.org/Platform-releng/Platform_Build Eclipse Platform Build based on CBI] see the [[CBI/Eclipse Platform Build Roadmap]]<br />
<br />
==Preferred Build Technologies==<br />
<br />
===Hudson===<br />
<br />
* The Eclipse [http://hudson.eclipse.org Hudson instance]; and<br />
* Hudson projects using [https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/ Maven and Tycho].<br />
<br />
===Maven===<br />
<br />
Maven 3.0 drives the builds. Projects are expected to provide standard Maven 3.0 POM files for their builds. The builds should be built in such a way that they can be run on the local workstation, or on the Eclipse build server. Note that builds can only be signed on the Eclipse build server.<br />
<br />
* [[Maven/Parent POM|Parent Maven POM]] for Eclipse projects; <br />
* [[Minerva#Signing|Signing Builds]] using Maven; and<br />
* [[Maven|Maven repository support at Eclipse]].<br />
<br />
===Tycho===<br />
<br />
Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.<br />
<br />
Helpful links:<br />
<br />
* [[Tycho|Tycho project]] information, including [[Tycho/Demo Projects|demo projects]]; and<br />
* [http://waynebeaton.wordpress.com/2010/09/23/building-woolsey-with-maven-and-tycho/ Building Woolsey with Maven and Tycho]<br />
* [[Tycho/Reference_Card|Reference Card]]<br />
* [[Tycho/Packaging_Types|Packaging Types]]<br />
<br />
===Nexus===<br />
<br />
[[Services/Nexus]]<br />
<br />
===Signing tool===<br />
<br />
* [[:CBI:Maven Plugins for Signing Artifacts]]<br />
* [http://wiki.eclipse.org/IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F On demand signing tool]<br />
<br />
==Related Topics and Links==<br />
* [http://wiki.eclipse.org/EclipseLTS Long Term Support]<br />
* [http://wiki.eclipse.org/Build_Technologies List of Build Technologies]<br />
<br />
==FAQ==<br />
<br />
* See your [http://wiki.eclipse.org/CBI/FAQ Frequently Asked Question list]<br />
<br />
==Meeting Minutes==<br />
* [http://wiki.eclipse.org/CBI/Jan10_2012 January 10, 2012]<br />
* [http://wiki.eclipse.org/CBI/Jan24_2012 January 24, 2012]<br />
* [http://wiki.eclipse.org/CBI/Feb7_2012 February 7, 2012]<br />
* [http://wiki.eclipse.org/CBI/March6_2012 March 6, 2012]<br />
* [http://wiki.eclipse.org/CBI/Mar20_2012 March 20, 2012]<br />
* [http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012 Code Sprint #1, April 11, 2012] - in Ottawa, Canada<br />
* [http://wiki.eclipse.org/CBI/Apr17_2012 April 17, 2012]<br />
* [http://wiki.eclipse.org/CBI/May1_2012 May 1, 2012]<br />
* [http://wiki.eclipse.org/CBI/May15_2012 May 15, 2012]<br />
* [http://wiki.eclipse.org/CBI/May29_2012 May 29, 2012]<br />
* [http://wiki.eclipse.org/CBI/June12_2012 June 12, 2012]<br />
* [http://wiki.eclipse.org/CBI/June26_2012 June 26, 2012]<br />
* [http://wiki.eclipse.org/CBI/July25_2012 July 25, 2012]<br />
* [http://wiki.eclipse.org/CBI/November15_2012 November 15, 2012]<br />
* [http://wiki.eclipse.org/CBI/January8_2013 January 8, 2013]<br />
<br />
[[Category:CBI]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=342414LTS/HowTos2013-07-02T18:16:34Z<p>Thanh.ha.eclipse.org: /* HowTos */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
Gerrit supports email notifications which you can register as a user for projects your interested in being notified about when a new review comes in. To subscribe to project notifications follow these steps:<br />
<br />
# Click '''Settings'''<br />
# Click '''Watched Projects'''<br />
# Enter a project to watch and click '''Watch'''<br />
<br />
<br />
Gerrit also supports project level notifications which requires more configuration but is described in this document: <br />
https://git.eclipse.org/r/Documentation/user-notify.html<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= Using TortoiseGit to "git submodule update" =<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
= FAQ =<br />
<br />
== Forgot Password ==<br />
<br />
If you forgot your password you can use the following link to reset your password:<br />
<br />
https://dev.eclipse.org/site_login/createaccount.php<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=Maven&diff=342317Maven2013-07-02T13:41:33Z<p>Thanh.ha.eclipse.org: </p>
<hr />
<div>* Note: maven.eclipse.org is planned for decommission per [http://bugs.eclipse.org/405750 Bug 405750], repo.eclipse.org is replacing maven.eclipse.org; details on the new service can be found at [[Services/Nexus]].<br />
<br />
A prototype of Maven repository support at Eclipse is undergoing creation.<br />
<br />
The site currently runs Nexus and is available at http://maven.eclipse.org/nexus/<br />
<br />
Discussion regarding this repository occurs in the [https://dev.eclipse.org/mailman/listinfo/dash-dev dash-dev] mailing list.<br />
= Proposal =<br />
<br />
Nexus is capable of segregating and aggregating individual repositories. To facilitate the management of artefacts hosted, it is proposed that the Nexus repository is configured with a number of subsidiary repositories which will hold different content, as follows:<br />
<br />
* <code>/orbit</code> - for holding Orbit approved external dependencies<br />
* <code>/release</code> - for aggregating<br />
** <code>/release/ganymede</code> - for storing final releases, e.g. Ganymede 3.5, 3.5.1, 3.5.2<br />
** <code>/release/helios</code> - for storing final releases, e.g. Helios 3.6, 3.6.1, 3.6.2<br />
* <code>/milestone</code> - for aggregating<br />
** <code>/milestone/juno</code> - for storing milestone releases (for Helios+1) e.g. 3.7M1, 3.7M2<br />
* <code>/integration</code> - for aggregating<br />
** <code>/integration/juno</code> - for storing -SNAPSHOT equivalents of integration (I) builds; to be purged frequently (weekly?)<br />
* <code>/nightly</code> - for aggregating<br />
** <code>/nightly/juno</code> - for storing -SNAPSHOT equivalents of nightly (N) builds; to be purged frequently (nightly?)<br />
<br />
It is proposed that the release entries are permanently available, whilst milestones may be cleared out after the final release, and nightly and integration builds are cleared out automatically.<br />
<br />
In addition, for testing:<br />
<br />
* <code>/testing</code> - for storing -SNAPSHOT equivalents for testing purposes; to be purged occasionally (monthly?)<br />
<br />
To support automated builds at Eclipse, it may make sense to proxy publicly available repositories, although these should not be publicly available.<br />
<br />
* <code>/central</code> - for aggregating:<br />
** <code>/repo1</code> - mirror of http://repo1.maven.org<br />
** <code>/repo2</code> - mirror of http://repo1.maven.org<br />
* <code>/codehaus-snapshots</code> - mirror of http://snapshots.repository.codehaus.org/ - may be needed for findbugs for tycho builds<br />
* <code>/codehaus</code> - mirror of http://repository.codehaus.org/<br />
* <code>/sonatype</code> - mirror of ?<br />
<br />
To make it easy to consume these for plugins, it may make sense to have a general name which aggregates all for these (e.g. <code>/build</code>)?<br />
<br />
== GAVs ==<br />
<br />
For any JAR, <code>org.eclipse.a.b.c</code>, the groupId will be <code>org.eclipse.a</code> and the artifactId will be <code>org.eclipse.a.b.c</code>.<br />
<br />
Versions will only use the major.minor.micro format. Build/quantifiers will be dropped. For releases and milestones, these should only be published after the official components have been created and so build IDs will not be an issue. For nightly/snapshot releases, the designator -SNAPSHOT will be used.<br />
<br />
== Repositories ==<br />
<br />
In order to build against known good sources, the 'repositories' should be configured such that they only consume from <code>/central</code> for acquisition of Maven plugins, and not to satisfy build dependencies. In other words, something like:<br />
<br />
<pre><br />
<repositories><br />
<repository><br />
<id>orbit</id><br />
<name>Orbit approved dependency repository</name><br />
<layout>maven2</layout><br />
<url>http://maven.eclipse.org/orbit</url><br />
<snapshots><enabled>false</enabled></snapshot><br />
</repository><br />
</repositories><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>central</id><br />
<name>Maven central</name><br />
<layout>maven2</layout><br />
<url>http://maven.eclipse.org/build</url><br />
<snapshots><enabled>false</enabled></snapshot><br />
<releases><updatePolicy>never</updatePolicy></releases> <br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
This will enable plugin dependencies (e.g. Tycho) to be resolved whilst not allowing project dependencies to consume other than from the Orbit pre-approved repository.<br />
<br />
== Profiles ==<br />
<br />
To allow different repositories to be switched between, we could use the profile mechanism in Maven to allow other repositories to be brought in:<br />
<br />
<pre><br />
<profiles><br />
<profile><br />
<id>milestone</id><br />
<activation><activeByDefault>false</activeByDefault></activation><br />
<repositories><br />
<repository><br />
<id>milestone</id><br />
<name>Milestone releases</name><br />
<url>http://maven.eclipse.org/milestone</url><br />
<snapshots><enabled>false</enabled></snapshots><br />
</repository><br />
</repositories> <br />
</profile><br />
<profile><br />
<id>integration</id><br />
<activation><activeByDefault>false</activeByDefault></activation><br />
<repositories><br />
<repository><br />
<id>integration</id><br />
<name>Integration releases</name><br />
<url>http://maven.eclipse.org/integration</url><br />
<snapshots><enabled>true</enabled></snapshots><br />
</repository><br />
</repositories> <br />
</profile><br />
<profile><br />
<id>nightly</id><br />
<activation><activeByDefault>false</activeByDefault></activation><br />
<repositories><br />
<repository><br />
<id>nightly</id><br />
<name>Nightly releases</name><br />
<url>http://maven.eclipse.org/nightly</url><br />
<snapshots><enabled>true</enabled></snapshots><br />
</repository><br />
</repositories> <br />
</profile><br />
</profiles><br />
</pre><br />
<br />
This will allow compilation against a milestone, integration or nightly branch set of dependencies with e.g. <code>maven -P nightly</code>.<br />
<br />
== Open issues ==<br />
<br />
<br />
== Related Bugs ==<br />
<br />
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 bug 283745] - Provide a Maven repository for stuff built at Eclipse <br />
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=340416 bug 340416] - Resolving dependencies from Orbit<br />
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=199302 bug 199302] - [SWT] Maven & SWT<br />
<br />
[[Category:Maven]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=IT_Infrastructure_Doc&diff=342094IT Infrastructure Doc2013-06-30T04:28:02Z<p>Thanh.ha.eclipse.org: /* Web service (Instant) - Don't pass -i to curl which includes the HTTP Header in your output file */</p>
<hr />
<div><span style="font-size: 90%">< [[Development Resources]]</span><br />
<br />
==Website==<br />
===How do I setup my project website?===<br />
{{Important |Git migration in progress|See {{Bug|359737}} or [http://waynebeaton.wordpress.com/2012/08/28/migrating-eclipse-project-websites-to-git/ this blog post] for more information.}}<br />
<br />
Project websites are hosted in a CVS repository separate from the actual project code. The repository path is dev.eclipse.org:/cvsroot/org.eclipse, in the www component.<br />
Once the webmaster<br />
adds a space for your project, files you commit to the website CVS are automatically checked out to www.eclipse.org/xyz, where <br />
xyz is your project's short name.<br />
You are free to use HTML and PHP on your website.<br />
<br >Hosting a project website is normally done when the project proposal has been approved.<br />
If you suspect your files are not being checked out to the www.eclipse.org website, simply commit a small change to one file. This is usually<br />
enough to trigger a website refresh.<br />
<br />
===How do I author web pages using the Phoenix method?===<br />
Please see <a href=phoenix.php> this document</a> for information on using Phoenix.<br />
You can also check out: [[Using Phoenix]] and [http://www.eclipse.org/phoenix/docs/sample_pages.php Sample Pages]<br />
<br />
===Access the Bugzilla database using PHP?===<br />
Please see the section labeled "[tools]" in the [http://portal.eclipse.org|MyFoundation Portal]<br />
<br />
===Use a database for my website?===<br />
We currently do not offer projects with database support.<br />
<br />
===I need to put a large file on my website. How should I do this?===<br />
Large (1 MB+) ZIP and JAR files must be put in the downloads area, using the Find A Mirror script to link to them.<br />
However, small files (less than 1 MB) can be put on the www.eclipse.org/yourproject website directly without causing too much harm.<br />
<br />
The Find A Mirror script supports transparent mirror use, so large screencasts and PDFs can be put in the downloads area as well without imposing the added step of selecting<br />
a mirror site for the file. Simply add &amp;r=1 to the URL. For instance, http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.1-200506271435/eclipse-SDK-3.1-linux-gtk.tar.gz&amp;r=1 will fetch you the <br />
Eclipse SDK 3.1 for Linux from a random mirror site without asking you which one.<br />
<br />
Remember to allow our mirrors at least 24 hours to sync up before using a transparent mirror redirect. <br />
<br />
===Use PHP on my website?===<br />
PHP support is available on www.eclipse.org only. Simply commit files with the .php file extension to your website's CVS repository.<br />
Although some projects host PHP files on download.eclipse.org, we do not encourage or recommend it.<br />
<br />
Eclipse.org is a high-traffic website. Please make sure your PHP code is optimized to run in this type of environment. See the next item. <br />
<br />
===Optimize my PHP code for large-scale use?===<br />
Eclipse.org is a high-traffic website. To improve PHP's functionality, we have set very liberal limits on how many resources<br />
PHP can consume. However. if if your project is very popular, bad PHP code can slow the entire site down.<br />
<br />
Of course, we could harden PHP to protect our website, but that would cut some functionality. Some tips for you:<br />
<br />
* '''Never call the web service to include/open files''' - include("http://www.eclipse.org/somefile.html") and fopen("http://localhost/somefile.xml") are very costly to run, because they call the web service, and can lead to eclipse.org Denial-Of-Servicing itself under heavy load.<br />
* '''Never include/open remote files''' - include("http://www.someothersite.org/somefile.html") is forbidden, as someone could launch a Denial-Of-Service attack against a remote site. We don't allow you to establish remote connections from eclipse.org servers other than the build server.<br />
* '''Sanitize your incoming parameters''' - include($parameter) is particularly dangerous if $parameter is not sanitized. Someone could freely surf the web anonymously, hiding behind eclipse.org servers, or they could use your page to access local files, or launch Denial-Of-Service attacks against remote servers. <br />
* '''Cache aggregated, processor-intensive data''' - SQL aggregations, file system scans, Bugzilla lists can (and should) be cached to avoid redundant processor- and disk-intensive operations. For instance, scanning through download.eclipse.org directories to display the size of a build could be useful, but doesn't need to happen for each website visitor. Cache the results of this operation to a file, and update the file if the file is older than 12 hours.<br />
<br />
There are many, many other security and PHP best-practices. These are just the basics.<br />
<br />
==SSH==<br />
===Shells===<br />
* Shell access is not enabled on eclipse.org accounts by default. Build/Release engineers may request a shell on build.eclipse.org by using the [http://portal.eclipse.org/ Portal].<br />
* Shell usage on build.eclipse.org is monitored. Successful logins may be performed from trusted networks only. Access from an untrusted network will require you to confirm the network; this is done via email to your committer email account.<br />
<br />
=== Upload my public key ===<br />
<br />
Passwordless authentication (using keys) is the preferred way of logging in and using Eclipse.org servers.<br />
<br />
To upload your key from within Eclipse, simply use the '''Export to SFTP...''' button on the '''General &gt; Network Connections &gt; SSH2 &gt; Key Management''' preference page: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-ssh2-preferences.htm<br />
<br />
One can also upload the key from the command line using sftp. First, copy the public key(s) you want to upload to a single file called "authorized_keys" in the current directory, and then:<br />
<br />
<pre><br />
sftp your_username@git.eclipse.org<br />
sftp> mkdir .ssh (if .ssh subdirectory does not already exist)<br />
sftp> put authorized_keys .ssh/authorized_keys<br />
sftp> quit<br />
</pre><br />
<br />
Next, tell Eclipse to use the corresponding private key in the preference page: '''General &gt; Network Connections &gt; SSH2 &gt; General tab'''.<br />
<br />
==CVS==<br />
===Connect to Eclipse CVS?===<br />
Please see [http://dev.eclipse.org/cvshowto.html this page].<br />
<br />
===Connect to Eclipse CVS when PSERVER and/or EXTSSH are firewalled?===<br />
Please see the Proxy configuration on [[CVS Howto|this page]].<br />
<br />
===Delete files from CVS?===<br />
Although you can use SSH and a terminal to delete files in your CVS repository, we recommend you open a Bugzilla bug, in Community CVS, <br />
requesting the files that need to be deleted.<br />
<br />
===Manage UNIX groups for CVS access?===<br />
The unix groups are essentially webmaster tools used to manage commit rights to CVS <br />
repositories and to the downloads area.<br />
For each project (Eclipse-Foundation-sanctioned project, such as Eclipse Platform, DSDP-DD, Mylar, <br />
CDT, etc) we typically create three groups:<br />
<br />
* '''project-dev:''' the group of accounts that can commit to the project's code repository<br />
* '''project-home:''' the group of accounts that can commit to the project'ss website<br />
* '''projectadmin:''' those who can store files in the downloads area.<br />
<br />
For some projects, having all committers in one group with commit rights across the entire <br />
project is not adequate when some committers must be limited to a specific set of modules. <br />
In these cases, we create project-module groups that allow specific committers to only <br />
commit to that portion of CVS.<br />
<br />
==Bugzilla==<br />
===Create a new Component/Version/Milestone/Target?===<br />
[http://wiki.eclipse.org/index.php/Webmaster_FAQ#I_need_to_add.2Fremove.change_a_version.2Fmilestone.2Fcomponent_in_Bugzilla._How_do_I_do_this.3F Please see the documentation here]<br />
<br />
==Downloads==<br />
=== Upload files to the download server? ===<br />
<br />
Downloadable files must be placed in the downloads area (~/downloads, or /home/data/httpd/download.eclipse.org) so they can be mirrored to our mirror sites worldwide. '''Please ensure only pertinent, current files are in the downloads area''', as we cannot store an eternity of nightly, integration and stable builds. Production releases can be kept forever; however, we ask that you move archived releases to archive.eclipse.org (see below). <br />
<br />
To upload your files: <br />
<br />
*use an SFTP or SCP client (in SFTP mode) and connect to build.eclipse.org using your committer account <br />
*upload files to your project's directory in the downloads area (typically ~/downloads/toplevel/yourproject). Ask your project lead. <br />
*'''Please ensure that the file permissions include world-readable (664; rw-rw-r--) and directory permissions allow for world-executable (775, rwxrwxr-x).''' <br />
*large projects with frequent builds may find it more convenient to use RSYNC over SSH. <br />
*'''do not link directly to download.eclipse.org/yourfile.zip'''! Instead, use the Find a Mirror script (info below). Using this script allows you to view download statistics and allows users to pick a nearby mirror site for their download.<br />
<br />
Once your files are on the download.eclipse.org server, they are immediately available to the general public. However, for release builds, we ask that you wait at least four hours for our mirror sites to fetch the new files before linking to them. It typically takes a day or two for all the mirror sites to synchronize with us and get new files. <br />
<br />
Please note that although we tolerate PHP, HTML and JPG/GIF files on download.eclipse.org, we encourage you to put such files on www.eclipse.org. Those files are not mirrored to public mirror servers.<br />
<br />
===Move files to archive.eclipse.org?===<br />
<br />
Because our mirror sites don't have as much disk space for Eclipse files as we do, we have created an http://archive.eclipse.org site for you to<br />
store older release builds.<br />
<br />
The archive.eclipse.org structure is similar to that of download.eclipse.org. To move your files, we recommend using the SSH prompt as below. If you are not comfortable with the SSH prompt, you can ask WebMaster to move the files for you. You will need a shell account on build.eclipse.org. If you do not have one, please ask webmaster.<br />
<br />
ssh yourcommitterid@build.eclipse.org<br />
mv ~/downloads/your/project/oldrelease/ /home/data/httpd/archive.eclipse.org/your/project/oldrelease/<br />
<br />
'''Note''': if you preserve the exact path and filename from download.eclipse.org to archive.eclipse.org, you don't need to change your links if your links use the Find a Mirror script.<br />
<br />
This link will work if /path/to/a/file.zip is on download.eclipse.org, or if it gets moved to the same place on archive.eclipse.org<br />
http://www.eclipse.org/downloads/download.php?file=/path/to/a/file.zip<br />
<br />
'''P2 repositories''': P2 repositories are not normally accessed via the mirror selection script. Therefore, extra treatment is required when the move should be made transparently without affecting users who may still have the original URL. <br />
<br />
[[Equinox/p2/p2.mirrorsURL#Moving_a_repo_to_archive.eclipse.org]] has a discussion how to achieve this (''work in progress'').<br />
<br />
===Use mirror sites/see which mirrors are mirroring my files?===<br />
Link to your download files like this:<br />
<br />
http://www.eclipse.org/downloads/download.php?file=/path/to/a/file.zip<br />
<br />
'''Parameters:'''<br />
* '''file''' (Required): specify the filename, relative to the downloads home, starting with a "/". This file must exist in the downloads area. Although you can specify a directory name, your mirror list will be more accurate if you specify a file.<br />
* '''format''' (Optional): specify html (default) or xml. Useful for building the mirrors.xml for Update sites.<br />
* '''protocol''' (Optional): ftp or http: list only ftp or http mirrors only (both are the default)<br />
* '''r''' (Optional): specify 1 to automatically redirect to the best mirror (the one that would normally be at the top) without asking the user to choose.<br />
* '''nf''' (Optional): specify 1 to get an actual 404 Not Found error if the file doesn't exist (instead of a lovely page saying so).<br />
<br />
The script will examine the Last Modified timestamp of the given file and return only those mirrors that have synchronized with Eclipse.org after that time.<br />
<br />
Examples:<br />
All mirrors of the Lepido project, in XML format:<br />
http://www.eclipse.org/downloads/download.php?file=/technology/lepido/M1/content.jar&amp;format=xml<br />
<br />
Get a file from a random mirror, without prompting<br />
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.1-200506271435/eclipse-SDK-3.1-win32.zip&amp;r=1<br />
<br />
<br />
'''PLEASE NOTE:''' We have a list of excluded file patterns -- files that are *not* sent to our mirrors. <br />
Nightly and Integration builds are typically very large and don't get many downloads, <br />
therefore it's typically more costly (in terms of bandwidth) to mirror them than to support the few client downloads they generate.<br />
At time of writing, our exclusion list is: <br />
*.nfs*<br />
* apitools/<br />
* apidocs/<br />
* archive/<br />
* archives/<br />
* /athena<br />
* builds/N*<br />
* drops/I*<br />
* drops/N*<br />
* drops/M*<br />
* *.jpg<br />
* *.gif<br />
* callisto/*<br />
* compilelogs/<br />
* eclipse.org-common/<br />
* eclipse/testUpdates*<br />
* eclipse/updates/3.2milestones<br />
* /eclipse/updates/3.6-I-builds/<br />
* dev/TPTP*<br />
* /tools/cdt/builds<br />
* modeling/gmf/downloads/drops/B*<br />
* *drops/*/N*<br />
* *drops/*/I*<br />
* *javadoc/<br />
* *javadocs/<br />
* linuxtools/N*<br />
* *nightly*<br />
* *Nightly*<br />
* *staging*<br />
* /webtools/downloads/drops/*/M*<br />
* performance/<br />
* /releases/staging<br />
* /releases/europa<br />
* testresults/<br />
* /rt/eclipselink/nightly*<br />
* /technology/babel/update-site*<br />
* /technology/cosmos<br />
* /technology/ohf<br />
* /technology/tigerstripe<br />
* testcompilelogs/<br />
* testResults/<br />
* /tools/downloads<br />
* /tools/orbit/committers<br />
* */N201*<br />
* */I201*<br />
* */I.I201*<br />
* */I-*<br />
* */N-*<br />
* *integration*/<br />
* xref/<br />
* */M20*<br />
* /rt/eclipselink/maven.repo*<br />
<br />
===Use the Find a Mirror script?===<br />
See the section above.<br />
<br />
===Enable mirrors / use mirrorsURL for my p2 repo?===<br />
<br />
Your artifacts.xml (jar) should have a p2.mirrorsURL property. Here is a an example from http://download.eclipse.org/eclipse/updates/3.6/R-3.6.2-201102101200/artifacts.jar<br />
<br />
<repository name='&quot;Eclipse Project Test Site&quot;' type='org.eclipse.equinox.p2.artifact.repository.simpleRepository' version='1'><br />
<properties size='4'><br />
<property name='p2.compressed' value='true'/><br />
<property name='p2.timestamp' value='1297373227427'/><br />
<property name='publishPackFilesAsSiblings' value='true'/><br />
<property name='p2.mirrorsURL' value='http://www.eclipse.org/downloads/download.php?file=/eclipse/updates/3.6/R-3.6.2-201102101200&amp;format=xml'/><br />
</properties><br />
<br />
A more detailed description can be found at [[Equinox/p2/p2.mirrorsURL]]. <br />
<br />
Ideally, everyone, for all p2 repositories, should use this property, since even if not mirrored currently, it does not hurt anything in that case, and you never know when your repository might become mirrored. In fact, failure to use this property can result in too many requests for jar files coming directly to 'download.eclipse.org' and greatly slow down the network and use too much bandwidth. If this happens for your project (or repository) measures may be taken to automatically redirect all such requests somewhere else, which often does not work well; for examples, see {{bug|368826}}.<br />
<br />
===Include a p2.index file at p2 repository site?===<br />
<br />
A little documented aide to p2 is to include a special file named "p2.index" at your p2 repository URL site. Every well-behaved, well-optimized p2 repository should have one. This is especially important for composite repository sites as it can save several unsuccessful round trips to download server looking for files that do not exist. For "how to" instructions, see the [[Equinox/p2/p2_index| p2 wiki]]. For history and deeper technical discussion, see {{bug|347448}}.<br />
<br />
===See download statistics?===<br />
The Find a Mirror script tracks download requests once the user has picked a mirror site (or the main Eclipse download site). You can also view download stats for files downloaded via p2 if you [[Equinox p2 download stats|enable your p2 repository for download statistics]]. To view these statistics, use the Live Download Statistics tool (Portal > Project Committer > Tools for all Committers).<br />
<br />
For more information, please see the [[Project Download Stats]] page.<br />
<br />
===View my disk space quota?===<br />
Because the downloads content is mirrored worldwide, Eclipse.org imposes disk space quotas to not overburden our mirror sites. There are no quotas on mail, CVS or www.eclipse.org website content. New projects are configured with quotas. If this is insufficient, we can increase the quota to suit your needs. However, before increasing a quota, we will make sure that your downloads area doesn't contain old or stale files. We appreciate you keeping the downloads areas as lean and clean as possible. <br />
<br />
You can view your project's download.eclipse.org disk usage and quota by logging into the [http://portal.eclipse.org Portal] > [tools] for all Committers > Disk space and quotas.<br />
<br />
===Increase my disk space quota?===<br />
Before requesting your quota be increased, please delete any old files that are no longer required, and move older release builds<br />
to archive.eclipse.org (instructions above). If you are confident that your download.eclipse.org footprint is as small as it can be<br />
and that you're still running out of space, simply send an e-mail to the WebMaster with your request, stating which project you're on.<br />
<br />
===Sign my plugins/ZIP files?===<br />
The Eclipse Foundation allows committers to sign JAR and ZIP files on its behalf. Signing is done from any of the Hudson servers, or on build.eclipse.org. There are two ways to sign:<br />
<br />
==== ZIP and JAR files from the Commandline (Queued) ====<br />
From the command line (or from a script) invoke the following command:<br />
sign <file> <mail|nomail|now> [outputDir] [skiprepack]<br />
<br />
* <file> refers to the name of the file, which '''must be located in the staging area''' (download-staging.priv)<br />
* <mail|nomail|now> either queues up the files for signing and sends email to confirm signing is complete, or signs the file immediately, returning control to the caller once signing is complete<br />
* [outputDir] is an optional directory where the signed files should be placed, leaving the originals intact<br />
* [skiprepack] optionally does not pack/process JAR files<br />
:: Important note: pack/process (aka conditioning, aka repack) is still required '''before''' signing if pack200 will be used on the Java jars at any time in the future. This option to the signing service provides the opportunity to use build systems that already do the conditioning to not to have to also re-do it again, automatically, as part of the signing process (which is wasteful at best, and in theory could cause odd, rare problems). That is, using <code>skiprepack</code> leaves the responsibility entirely to the user of the signing service to do the conditioning themselves, before submitting for signing.<br />
<br />
==== Web service (Instant) ====<br />
Using a web POST method, individual JAR files can be signed from any of the internal Hudson servers (or from build.eclipse.org) with this service:<br />
<br />
http://build.eclipse.org:31338/sign<br />
<br />
The output of that service will be the signed file. '''Please note''' that it is not appropriate to submit a ZIP file of jars to the web service. Use the queued method instead. Also note that the web service does not pack or process jar files. You must condition/pack them yourself '''prior''' to signing if you wish to do so.<br />
<br />
# JAR FILES: Submit unsigned-jar.jar and save signed output to signedfile.jar<br />
curl -o signedfile.jar -F filedata=@unsigned-jar.jar http://build.eclipse.org:31338/sign<br />
<br />
# WINDOWS EXE: Submit Windows unsigned.exe and save signed output to signed.exe<br />
curl -o signed.exe -F filedata=@unsigned.exe http://build.eclipse.org:31338/winsign.php<br />
<br />
# MAC: Submit unsigned and save signed output to signed.zip<br />
# Note: You must zip your entire *.app directory for example: zip -r unsigned.zip Eclipse.app<br />
curl -o signed.zip -F filedata=@unsigned.zip http://build.eclipse.org:31338/macsign.php<br />
<br />
==Builds==<br />
<br />
===Access/use the Eclipse Build Server?===<br />
[[Image:Build_infra_layout.png|thumb|Build and Hudson storage layout]]<br />
<br />
Although we strongly encourage the use of [http://hudson.eclipse.org Hudson] for builds, committers can use the build.eclipse.org server to run builds and tests for their project. <br />
Unlike the other eclipse.org servers, committers are permitted to run software on this server, <br />
and to maintain running software in the background. If you need to run cron jobs, please contact <br />
the webmaster, stating the time and frequency at which these jobs are to run, and for how long <br />
they typically run.<br />
'''Server details:'''<br />
* host: build.eclipse.org<br />
* username: use your committer account<br />
*server: Intel Dual-Quad Xeon E5540 @ 2.53GHz, 24G RAM<br />
* architecture: x86_64<br />
<br />
You can use an SSH client to connect to the server. For more information on SSH, please see the SSH section of this document.<br />
<br />
Here are some directories that are of interest:<br />
* '''/cvsroot''', '''/svnroot''', '''/gitroot''' -> the code repositories, connected to eclipse.org via a Gigabit connection. Your Build account cannot write to these files directly<br />
* '''/home/data/httpd/download.eclipse.org''' -> the download.eclipse.org root, connected to eclipse.org via Gigabit connection.<br />
* '''/shared''' -> a shared disk to store your build files and applications. Please note, however, that we do not maintain backups of this directory. This path is structured like the downloads area, and is accessible via http://build.eclipse.org/ (That URL redirects to the Eclipse homepage, but browsing to a specific project URL will work: http://build.eclipse.org/technology/, http://build.eclipse.org/tools/ etc.)<br />
* '''/shared/common''' -> a common location to store applications. Ant and various JDKs are located there.<br />
<br />
If you have any questions, please contact the webmaster.<br />
<br />
===Access/request Hudson services===<br />
<br />
Please see the [[Hudson]] document.<br />
<br />
== Code Quality Analysis == <br />
<br />
* [[FindBugs]]<br />
* [[Sonar]]<br />
* JDT :), please consider enabling [http://help.eclipse.org/topic/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ref-preferences-errors-warnings.htm?cp=1_4_2_0_3_1 compiler warnings] beyond the defaults. The JDT help also contains a start of a section on [http://help.eclipse.org/topic/org.eclipse.jdt.doc.user/tasks/task-improve_code_quality.htm?cp=1_3_9 improving code quality].<br />
<br />
==Mailing Lists==<br />
<br />
===Setup a new mailing list?===<br />
Because Mailing Lists are subject to SPAM and can adversely affect eclipse.org performance (imaging sending 200 e-mails to a list that contains 3000 members), proper care<br />
is taken in configuring each list. New mailing lists are set up by the WebMaster for this reason. Also, the webmaster creates an HTML view (called mailing list archives) of mailing list postings for<br />
archive and search purposes.<br />
<br />
===View list members?===<br />
Because mailing lists contain private information, such as a member's e-mail address, name and surname, we cannot publicly display this information. However,<br />
the PMC or Project Lead can become the list administrator, which would allow you to view the membership information for<br />
your lists. The PMC/Project lead can inquire about list administration to the WebMaster, stating which lists they would like to manage.<br />
<br />
<br />
==Eclipse Wiki==<br />
<br />
===Create a new page in the Eclipse Wiki===<br />
To create a new page, simply type the page name at the end of "/" in the URL. The name can contain spaces. For instance,<br />
http://wiki.eclipse.org/Some_Page will allow you to create and edit this new page.<br />
<br />
==Eclipse Servers==<br />
<br />
Eclipse Foundation [[IT SLA]]<br />
<br />
When you become committer, your default shell allows only CVS and SVN commands. <br />
If you need a 'real' shell for dealing with distribution files or working with automated builds, you'll need to have your project lead or the project PMC file a bug requesting the upgrade.<br />
<br />
<br />
''This page is moderated by the EMO''<br />
[[Category:Development_Resources]]<br />
[[Category:How to Contribute]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=340258LTS/HowTos2013-06-18T14:45:02Z<p>Thanh.ha.eclipse.org: /* Getting notifications */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
Gerrit supports email notifications which you can register as a user for projects your interested in being notified about when a new review comes in. To subscribe to project notifications follow these steps:<br />
<br />
# Click '''Settings'''<br />
# Click '''Watched Projects'''<br />
# Enter a project to watch and click '''Watch'''<br />
<br />
<br />
Gerrit also supports project level notifications which requires more configuration but is described in this document: <br />
https://git.eclipse.org/r/Documentation/user-notify.html<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=340257LTS/HowTos2013-06-18T14:44:20Z<p>Thanh.ha.eclipse.org: /* Getting notifications */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
Gerrit supports email notifications which you can register as a user for projects your interested in being notified about when a new review comes in. To subscribe to project notifications follow these steps:<br />
<br />
# Click '''Settings'''<br />
# Click '''Watched Projects'''<br />
# Enter a project to watch and click '''Watch'''<br />
<br />
<br />
Gerrit also supports project level notifications which is described in this document: <br />
https://git.eclipse.org/r/Documentation/user-notify.html<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=340256LTS/HowTos2013-06-18T14:44:05Z<p>Thanh.ha.eclipse.org: /* Getting notifications */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
Gerrit supports email notifications which you can register as a user for projects your interested in being notified about when a new review comes in. To subscribe to project notifications follow these steps:<br />
<br />
# Click '''Settings'''<br />
# Click '''Watched Projects'''<br />
# Enter a project to watch and click '''Watch'''<br />
<br />
<br />
Gerrit also supports project level notifications which is described in this document: <br />
https://git.eclipse.org/r/Documentation/user-notify.html<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=340255LTS/HowTos2013-06-18T14:43:53Z<p>Thanh.ha.eclipse.org: /* Getting notifications */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
Gerrit supports email notifications which you can register as a user for projects your interested in being notified about when a new review comes in. To subscribe to project notifications follow these steps:<br />
<br />
1. Click '''Settings'''<br />
<br />
2. Click '''Watched Projects'''<br />
<br />
3. Enter a project to watch and click '''Watch'''<br />
<br />
<br />
Gerrit also supports project level notifications which is described in this document: <br />
https://git.eclipse.org/r/Documentation/user-notify.html<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=340254LTS/HowTos2013-06-18T14:43:37Z<p>Thanh.ha.eclipse.org: /* Getting notifications */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
Gerrit supports email notifications which you can register as a user for projects your interested in being notified about when a new review comes in. To subscribe to project notifications follow these steps:<br />
<br />
1. Click '''Settings'''<br />
2. Click '''Watched Projects'''<br />
3. Enter a project to watch and click '''Watch'''<br />
<br />
<br />
Gerrit also supports project level notifications which is described in this document: <br />
https://git.eclipse.org/r/Documentation/user-notify.html<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=340252LTS/HowTos2013-06-18T14:39:22Z<p>Thanh.ha.eclipse.org: /* Reviewing a patch / code review */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
== Getting notifications ==<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=Services/Nexus&diff=336982Services/Nexus2013-05-21T13:16:08Z<p>Thanh.ha.eclipse.org: /* Deploying artifacts to repo.eclipse.org */</p>
<hr />
<div>== Eclipse Nexus Instance ==<br />
<br />
The Eclipse Nexus instance is hosted at: https://repo.eclipse.org<br />
<br />
This repository allows Eclipse projects to publish their build artifacts into a centralized repository hosted by EMO.<br />
<br />
Notes:<br />
<br />
* Snapshots older than 30-days are automatically removed on a weekly basis<br />
<br />
<br />
=== Getting a Nexus repo for your Project ===<br />
<br />
Simply file a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Nexus Bug] and specify what project you'd like a Nexus repo for.<br />
<br />
== Pulling artifacts from Nexus ==<br />
<br />
To use repo.eclipse.org to pull artifacts for your project there are a few URLs that can be used.<br />
<br />
=== Releases Group ===<br />
https://repo.eclipse.org/content/repositories/releases/<br />
<br />
This URL is a top-level aggregate of all project releases repositories. This URL is recommended if you just want to pull in releases from any project hosting artifacts on repo.eclipse.org<br />
<br />
=== Snapshots Group ===<br />
https://repo.eclipse.org/content/repositories/snapshots/<br />
<br />
This URL is a top-level aggregate of all project snapshots repositories. This URL is useful for developers who want to pull in artifacts that may have not yet been released usually nightlies.<br />
<br />
=== Project Specific Repos ===<br />
<br />
Finally you can also use a project specific repo if you only want to ensure you are only pulling artifacts from specific projects. To get the URLs for these projects you can navigate to https://repo.eclipse.org/index.html#view-repositories and browse for the URL link for the specific project.<br />
<br />
<br />
== Deploying artifacts to repo.eclipse.org ==<br />
<br />
To deploy artifacts to repo.eclipse.org you will need to use Hudson (http://hudson.eclipse.org) to configure a job for deploying your artifacts.<br />
<br />
It is recommended that you use '''JDK 7''' or higher as we have seen SSL Handshake issues when using JDK 6.<br />
<br />
=== Initial Maven POM setup ===<br />
<br />
Before Hudson can deploy your project's artifacts to Nexus you will need to do some setup on the Maven side to add a [http://maven.apache.org/pom.html#Distribution_Management "distributionManagement"] section to your project pom. An example below:<br />
<br />
<pre><br />
<distributionManagement><br />
<repository><br />
<id>repo.eclipse.org</id><br />
<name>Project Repository - Releases</name><br />
<url>https://repo.eclipse.org/content/repositories/project-releases/</url><br />
</repository><br />
<snapshotRepository><br />
<id>repo.eclipse.org</id><br />
<name>Project Repository - Snapshots</name><br />
<url>https://repo.eclipse.org/content/repositories/project-snapshots/</url><br />
</snapshotRepository><br />
</distributionManagement><br />
</pre><br />
<br />
Replace instances of the word "project" with your project's name.<br />
<br />
Note: It is important to ensure your ID's are "repo.eclipse.org" as the Hudson instance is configured to use these IDs.<br />
<br />
If you want to keep several snapshot versions use:<br />
<pre><br />
<snapshotRepository><br />
<uniqueVersion>true</uniqueVersion><br />
...<br />
</pre><br />
<br />
=== Hudson Job Setup ===<br />
<br />
Using http://hudson.eclipse.org you will need to configure Maven to run the "deploy" goal.<br />
<br />
There are 2 ways you might want to do this:<br />
<br />
# Simply add the "deploy" goal as one of your Maven goals as part of your build<br />
# Create separate jobs, one for building and one for deploying (if you want more control over when to deploy)<br />
<br />
<br />
If you decided to go with creating separate jobs, your deploy job will need access to your build job's workspace, an easy way of making this work is to configure the build job, and the deploy job with the optional '''Use custom workspace''' configuration under '''Advanced project options'''.<br />
<br />
Example:<br />
<br />
[[Image:custom_workspace.jpg]]<br />
<br />
Replace '''<your build job project name>''' with the name of your project job, for example if your build job was named '''''cbi-maven-plugins-build''''' then your Directory should be '''''/opt/public/jobs/cbi-maven-plugins-build/workspace'''''. This setting should be configured in both your Build job and Deploy jobs.<br />
<br />
<br />
Finally your deploy job should invoke an instance of Maven 3 with the "deploy" goal. The only additional option you need to ensure that's configured is to click '''Advanced''' and configure the '''Settings''' option and set it to '''Deploy to repo.eclipse.org'''. This custom settings file contains the necessary credentials in order for you to deploy to repo.eclipse.org.<br />
<br />
[[Image:deploy_settings.jpg]]<br />
<br />
== Deploying a jar to repo.eclipse.org ==<br />
<br />
It is possible to use the Maven '''deploy:deploy-file''' goal to push a jar file into repo.eclipse.org via hudson.eclipse.org. For every jar you wish to push into repo.eclipse.org an associating pom.xml file is necessary.<br />
<br />
The simplest pom.xml can be as follows:<br />
<br />
<pre><br />
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><br />
<modelVersion>4.0.0</modelVersion><br />
<groupId>org.eclipse.jdt</groupId><br />
<artifactId>org.eclipse.jdt.core</artifactId><br />
<version>3.9.0.v20130313-2254</version><br />
</project><br />
</pre><br />
<br />
hudson.eclipse.org has access to the same /shared as build.eclipse.org so placing your files somewhere there will allow hudson to be able to find it.<br />
<br />
=== Configuring Hudson for mvn deploy:deploy-file ===<br />
<br />
There are 3 settings which need to be configured:<br />
<br />
# Goals: deploy:deploy-file<br />
# Properties:<br />
#:<pre><br />
#::groupId=<groupId><br />
#::artifactId=<artifactId><br />
#::version=<version><br />
#::packaging=jar<br />
#::file=/shared/path/to/file.jar<br />
#::repositoryId=repo.eclipse.org<br />
#::url=<Your project's repo URL to push jar into><br />
#:</pre><br />
# POM File: /path/to/pom.xml<br />
<br />
For example:<br />
[[Image:mvn-deploy-file.png]]<br />
<br />
<br />
Note: You will also need to configure your settings file to use '''Deploy to repo.eclipse.org''' per instructions in the previous section for deploying artifacts.</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=IT_Infrastructure_Doc&diff=336495IT Infrastructure Doc2013-05-14T20:55:24Z<p>Thanh.ha.eclipse.org: /* Web service (Instant) */</p>
<hr />
<div><span style="font-size: 90%">< [[Development Resources]]</span><br />
<br />
==Website==<br />
===How do I setup my project website?===<br />
{{Important |Git migration in progress|See {{Bug|359737}} or [http://waynebeaton.wordpress.com/2012/08/28/migrating-eclipse-project-websites-to-git/ this blog post] for more information.}}<br />
<br />
Project websites are hosted in a CVS repository separate from the actual project code. The repository path is dev.eclipse.org:/cvsroot/org.eclipse, in the www component.<br />
Once the webmaster<br />
adds a space for your project, files you commit to the website CVS are automatically checked out to www.eclipse.org/xyz, where <br />
xyz is your project's short name.<br />
You are free to use HTML and PHP on your website.<br />
<br >Hosting a project website is normally done when the project proposal has been approved.<br />
If you suspect your files are not being checked out to the www.eclipse.org website, simply commit a small change to one file. This is usually<br />
enough to trigger a website refresh.<br />
<br />
===How do I author web pages using the Phoenix method?===<br />
Please see <a href=phoenix.php> this document</a> for information on using Phoenix.<br />
You can also check out: [[Using Phoenix]] and [http://www.eclipse.org/phoenix/docs/sample_pages.php Sample Pages]<br />
<br />
===Access the Bugzilla database using PHP?===<br />
Please see the section labeled "[tools]" in the [http://portal.eclipse.org|MyFoundation Portal]<br />
<br />
===Use a database for my website?===<br />
We currently do not offer projects with database support.<br />
<br />
===I need to put a large file on my website. How should I do this?===<br />
Large (1 MB+) ZIP and JAR files must be put in the downloads area, using the Find A Mirror script to link to them.<br />
However, small files (less than 1 MB) can be put on the www.eclipse.org/yourproject website directly without causing too much harm.<br />
<br />
The Find A Mirror script supports transparent mirror use, so large screencasts and PDFs can be put in the downloads area as well without imposing the added step of selecting<br />
a mirror site for the file. Simply add &amp;r=1 to the URL. For instance, http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.1-200506271435/eclipse-SDK-3.1-linux-gtk.tar.gz&amp;r=1 will fetch you the <br />
Eclipse SDK 3.1 for Linux from a random mirror site without asking you which one.<br />
<br />
Remember to allow our mirrors at least 24 hours to sync up before using a transparent mirror redirect. <br />
<br />
===Use PHP on my website?===<br />
PHP support is available on www.eclipse.org only. Simply commit files with the .php file extension to your website's CVS repository.<br />
Although some projects host PHP files on download.eclipse.org, we do not encourage or recommend it.<br />
<br />
Eclipse.org is a high-traffic website. Please make sure your PHP code is optimized to run in this type of environment. See the next item. <br />
<br />
===Optimize my PHP code for large-scale use?===<br />
Eclipse.org is a high-traffic website. To improve PHP's functionality, we have set very liberal limits on how many resources<br />
PHP can consume. However. if if your project is very popular, bad PHP code can slow the entire site down.<br />
<br />
Of course, we could harden PHP to protect our website, but that would cut some functionality. Some tips for you:<br />
<br />
* '''Never call the web service to include/open files''' - include("http://www.eclipse.org/somefile.html") and fopen("http://localhost/somefile.xml") are very costly to run, because they call the web service, and can lead to eclipse.org Denial-Of-Servicing itself under heavy load.<br />
* '''Never include/open remote files''' - include("http://www.someothersite.org/somefile.html") is forbidden, as someone could launch a Denial-Of-Service attack against a remote site. We don't allow you to establish remote connections from eclipse.org servers other than the build server.<br />
* '''Sanitize your incoming parameters''' - include($parameter) is particularly dangerous if $parameter is not sanitized. Someone could freely surf the web anonymously, hiding behind eclipse.org servers, or they could use your page to access local files, or launch Denial-Of-Service attacks against remote servers. <br />
* '''Cache aggregated, processor-intensive data''' - SQL aggregations, file system scans, Bugzilla lists can (and should) be cached to avoid redundant processor- and disk-intensive operations. For instance, scanning through download.eclipse.org directories to display the size of a build could be useful, but doesn't need to happen for each website visitor. Cache the results of this operation to a file, and update the file if the file is older than 12 hours.<br />
<br />
There are many, many other security and PHP best-practices. These are just the basics.<br />
<br />
==SSH==<br />
===Shells===<br />
* Shell access is not enabled on eclipse.org accounts by default. Build/Release engineers may request a shell on build.eclipse.org by using the [http://portal.eclipse.org/ Portal].<br />
* Shell usage on build.eclipse.org is monitored. Successful logins may be performed from trusted networks only. Access from an untrusted network will require you to confirm the network; this is done via email to your committer email account.<br />
<br />
=== Upload my public key ===<br />
<br />
Passwordless authentication (using keys) is the preferred way of logging in and using Eclipse.org servers.<br />
<br />
To upload your key from within Eclipse, simply use the '''Export to SFTP...''' button on the '''General &gt; Network Connections &gt; SSH2 &gt; Key Management''' preference page: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-ssh2-preferences.htm<br />
<br />
One can also upload the key from the command line using sftp. First, copy the public key(s) you want to upload to a single file called "authorized_keys" in the current directory, and then:<br />
<br />
<pre><br />
sftp your_username@git.eclipse.org<br />
sftp> mkdir .ssh (if .ssh subdirectory does not already exist)<br />
sftp> put authorized_keys .ssh/authorized_keys<br />
sftp> quit<br />
</pre><br />
<br />
Next, tell Eclipse to use the corresponding private key in the preference page: '''General &gt; Network Connections &gt; SSH2 &gt; General tab'''.<br />
<br />
==CVS==<br />
===Connect to Eclipse CVS?===<br />
Please see [http://dev.eclipse.org/cvshowto.html this page].<br />
<br />
===Connect to Eclipse CVS when PSERVER and/or EXTSSH are firewalled?===<br />
Please see the Proxy configuration on [[CVS Howto|this page]].<br />
<br />
===Delete files from CVS?===<br />
Although you can use SSH and a terminal to delete files in your CVS repository, we recommend you open a Bugzilla bug, in Community CVS, <br />
requesting the files that need to be deleted.<br />
<br />
===Manage UNIX groups for CVS access?===<br />
The unix groups are essentially webmaster tools used to manage commit rights to CVS <br />
repositories and to the downloads area.<br />
For each project (Eclipse-Foundation-sanctioned project, such as Eclipse Platform, DSDP-DD, Mylar, <br />
CDT, etc) we typically create three groups:<br />
<br />
* '''project-dev:''' the group of accounts that can commit to the project's code repository<br />
* '''project-home:''' the group of accounts that can commit to the project'ss website<br />
* '''projectadmin:''' those who can store files in the downloads area.<br />
<br />
For some projects, having all committers in one group with commit rights across the entire <br />
project is not adequate when some committers must be limited to a specific set of modules. <br />
In these cases, we create project-module groups that allow specific committers to only <br />
commit to that portion of CVS.<br />
<br />
==Bugzilla==<br />
===Create a new Component/Version/Milestone/Target?===<br />
[http://wiki.eclipse.org/index.php/Webmaster_FAQ#I_need_to_add.2Fremove.change_a_version.2Fmilestone.2Fcomponent_in_Bugzilla._How_do_I_do_this.3F Please see the documentation here]<br />
<br />
==Downloads==<br />
=== Upload files to the download server? ===<br />
<br />
Downloadable files must be placed in the downloads area (~/downloads, or /home/data/httpd/download.eclipse.org) so they can be mirrored to our mirror sites worldwide. '''Please ensure only pertinent, current files are in the downloads area''', as we cannot store an eternity of nightly, integration and stable builds. Production releases can be kept forever; however, we ask that you move archived releases to archive.eclipse.org (see below). <br />
<br />
To upload your files: <br />
<br />
*use an SFTP or SCP client (in SFTP mode) and connect to build.eclipse.org using your committer account <br />
*upload files to your project's directory in the downloads area (typically ~/downloads/toplevel/yourproject). Ask your project lead. <br />
*'''Please ensure that the file permissions include world-readable (664; rw-rw-r--) and directory permissions allow for world-executable (775, rwxrwxr-x).''' <br />
*large projects with frequent builds may find it more convenient to use RSYNC over SSH. <br />
*'''do not link directly to download.eclipse.org/yourfile.zip'''! Instead, use the Find a Mirror script (info below). Using this script allows you to view download statistics and allows users to pick a nearby mirror site for their download.<br />
<br />
Once your files are on the download.eclipse.org server, they are immediately available to the general public. However, for release builds, we ask that you wait at least four hours for our mirror sites to fetch the new files before linking to them. It typically takes a day or two for all the mirror sites to synchronize with us and get new files. <br />
<br />
Please note that although we tolerate PHP, HTML and JPG/GIF files on download.eclipse.org, we encourage you to put such files on www.eclipse.org. Those files are not mirrored to public mirror servers.<br />
<br />
===Move files to archive.eclipse.org?===<br />
<br />
Because our mirror sites don't have as much disk space for Eclipse files as we do, we have created an http://archive.eclipse.org site for you to<br />
store older release builds.<br />
<br />
The archive.eclipse.org structure is similar to that of download.eclipse.org. To move your files, we recommend using the SSH prompt as below. If you are not comfortable with the SSH prompt, you can ask WebMaster to move the files for you. You will need a shell account on build.eclipse.org. If you do not have one, please ask webmaster.<br />
<br />
ssh yourcommitterid@build.eclipse.org<br />
mv ~/downloads/your/project/oldrelease/ /home/data/httpd/archive.eclipse.org/your/project/oldrelease/<br />
<br />
'''Note''': if you preserve the exact path and filename from download.eclipse.org to archive.eclipse.org, you don't need to change your links if your links use the Find a Mirror script.<br />
<br />
This link will work if /path/to/a/file.zip is on download.eclipse.org, or if it gets moved to the same place on archive.eclipse.org<br />
http://www.eclipse.org/downloads/download.php?file=/path/to/a/file.zip<br />
<br />
'''P2 repositories''': P2 repositories are not normally accessed via the mirror selection script. Therefore, extra treatment is required when the move should be made transparently without affecting users who may still have the original URL. <br />
<br />
[[Equinox/p2/p2.mirrorsURL#Moving_a_repo_to_archive.eclipse.org]] has a discussion how to achieve this (''work in progress'').<br />
<br />
===Use mirror sites/see which mirrors are mirroring my files?===<br />
Link to your download files like this:<br />
<br />
http://www.eclipse.org/downloads/download.php?file=/path/to/a/file.zip<br />
<br />
'''Parameters:'''<br />
* '''file''' (Required): specify the filename, relative to the downloads home, starting with a "/". This file must exist in the downloads area. Although you can specify a directory name, your mirror list will be more accurate if you specify a file.<br />
* '''format''' (Optional): specify html (default) or xml. Useful for building the mirrors.xml for Update sites.<br />
* '''protocol''' (Optional): ftp or http: list only ftp or http mirrors only (both are the default)<br />
* '''r''' (Optional): specify 1 to automatically redirect to the best mirror (the one that would normally be at the top) without asking the user to choose.<br />
* '''nf''' (Optional): specify 1 to get an actual 404 Not Found error if the file doesn't exist (instead of a lovely page saying so).<br />
<br />
The script will examine the Last Modified timestamp of the given file and return only those mirrors that have synchronized with Eclipse.org after that time.<br />
<br />
Examples:<br />
All mirrors of the Lepido project, in XML format:<br />
http://www.eclipse.org/downloads/download.php?file=/technology/lepido/M1/content.jar&amp;format=xml<br />
<br />
Get a file from a random mirror, without prompting<br />
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.1-200506271435/eclipse-SDK-3.1-win32.zip&amp;r=1<br />
<br />
<br />
'''PLEASE NOTE:''' We have a list of excluded file patterns -- files that are *not* sent to our mirrors. <br />
Nightly and Integration builds are typically very large and don't get many downloads, <br />
therefore it's typically more costly (in terms of bandwidth) to mirror them than to support the few client downloads they generate.<br />
At time of writing, our exclusion list is: <br />
*.nfs*<br />
* apitools/<br />
* apidocs/<br />
* archive/<br />
* archives/<br />
* /athena<br />
* builds/N*<br />
* drops/I*<br />
* drops/N*<br />
* drops/M*<br />
* *.jpg<br />
* *.gif<br />
* callisto/*<br />
* compilelogs/<br />
* eclipse.org-common/<br />
* eclipse/testUpdates*<br />
* eclipse/updates/3.2milestones<br />
* /eclipse/updates/3.6-I-builds/<br />
* dev/TPTP*<br />
* /tools/cdt/builds<br />
* modeling/gmf/downloads/drops/B*<br />
* *drops/*/N*<br />
* *drops/*/I*<br />
* *javadoc/<br />
* *javadocs/<br />
* linuxtools/N*<br />
* *nightly*<br />
* *Nightly*<br />
* *staging*<br />
* /webtools/downloads/drops/*/M*<br />
* performance/<br />
* /releases/staging<br />
* /releases/europa<br />
* testresults/<br />
* /rt/eclipselink/nightly*<br />
* /technology/babel/update-site*<br />
* /technology/cosmos<br />
* /technology/ohf<br />
* /technology/tigerstripe<br />
* testcompilelogs/<br />
* testResults/<br />
* /tools/downloads<br />
* /tools/orbit/committers<br />
* */N201*<br />
* */I201*<br />
* */I.I201*<br />
* */I-*<br />
* */N-*<br />
* *integration*/<br />
* xref/<br />
* */M20*<br />
* /rt/eclipselink/maven.repo*<br />
<br />
===Use the Find a Mirror script?===<br />
See the section above.<br />
<br />
===Enable mirrors / use mirrorsURL for my p2 repo?===<br />
<br />
Your artifacts.xml (jar) should have a p2.mirrorsURL property. Here is a an example from http://download.eclipse.org/eclipse/updates/3.6/R-3.6.2-201102101200/artifacts.jar<br />
<br />
<repository name='&quot;Eclipse Project Test Site&quot;' type='org.eclipse.equinox.p2.artifact.repository.simpleRepository' version='1'><br />
<properties size='4'><br />
<property name='p2.compressed' value='true'/><br />
<property name='p2.timestamp' value='1297373227427'/><br />
<property name='publishPackFilesAsSiblings' value='true'/><br />
<property name='p2.mirrorsURL' value='http://www.eclipse.org/downloads/download.php?file=/eclipse/updates/3.6/R-3.6.2-201102101200&amp;format=xml'/><br />
</properties><br />
<br />
A more detailed description can be found at [[Equinox/p2/p2.mirrorsURL]]. <br />
<br />
Ideally, everyone, for all p2 repositories, should use this property, since even if not mirrored currently, it does not hurt anything in that case, and you never know when your repository might become mirrored. In fact, failure to use this property can result in too many requests for jar files coming directly to 'download.eclipse.org' and greatly slow down the network and use too much bandwidth. If this happens for your project (or repository) measures may be taken to automatically redirect all such requests somewhere else, which often does not work well; for examples, see {{bug|368826}}.<br />
<br />
===Include a p2.index file at p2 repository site?===<br />
<br />
A little documented aide to p2 is to include a special file named "p2.index" at your p2 repository URL site. Every well-behaved, well-optimized p2 repository should have one. This is especially important for composite repository sites as it can save several unsuccessful round trips to download server looking for files that do not exist. For "how to" instructions, see the [[Equinox/p2/p2_index| p2 wiki]]. For history and deeper technical discussion, see {{bug|347448}}.<br />
<br />
===See download statistics?===<br />
The Find a Mirror script tracks download requests once the user has picked a mirror site (or the main Eclipse download site). You can also view download stats for files downloaded via p2 if you [[Equinox p2 download stats|enable your p2 repository for download statistics]]. To view these statistics, use the Live Download Statistics tool (Portal > Project Committer > Tools for all Committers).<br />
<br />
For more information, please see the [[Project Download Stats]] page.<br />
<br />
===View my disk space quota?===<br />
Because the downloads content is mirrored worldwide, Eclipse.org imposes disk space quotas to not overburden our mirror sites. There are no quotas on mail, CVS or www.eclipse.org website content. New projects are configured with quotas. If this is insufficient, we can increase the quota to suit your needs. However, before increasing a quota, we will make sure that your downloads area doesn't contain old or stale files. We appreciate you keeping the downloads areas as lean and clean as possible. <br />
<br />
You can view your project's download.eclipse.org disk usage and quota by logging into the [http://portal.eclipse.org Portal] > [tools] for all Committers > Disk space and quotas.<br />
<br />
===Increase my disk space quota?===<br />
Before requesting your quota be increased, please delete any old files that are no longer required, and move older release builds<br />
to archive.eclipse.org (instructions above). If you are confident that your download.eclipse.org footprint is as small as it can be<br />
and that you're still running out of space, simply send an e-mail to the WebMaster with your request, stating which project you're on.<br />
<br />
===Sign my plugins/ZIP files?===<br />
The Eclipse Foundation allows committers to sign JAR and ZIP files on its behalf. Signing is done from any of the Hudson servers, or on build.eclipse.org. There are two ways to sign:<br />
<br />
==== ZIP and JAR files from the Commandline (Queued) ====<br />
From the command line (or from a script) invoke the following command:<br />
sign <file> <mail|nomail|now> [outputDir] [skiprepack]<br />
<br />
* <file> refers to the name of the file, which '''must be located in the staging area''' (download-staging.priv)<br />
* <mail|nomail|now> either queues up the files for signing and sends email to confirm signing is complete, or signs the file immediately, returning control to the caller once signing is complete<br />
* [outputDir] is an optional directory where the signed files should be placed, leaving the originals intact<br />
* [skiprepack] optionally does not pack/process JAR files<br />
:: Important note: pack/process (aka conditioning, aka repack) is still required '''before''' signing if pack200 will be used on the Java jars at any time in the future. This option to the signing service provides the opportunity to use build systems that already do the conditioning to not to have to also re-do it again, automatically, as part of the signing process (which is wasteful at best, and in theory could cause odd, rare problems). That is, using <code>skiprepack</code> leaves the responsibility entirely to the user of the signing service to do the conditioning themselves, before submitting for signing.<br />
<br />
==== Web service (Instant) ====<br />
Using a web POST method, individual JAR files can be signed from any of the internal Hudson servers (or from build.eclipse.org) with this service:<br />
<br />
http://build.eclipse.org:31338/sign<br />
<br />
The output of that service will be the signed file. '''Please note''' that it is not appropriate to submit a ZIP file of jars to the web service. Use the queued method instead. Also note that the web service does not pack or process jar files. You must condition/pack them yourself '''prior''' to signing if you wish to do so.<br />
<br />
# JAR FILES: Submit unsigned-jar.jar and save signed output to signedfile.jar<br />
curl -o signedfile.jar -i -F filedata=@unsigned-jar.jar http://build.eclipse.org:31338/sign<br />
<br />
# WINDOWS EXE: Submit Windows unsigned.exe and save signed output to signed.exe<br />
curl -o signed.exe -F filedata=@unsigned.exe http://build.eclipse.org:31338/winsign.php<br />
<br />
# MAC: Submit unsigned and save signed output to signed.zip<br />
# Note: You must zip your entire *.app directory for example: zip -r Eclipse.app unsigned.zip<br />
curl -o signed.zip -i -F filedata=@unsigned.zip http://build.eclipse.org:31338/macsign.php<br />
<br />
==Builds==<br />
<br />
===Access/use the Eclipse Build Server?===<br />
[[Image:Build_infra_layout.png|thumb|Build and Hudson storage layout]]<br />
<br />
Although we strongly encourage the use of [http://hudson.eclipse.org Hudson] for builds, committers can use the build.eclipse.org server to run builds and tests for their project. <br />
Unlike the other eclipse.org servers, committers are permitted to run software on this server, <br />
and to maintain running software in the background. If you need to run cron jobs, please contact <br />
the webmaster, stating the time and frequency at which these jobs are to run, and for how long <br />
they typically run.<br />
'''Server details:'''<br />
* host: build.eclipse.org<br />
* username: use your committer account<br />
*server: Intel Dual-Quad Xeon E5540 @ 2.53GHz, 24G RAM<br />
* architecture: x86_64<br />
<br />
You can use an SSH client to connect to the server. For more information on SSH, please see the SSH section of this document.<br />
<br />
Here are some directories that are of interest:<br />
* '''/cvsroot''', '''/svnroot''', '''/gitroot''' -> the code repositories, connected to eclipse.org via a Gigabit connection. Your Build account cannot write to these files directly<br />
* '''/home/data/httpd/download.eclipse.org''' -> the download.eclipse.org root, connected to eclipse.org via Gigabit connection.<br />
* '''/shared''' -> a shared disk to store your build files and applications. Please note, however, that we do not maintain backups of this directory. This path is structured like the downloads area, and is accessible via http://build.eclipse.org/ (That URL redirects to the Eclipse homepage, but browsing to a specific project URL will work: http://build.eclipse.org/technology/, http://build.eclipse.org/tools/ etc.)<br />
* '''/shared/common''' -> a common location to store applications. Ant and various JDKs are located there.<br />
<br />
If you have any questions, please contact the webmaster.<br />
<br />
===Access/request Hudson services===<br />
<br />
Please see the [[Hudson]] document.<br />
<br />
== Code Quality Analysis == <br />
<br />
* [[FindBugs]]<br />
* [[Sonar]]<br />
* JDT :), please consider enabling [http://help.eclipse.org/topic/org.eclipse.jdt.doc.user/reference/preferences/java/compiler/ref-preferences-errors-warnings.htm?cp=1_4_2_0_3_1 compiler warnings] beyond the defaults. The JDT help also contains a start of a section on [http://help.eclipse.org/topic/org.eclipse.jdt.doc.user/tasks/task-improve_code_quality.htm?cp=1_3_9 improving code quality].<br />
<br />
==Mailing Lists==<br />
<br />
===Setup a new mailing list?===<br />
Because Mailing Lists are subject to SPAM and can adversely affect eclipse.org performance (imaging sending 200 e-mails to a list that contains 3000 members), proper care<br />
is taken in configuring each list. New mailing lists are set up by the WebMaster for this reason. Also, the webmaster creates an HTML view (called mailing list archives) of mailing list postings for<br />
archive and search purposes.<br />
<br />
===View list members?===<br />
Because mailing lists contain private information, such as a member's e-mail address, name and surname, we cannot publicly display this information. However,<br />
the PMC or Project Lead can become the list administrator, which would allow you to view the membership information for<br />
your lists. The PMC/Project lead can inquire about list administration to the WebMaster, stating which lists they would like to manage.<br />
<br />
<br />
==Eclipse Wiki==<br />
<br />
===Create a new page in the Eclipse Wiki===<br />
To create a new page, simply type the page name at the end of "/" in the URL. The name can contain spaces. For instance,<br />
http://wiki.eclipse.org/Some_Page will allow you to create and edit this new page.<br />
<br />
==Eclipse Servers==<br />
<br />
Eclipse Foundation [[IT SLA]]<br />
<br />
When you become committer, your default shell allows only CVS and SVN commands. <br />
If you need a 'real' shell for dealing with distribution files or working with automated builds, you'll need to have your project lead or the project PMC file a bug requesting the upgrade.<br />
<br />
<br />
''This page is moderated by the EMO''<br />
[[Category:Development_Resources]]<br />
[[Category:How to Contribute]]</div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335746LTS/HowTos2013-05-06T19:28:13Z<p>Thanh.ha.eclipse.org: /* Setting up SSH Public Keys */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
<br />
==== Verifying SSH works ====<br />
<br />
The following command should return a list of available projects to you if your ssh settings are configured correctly.<br />
<br />
<code>ssh -p 29418 user@lts.eclipse.org gerrit ls-projects</code><br />
<br />
Replace '''user''' with your userid from Gerrit.<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335466LTS/HowTos2013-05-02T20:05:53Z<p>Thanh.ha.eclipse.org: /* Reviewing a patch / code review */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open''' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335465LTS/HowTos2013-05-02T20:05:40Z<p>Thanh.ha.eclipse.org: /* Reviewing a code change */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a patch / code review ==<br />
<br />
You can display all open code reviews by:<br />
<br />
# Clicking '''All''' from the top menu<br />
# Clicking '''Open'' from the submenu<br />
<br />
This will list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335464LTS/HowTos2013-05-02T20:04:22Z<p>Thanh.ha.eclipse.org: /* Pushing changes to Company specific branch */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
== Reviewing a code change ==<br />
<br />
Clicking '''All > Open''' at the top menu will display a list of all open code reviews that need reviewing. Selecting a specific review will open up a screen displaying the contents of the patch submitted and allow you to review the patch.<br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335460LTS/HowTos2013-05-02T20:01:30Z<p>Thanh.ha.eclipse.org: /* Setting up Git */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]])<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335459LTS/HowTos2013-05-02T20:01:18Z<p>Thanh.ha.eclipse.org: /* Setting up Git */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (refer to [[#Checkout code with Gerrit]]<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335458LTS/HowTos2013-05-02T20:00:25Z<p>Thanh.ha.eclipse.org: /* Build step 1, invoke maven for Platform build */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean verify<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335457LTS/HowTos2013-05-02T19:59:32Z<p>Thanh.ha.eclipse.org: /* Pushing changes to Company specific branch */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
= Hudson =<br />
<br />
Hudson is a Continuous Integration server used by the LTS Forge. It is hosted at https://lts.eclipse.org/hudson<br />
<br />
You can use Hudson to run periodic builds.<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean install<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Set profiles: no-bree-libs<br />
# Save<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335456LTS/HowTos2013-05-02T19:56:36Z<p>Thanh.ha.eclipse.org: /* Setting up a Hudson Maven project to build Eclipse Platform */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335453LTS/HowTos2013-05-02T19:54:15Z<p>Thanh.ha.eclipse.org: /* Pushing a patch to Gerrit Review */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
<br />
== Pushing changes to Company specific branch ==<br />
<br />
While LTS Central Forge does not allow direct pushes you are able to push directly to your company specific branch by prefixing your branch name with your company. For example:<br />
<br />
<pre><br />
git checkout -b company/branch<br />
git add /path/to/file<br />
git commit<br />
git push origin company/branch<br />
</pre><br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (example: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git)<br />
#* '''Note:''' This is the path component of the https:// provider.<br />
#** Example: https://lts.eclipse.org/gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
#** Becomes: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean install<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Set profiles: no-bree-libs<br />
# Save<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335452LTS/HowTos2013-05-02T19:50:48Z<p>Thanh.ha.eclipse.org: /* Pushing a patch to Gerrit Review */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<pre><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</pre><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (example: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git)<br />
#* '''Note:''' This is the path component of the https:// provider.<br />
#** Example: https://lts.eclipse.org/gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
#** Becomes: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean install<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Set profiles: no-bree-libs<br />
# Save<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335451LTS/HowTos2013-05-02T19:50:20Z<p>Thanh.ha.eclipse.org: /* Checkout code with Gerrit */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
<br />
== Pushing a patch to Gerrit Review ==<br />
<br />
After making a patch and your ready to push you will want to commit your patch to your local git and then push it up to Gerrit's special '''refs/for/branch''' path.<br />
<br />
<code><br />
git add /path/to/file<br />
git commit<br />
git push origin HEAD:refs/for/branch<br />
</code><br />
<br />
* Replace refs/for/'''branch''' with the branch name of the branch your code is for such as R4_2_maintenance<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (example: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git)<br />
#* '''Note:''' This is the path component of the https:// provider.<br />
#** Example: https://lts.eclipse.org/gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
#** Becomes: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean install<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Set profiles: no-bree-libs<br />
# Save<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.orghttps://wiki.eclipse.org/index.php?title=LTS/HowTos&diff=335432LTS/HowTos2013-05-02T15:37:09Z<p>Thanh.ha.eclipse.org: /* Checkout code with Gerrit */</p>
<hr />
<div>= LTS Forge =<br />
<br />
The Eclipse LTS Forge offers several services:<br />
<br />
* Gerrit instance which handles the management of repositories as well an interface for members to submit patches for code review (https://lts.eclipse.org/r)<br />
* Hudson instance for Continuous Integration (https://lts.eclipse.org/hudson)<br />
<br />
<br />
= Using Gerrit / Git =<br />
<br />
Gerrit a code review system as well as a repository service manager which provides access to project repositories.<br />
<br />
The LTS Forge Gerrit instance is available at https://lts.eclipse.org/r<br />
<br />
Once there you will not be able to see any projects or code reviews until you login. You can login by clicking '''Sign In''' at the top right of the page.<br />
<br />
You will need to use your '''eclipse.org''' email address and password to login.<br />
<br />
We will try to cover a few use-cases of what you might want to do in the subsections below.<br />
<br />
<br />
== Setting up your Gerrit account ==<br />
<br />
In order to checkout code from the git repositories you will first need to configure your Gerrit account. There is 2 possible options depending on what your most comfortable with.<br />
<br />
1. Setup a SSH Key to enable git checkouts via SSH<br />
<br />
2. Generate a random password to enable git checkotus via HTTPS<br />
<br />
<br />
To access the screens to configure these you will need to click '''Settings''' at the top right once you login to Gerrit.<br />
<br />
Then clicking '''SSH Public Keys''' or '''HTTP Password''' in the left menu bar depending on which you want to configure.<br />
<br />
=== Setting up SSH Public Keys ===<br />
<br />
SSH Public Key authentication is recommended over HTTP Password authentication as it is a little more secure.<br />
<br />
[[Image:Gerrit-settings-sshpublickeys.jpg|thumb|Gerrit Settings for SSH Public Keys]]<br />
<br />
To configure an SSH Public Key you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''SSH Public Keys''' on the left menu<br />
# Copy and Paste your SSH Key into the '''Add SSH Public Key''' box<br />
# Click '''Add'''<br />
<br />
Once your SSH Public Key is added you should be able to checkout using the Gerrit SSH URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
=== Setting up HTTP Password ===<br />
<br />
[[Image:Gerrit-settings-httppassword.jpg|thumb|Gerrit Settings for HTTP Password]]<br />
<br />
To configure an HTTP Password you will need to:<br />
<br />
# Click '''Settings''' on the top right after logging into Gerrit<br />
# Click '''HTTP Password''' on the left menu<br />
# Click '''Generate Password''' to generate a new password<br />
<br />
Note: If you have no need for a HTTP Password it is recommended you clear the password as this will make your account more secure.<br />
<br />
Once your HTTP Password is generated you should be able to checkout using the Gerrit HTTPS URLs for your project. You will need to use the '''Username''' that Gerrit supplied as your username when checking out the code.<br />
<br />
For example:<br />
<br />
<code>git clone https://lts.eclipse.org/r/project/repo.git</code><br />
<br />
<br />
See also: [[#Checkout code with Gerrit]]<br />
<br />
== Checkout code with Gerrit ==<br />
<br />
Gerrit provides 2 URLs for checking out code in the format:<br />
<br />
# <code>git clone ssh://lts.eclipse.org:29418/project/repo</code><br />
# <code>git clone https://lts.eclipse.org/r/project/repo</code><br />
<br />
* Replace '''project''' with the project such as "jdt", "platform", "equinox", etc...<br />
* Replace '''repo''' with the specific repo in the project such as "eclipse.platform.releng.aggregator"<br />
<br />
<br />
You can get a list of all projects you have access to by navigating to the projects page in Gerrit.<br />
<br />
# Click '''Projects''' in the top menubar<br />
# Click '''List''' in the Projects submenu<br />
<br />
The project list shows the full '''project/repo''' list so you can simply replace that string into the example URLs above.<br />
<br />
[[Image:Gerrit-projects-list.jpg|frame|center|Gerrit Projects List]]<br />
<br />
= HowTos =<br />
<br />
== Using TortoiseGit to "git submodule update" ==<br />
<br />
#Navigate to your git repository which you cloned (eg. eclipse.platform.releng.aggregator)<br />
#Right click &gt; TortoiseGit &gt; Submodule Update<br />
#Select to Initialize Submodules<br />
#Click OK<br />
<br />
== Setting up a Hudson Maven project to build Eclipse Platform ==<br />
<br />
For the steps below. Navigate to your Job you wish to configure and choose '''Configure'''<br />
<br />
=== Set the JDK ===<br />
<br />
It is recommended to set the JDK explicitly for your job instead of using the Default JDK. If you don't know which one to pick we recommend to select Oracle JDK 1.7.<br />
<br />
=== Setting up Git ===<br />
<br />
# Enter URL of git repo (example: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git)<br />
#* '''Note:''' This is the path component of the https:// provider.<br />
#** Example: https://lts.eclipse.org/gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
#** Becomes: /gitroot/lts-central/platform/eclipse.platform.releng.aggregator.git<br />
# Set the build branch (eg. R4_2_maintenance)<br />
# Click '''Advanced...''' under ''Branches to Build''<br />
# Check '''Skip internal tag'''<br />
# Save<br />
<br />
=== Setting up Platform Build ===<br />
<br />
==== Build step 1, invoke maven for Platform build ====<br />
<br />
# click Add Build Step -> Invoke Maven 3<br />
# click Advanced<br />
# Set goals: clean install<br />
# Set properties: maven.test.skip=true<br />
# Set pom-file: pom.xml<br />
# Set private repository enabled<br />
# Set profiles: no-bree-libs<br />
# Save<br />
<br />
<br />
<br />
= Known Issues =<br />
<br />
== Fail to clone submodules using msysgit ==<br />
<br />
Per Bug 376400 we discovered that msysgit has a max character limit somewhere around 256 which causes cloning files with a path longer than that to fail.<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376400#c4<br />
<br />
Workaround: Put your repo in the root of a drive and give it a short name. For example: C:\z<br />
<br />
== My Views link is broken ==<br />
<br />
Per Bug 403242 we discovered that trying to set any settings under "User Configuration" will cause the "Default View" setting to be set to blank. Once this occurs clicking "My View" in the left pane will display a stack trace error with no way of resetting it. Until this bug is resolved in Hudson we would recommend not trying to set anything in "User Configuration".<br />
<br />
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403242<br />
<br />
== Error assembling JAR: Could not find a common basedir (Resolved) ==<br />
<br />
In git version 1.7.8 and newer, git changed it's behaviour with respect to submodules https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.8.txt<br />
<br />
The new behaviour causes Tycho Eclipse-SourceReference provider for git to be unable to calculate the basedir correctly. There is a open Tycho bug that includes a patch for getting this resolved https://bugs.eclipse.org/bugs/show_bug.cgi?id=393752<br />
<br />
Workaround: Use a git version 1.7.7 or earlier.<br />
<br />
== Cannot git clone via ssh:// protocol (Resolved) ==<br />
<br />
The issue with this is that most user accounts on the Forge will not have shell access to the forge and the ssh:// protocol requires shell to operate. The solution we decided to go with was we provisioned a https:// protocal instead which we will recommend users to use instead.<br></div>Thanh.ha.eclipse.org