Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between pages "Platform-releng-faq-obsolete" and "DSDP/DD/Face-to-face Toronto 22-Feb-2006"

(Difference between pages)
m
 
(→‎Contributions and Participation Discussion)
 
Line 1: Line 1:
−
<H3>Eclipse Platform Release Engineering FAQ</H3>
+
== Agenda & Attendee List ==
 +
* [[DSDP/DD/Toronto_22-Feb-2006_Agenda|Agenda]]
  
−
<p>
+
== Presentations ==
−
If you would like additional content added to this FAQ, please send a note to the
+
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2006-2-22_Toronto_DD_PDA_Prototype.ppt Pawel P - PDA Prototype]
−
[https://dev.eclipse.org/mailman/listinfo/platform-releng-dev platform releng developers mailing list]
+
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2006-2-22_Toronto_DD_CDT_FlexHierarchyUpdate.ppt Mikhail K - CDT Flexible Hiearchy Update]
−
</p>
+
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2006-2-22_Toronto_DD_UpdatePolicy-ModelProxy.ppt Samantha C - Update Policy]
  
−
<h4>What hardware comprises the platform-releng build infrastructure?</h4>
+
== Minutes - Wednesday DD Meeting ==
−
  <p>The eclipse platform build infrastructure consists of<br><ol>
+
=== Eclipse 3.2 Debug Platform - Demos / feedback session on prototyping ===
−
    <li>2 linux build machines (2GHz, 1GB and PowerMac G5, 2GB )<br></li>
+
* Pawel Piech - Wind River
−
    <li>2 junit test machines, one windows (2GHz, 1 GB) one linux (2.66
+
** Implemented directly against platform
−
    GHz, 1.2 GB )</li>
+
** [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2006-2-22_Toronto_DD_PDA_Prototype.ppt Pawel P - PDA Prototype]
−
    <li>4 performance test machines - one set of slower machines (one windows, one
+
** The current state of the flexible hierachy aligns well with WR's debugger implementation.
−
    linux 2GHz, 512 MB) and one set of fast machines (one windows, one linux
+
** Main issues at this point:  
−
    3GHz, 2GB)</li>
+
*** Need retargetable actions
−
    <li>1 linux cvs test server(500MHz, 500MB)</li>
+
*** Need public interface to get at standard images for label providers
−
    <li>1 database server with apache derby installed to store performance test
+
*** Column support in views is incomplete at this point
−
  results (2.5GHz, 500MB)</li>
+
* Alan Boxall
−
</ol></p><br>
+
** Implemented directly against platform
 +
** Moving from 3.0 to 3.1 - the biggest challenge was to get the multi-threaded UI to talk to their synchronous debug engine.
 +
*** They queue up all asynchronous requests. They use a lot of caching.
 +
** They are using the compatibility mode right now.
 +
** Taking advantage of 3.2 EDM in the future:  eventually, IBM's debug engines will drive the hieararchy.
 +
** Number of jobs is somewhat alarming.  (See performance discussions below.)
 +
** Plan to do some prototyping against flexible hierarchy after 3.2 is released.
 +
* Mikhail Khodjaiants, QNX
 +
** [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2006-2-22_Toronto_DD_CDT_FlexHierarchyUpdate.ppt Mikhail K - CDT Flexible Hiearchy Update]
 +
** CDT has requests to provide customized versions of variables and registers view.  Probably will happen after CDT 3.2.
 +
** Using compatibility mode right now for flexibile hierarchy (for 3.1).  Still need more investigation for how to expose customization.
 +
** TI:
 +
*** We need flexible hierarchy exposed at CDI layer.
 +
*** We use disassmebly view.  Need a disassembly memory renderer.
 +
*** Summary, they need flexibility at top and bottom.
 +
*** They would like to see CDT define a more embedded-centric user experience without major changes to CDI.
 +
*** Some view customizations.
 +
** Freescale:
 +
*** Multi-core flexibility is important.
 +
** Nokia:
 +
*** Similar comments to TI.
 +
* ATI
 +
** Builds against Eclipse platform, but haven't had a chance to look at 3.2 yet.
 +
* AMI
 +
** Builds against Eclipse platform.
 +
** Migrated an old VB debugger.  Looked at CDT and did some prototyping, but decided it would be too much work.
 +
** They are lacking some features using the platform directly, but also believe they have less problems.  One big issue was using GDB with their architecture.
 +
** First product: Oct 05 and based on 3.1.
 +
** Biggest issue is trying to use the memory view with their architecture.
 +
** Haven't prototyped against 3.2 EDM yet, but they can benefit from simplified hiearchy.  Update policies are also critically important because of very slow target connections.  Will focus on 3.2 after April.
 +
** Continually re-evaluate CDT.  Could potentially use parts of CDT.
 +
* PalmSource
 +
** Have a released product on 3.0 with a customized CDT.
 +
** Working on a 3.1-based product with un-modified CDT.  Trying to use GDB.
 +
** Also like view customization.
 +
* TI: Demo of view customizations in E 3.1
 +
** Variables and registers view are in table tree format (using tree control)
  
−
<h4>Is the Eclipse platform build process completely automated?</h4>
+
=== EDM 3.2 Progress Update – Darin W (IBM) ===
 +
* Stuff in M5 (public API freeze)
 +
** Virtual tree - turned out to be more complicated than they thought.
 +
** Virtual table
 +
** Incremental load
 +
* Stuff not in M5
 +
** Scopes / drag and drop
 +
** Columns
 +
* Moving forward, our API's are provisional, so we can still make changes.
 +
** March 30 - M6 feature freeze - only 3 weeks of development left
 +
** Columns and removing the last remaining synchronous interfaces
 +
* What's next after the 3.2 release?
 +
** How much feedback they get will determine how quickly these provisional API's can be public
 +
** Would need feedback in first 3 months:  July - Sept
 +
** The customized view content may have to go through another cycle.
 +
* 125374 - multi-column support in variables view:  patch posted.  Darin says this is close to the actual design.  Ted would like more granuality in toggling specific columns on and off.  Ted will add this to bug entry.
 +
* Plugable cell editors probably won't make the release.  Ted to look at provided a patch to possibly help get this in.
 +
* API versioning - adding new interfaces on top of old ones vs. deprecating.  When are interfaces collapsed together
 +
** Intention is that the adapters would live for a while in order to enable the backward-compatible debug model.
 +
* Using the editor with multiple debugging backends
 +
** Double-click gutter action - how is this resolved when the same editor is shared between two debug engines.
 +
** Seems to be a bigger problem that spans multiple projects:  CDT, DD, PTP
  
−
  <p>Yes, the Eclipse build process starts with a cron job on our main build machine that initiates a shell script that checks out the builder projects. </p>
+
=== Performance discussion ===
−
 
+
* IBM will come to EclipseCon that shows performance across multiple versions
−
    <li>org.eclipse.releng.eclipsebuilder -&gt; scripts to build each type of drop</li>
+
* Concerns about the large numbers of working threads spawned
−
    <li>org.eclipse.releng.basebuilder -&gt; a subset of eclipse plugins required to run the build.</li>
+
* Will have some suggestions for performance improvements
−
    <li>we also use several small cvs projects on an internal server that
+
* Action items:  each company should run its own performance numbers
  
 +
=== Update Policy ===
 +
* Progress Update – Samantha (IBM)
 +
** [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2006-2-22_Toronto_DD_UpdatePolicy-ModelProxy.ppt Samantha C - Update Policy]
 +
*** Slide 4:  Element, Model Proxy Factory, Model Proxy, and Model provided by client.  "Update Policy" is actually "View Updater"
 +
** Implementation is in the model and is model-specific.
 +
** Still work to do before we have a generic implementation.
 +
** Update policy will have to be part of viewer, and model proxy will have to be part of the model.
 +
* Need to form a workgroup to address the issues in Samantha's presentation.  Need to collect use cases from folks in this group.
 +
* Need to share a common look-and-feel, even if the implementation is in the model.
 +
* What's in 3.2
 +
** You can create model Proxies that tell how and when debug events are handled
 +
** Not there: a generic update policy
  
−
          store login credentials, publishing information and jdks</li>
+
=== Memory View ===
 +
* Demo by Ted Williams (WR) of new renderer for memory view.
 +
* DD group would like this contributed
 +
* Other features
 +
** Programmatic foreground and background coloring
 +
** Customizable context menu
 +
** Symbol interleave with address bar
 +
** Optional confirm before write
 +
** Undo write
 +
** Column headings with sub-address - user can turn on and off
  
 +
=== Contributions and Participation Discussion ===
 +
* See Felix's notes
  
−
  <p>Fetch, build and assemble scripts are generated automatically the org.eclipse.pde.build plugin in org.eclipse.releng.basebuilder. Fetch scripts specify the version of code to retrieve from the repository. Build
+
−
      scripts are also generated automatically to compile all java code, determine compile order and manage dependancies. Assembly scripts are generated to assemble the compiled code into it's final form, tar.gz, zip
+
−
      etc. We also use custom build scripts that you can see in org.eclipse.releng.eclipsebuilder.</p>
+
−
    <p>After the build drops are built, the automated junit and performance testing begins. Tests occur over ssh for Linux machines, and rsh for Windows machines.    Each component team contributes it's own tests. Once the tests are completed,the results are copied back to the build machine. Also, the images for the
+
−
  performance tests are generated.</p><br>
+
  
−
  <h4>What's the difference between an integration
+
−
    and nightly build?</h4>
+
−
     
+
−
      <p>With integration builds, we specify a version of the plugin to retrieve in the
+
−
    map files. (org.eclipse.releng/maps). With nightly builds, we retrieve the plugins specified in the map files from the HEAD stream.  The types of builds we run are described here   http://download.eclipse.org/eclipse/downloads/build_types.html.</p><br>
+
  
−
<h4>How do I run a build using the scripts in org.eclipse.releng.eclipsebuilder ?</h4>
+
* Prposal:  Technology sub-groups
 +
** Purpose is to create faster progress on the many technical areas the group wants to purpose.
 +
{| border="1"
 +
| '''Technology''' || '''Lead''' || '''Members'''
 +
|-
 +
| [[DSDP/DD/DebugView|Debug view]] || Paul Gingrich (TI) || TBD
 +
|-
 +
| [[DSDP/DD/MemoryView|Memory]] || Samantha Chan (IBM)  || Ted Williams (WR), Freescale, AMI
 +
|-
 +
| [[DSDP/DD/ExpressionsAndVariablesViews|Expressions & Variables]] || Ken Ryall (Nokia) || Ted Williams (WR), Pete Nichols (IBM)
 +
|-
 +
| [[DSDP/DD/RegistersView|Registers]] || Kirk Beitz (Freescale) || Ted Williams (WR), Pete Nichols (IBM), ATI
 +
|-
 +
| [[DSDP/DD/BreakpointsView|Breakpoints]] || Ewa Matejska (PalmSource) || Pawel Piech (WR), Mikhail Khodjaiants (QNX), TI, Nokia
 +
|-
 +
| [[DSDP/DD/ConsoleView|Console - Debug/Serial/Network]] || Aaron Spear (Mentor) || Freescale, AMI, PalmSource
 +
|-
 +
| [[DSDP/DD/DisassemblyView|Disassembly]] || Chris Recoskie (TI) - temporary lead || Wind River
 +
|-
 +
| [[DSDP/DD/GeneralViewManagement|Views - multi-context, pin/clone, update policy]] || Darin Wright (IBM) || Samantha Chan (IBM), Ted Williams (WR)
 +
|-
 +
| [[DSDP/DD/DebugModel|Debug Model]] || Pawel Piech (Wind River) || Mikhail Khodjaiants (QNX), Freescale, Nokia
 +
|-
 +
| [[DSDP/DD/Launch|Launching]] || Pete Nichols (IBM) || TI
 +
|-
 +
| [[DSDP/DD/Editor|Editor]] || Ewa Matejska (PalmSource) || Pete Nichols(IBM), Nokia
 +
|-
 +
| [[DSDP/DD/SourceLookup|Source Lookup]] || Pawel Piech (Wind River) || Pete Nichols(IBM)
 +
|}
 +
** Assignment
 +
*** Leader drives discussions and prototyping on their technology.  Leader initiates conference calls, start a wiki page (see link above), collects requirements, and investigates/delegates prototyping.  Leader is responsible for making sure the discussion is progressing.  Leaders have commit rights to DD.
 +
*** Team members help provide requirements and help protoype.
 +
*** All communications should happen on dsdp-dd-dev mailing list for visibility.
 +
*** By next meeting:  Lead should have requirements at minimum, but should also have protoype if at all possible, since having something to look at will generate better feedback.
 +
* Current developer commitments (used to build table above)
 +
** TI
 +
*** 1 half-time engineer
 +
*** Plan to update memory rendings, registers view, and variables view over the course of this year.  Targeting Eclipse 3.1.2. right now management.  Eclipse 3.2 product will release late summer / early fall.
 +
** WR
 +
*** 2 half-time+ engineers
 +
*** Picking up 3.2 in fall release.
 +
** Freescale
 +
*** Still working on first eclipse based product, so not yet ready to commit to providing fixes for any issues. After first release, they will have more breathing room for possible contributions.
 +
** PalmSource
 +
*** Also releasing first product, but could probably get some resources approved if community can delegate some work, especially in CDT.  Looking for direction and needs from Mikhail.
 +
** ATI (Mentor)
 +
*** Still evangelizing internally.  SPIRIT participation is definitely possible.  Potentially some tool contributions for creating, parsing, and checking SPIRIT files.
 +
** AMI
 +
*** Really want to contribute, but have no resources yet.  Could possibily contribute a debug console.
 +
** Nokia
 +
*** Would like to contribute work on the views.  Currently working on second Eclipse product.  Looking at adding extensible breakpoint behavior and possibly some work on variable detail formatting for c++.  After that they'll look at feedback from customers to help set priorities.
 +
** IBM
 +
*** 1 engineer
 +
*** Memory update policies and possibly contribute inbound launch code.  Need to think about other areas.
 +
* How can we get better participation to help Darin out on the debugger interfaces and views?
 +
* Where do we want to go next?  Volunteers for implementation?
 +
** New breakpoint features?
 +
** More memory rendering?
 +
** Multi-core
 +
** Sample debugger implementation from Wind River?
 +
** Debug console
 +
* Committer List
 +
** This list is based on the sub-project leads who volunteer to build use-cases and coordinate prototyping for platform improvements.  The commiters will have edit access to the Wiki and DSDP/DD CVS repository.
 +
** Paul Gingrich (TI)
 +
** Samantha Chan (IBM)
 +
** Ken Ryall (Nokia)
 +
** Kirk Beitz (Freescale)
 +
** Ewa Matejska (PalmSource)
 +
** Aaron Spear (Mentor)
 +
** Chris Recoskie (TI)
 +
** Darin Wright (IBM)
 +
** Pawel Piech (Wind River)
 +
** Pete Nichols (IBM)
 +
** Ted Williams (WR)
  
−
<p>
+
=== Miscellaneous ===
−
This document provides an overview of
+
* Eclipse 3.2 launching framework feedback
−
[http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.releng.eclipsebuilder/readme.html?rev=HEAD&amp;content-type=text/html how to build eclipse components using the releng scripts.]      </p><br>
+
** Darin described the launch changes in 3.2, which are covered in [http://eclipsezilla.eclipsecon.org/eclipsezilla/show_bug.cgi?id=58 "Integrating Custom Debuggers into the Eclipse Platform"] - his tutorial at EclipseCon 2006.
  
−
<h4>How do I automate my builds with PDE Build?</h4>
+
== Minutes - Thursday TM/DD joint session ==
 +
=== Update on DSDP, Plans for EclipseCon - Doug G ===
 +
* See [http://www.eclipse.org/dsdp DSDP Website].  Discussed new sub-projects:  MTJ and NAB.  Project pages will be posted in 1 to 2 weeks.
 +
* All companies will be represented at EclipseCon.  Aaron S, Mikhail K, Kirk B, Tom H won't be there, though.
 +
* AI:  Doug to setup lunch tables - due by Mar 1.  Will coordinate with Doug S to not duplicate CDT areas.
 +
* BOF - schedule at the conference.
  
−
<p>
+
=== SPIRIT Discussion ===
−
This document describes
+
* Hobson - Introduction
−
[http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.releng.basebuilder/readme.html?rev=HEAD&amp;content-type=text/html how to automate builds using PDE Build.] 
+
** (presentations to be posted)
−
</p>
+
*** First presentation - SPIRIT for EDA - this is more for information
−
<br>
+
*** Second presentation - SPIRIT for Debuggers
−
 
+
** Debug working group is probably needed to drive the SPIRIT definition.
−
<h4>How do I contribute a JUnit Plugin-in Test to the build?</h4>
+
** Ideal if Eclipse could join the consortium. ARM and Mentor can be interfaces, too.
−
 
+
** Hobson could work on setting up the debug working group.  Hobson will also check on what they can make available for parsers.  Hobson will check on licensing of SPIRIT XML files.
−
<p>
+
** Next steps
−
[http://www.eclipse.org/eclipse/platform-releng/junit-contributing.html Contributing JUnit Plug-in Tests]
+
*** Each member company to look into joining SPIRIT
−
</p>
+
*** DSDP-DD and DSDP-TM to nominate representative for a debug working group
−
 
+
*** DSDP-DD and/or DSDP-TM to build tools for generating/reading/validating SPIRIT files.  AI for Aaron to talk to company about potential contributions.  No Java Parser available yet for SPIRIT - we could contribute this in DD.
−
<h4>How do I contribute an example plugin to the build?</h4>
+
* Doug - WR's data files standards
−
 
+
** Two feature requests from SPIRIT
−
<p>
+
*** Board initialization specification
−
Once you have your plugin ready, install the org.eclipse.releng.tools plug-in, and use the "Release" action in the context menu of the test plug-in project to update and commit the map file.</p>
+
*** Help file indexing so registers can point to Silicon Vendor's pdf/html manuals
−
 
+
** Flow: SoC describes silicon -> Board vendor describes hardware and initialization -> user customizes initialization.   
−
<p>Send a request to platform-releng-dev@eclipse.org to add the test plugins to the build process. Include the following information:</p>
+
* Aaron Spear - general discussion on SPIRIT requirements
−
 
+
** (presentation to be posted)
−
<li>the plug-in ids</li>
+
** Feedback on additional register spec requirements
−
 
+
*** Unique ID
−
<p>The Eclipse release engineering team will update the org.eclipse.sdk.examples-feature to include the new tests.  They will also update org.eclipse.releng.eclipsebuilder/all/publishing/templateFiles/testManifest.xml to indicate the zip that should get a red X if there are compile errors associated with that plugin on the build page.
+
*** Initial grouping, but ability for a user to change groups
−
</p>
+
*** Textual descriptions - problematic for I18N - how should SPIRIT handle?
−
 
+
*** Mapping between debug format and registers - does this belong in SPIRIT or elsewhere?
−
<h4>I would like to recompile eclipse on a platform that is not currently supported. What is the best approach to this?  How can I ensure that the community can use my work?</h4>
+
*** Disassembly information should be a part of this - eventually we'd like table-driven disassembly - separate discussion
−
 
+
*** Endianness, default display size: byte, word, long, double, etc.
−
<p>The best approach is use the source build drop and modify the scripts to support that you are interested in. Then
+
*** Help index
−
      open a bug  https://bugs.eclipse.org with product <i>platform</i> and component <i>releng</i> attaching the patches to the scripts that were required to build the new drop.</p><br>
+
*** Long description for tool tip
−
 
+
** Feedback on additional memory spec requirements
−
<h4>How long does the build take to complete?</h4>
+
*** Flash - should be a separate discussion - CFI standard (?)
−
 
+
*** Cache
−
  <p>It takes two hours for all the drops to be produced. Junit (four hours)
+
*** Virtual - should be a separate topic - ATI limited the XML to what's physically on the chip. - need to describe MMU structure
−
  and performance tests (eight hours) run in parallel after the drops have been
+
*** Need to think about run-time memory map changes that are tied to the OS. Debugger will need to look at the MMU structure and also need to know about kernel data structures to handle the effective-to-physical address translation.
−
  built.
+
*** Shared memory between cores
−
  It takes a further
+
−
  two hours for the performance results to be generated. We will reduce the amount
+
−
  of time that  the build takes in the 3.2 timeframe by implementing faster hardware
+
−
  and more parallel ant tasks.
+
−
</p><br>
+
−
 
+
−
<h4>When is the next build?</h4>
+
−
<p>Please refer to the build schedule http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html
+
−
      </p><br>
+
−
 
+
−
<h4>When is the next milestone?</h4>
+
−
<p>Please refer to the Eclipse Platform Project Plan
+
−
http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html
+
−
</p><br>
+
−
 
+
−
<h4>I'd like to run a build with the version of the code that was used for build X? How do I know what versions of code in the repository were used?</h4>
+
−
<p>There are several ways to approach this issue. 
+
−
<ul>
+
−
<li>
+
−
Look at the directory.txt linked from the top of every build page.  The directory.txt concatenates all the map files used in a build into a single file. Please note that every nightly build runs from HEAD.  Therefore it is impossible to replicate a nightly build.
+
−
</li>
+
−
<li>
+
−
In addition, with every maintenance and integration build, the org.eclipse.releng project, which contains the map files for each project, is tagged with a version corresponding to that build.  For instance, the version I20051018-0932 corresponds to the integration build of the same name.  Please note that the builder projects, (org.eclipse.releng.eclipsebuilder and org.eclipse.releng.basebuilder) are also tagged during an integration build with the corresponding build name, but are not reflected in the directory.txt because they are not included in the eclipse distribution itself.
+
−
</li>
+
−
<li>
+
−
Finally, after each release the releng team tags all projects from the map files used in the release.  So, all the projects used to construct version 3.1.1 are tagged R_3_1_1. 
+
−
</li></ul>
+
−
</p><br>
+
−
 
+
−
<h4>I'm looking for an older build but can't find them on the download page?</h4>
+
−
 
+
−
<p>Check out archive site the http://archive.eclipse.org/eclipse/downloads for vintage builds.</p><br>
+
−
 
+
−
 
+
−
 
+
−
<h4>I'm a platform committer and have made major changes today.  I'd like to run a test build to ensure that my changes don't break the build. Can I request a test build from a web page?</h4>
+
−
 
+
−
<p>No, you cannot request a eclipse test build from a web page.  Our build takes too long and much of the time the builds machines are busy.  Please send an email to the releng team requesting a test build and explaining the changes you have made.  If you would like an expediated test build, please provide chocolate.</p><br>
+
−
 
+
−
<h4>How do I set up performance tests?</h4>
+
−
<p>Refer to the
+
−
 
+
−
[http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html    performance tests how-to.]
+
−
</p>
+
−
<br>
+
−
 
+
−
<h4>How do I run the performance tests from the zips provided on the download page?</h4>
+
−
 
+
−
  <p>Check out this https://bugs.eclipse.org/bugs/show_bug.cgi?id=91229#c3
+
−
  bug</p><br>
+
−
 
+
−
  <h4>What do I need to do to use org.eclipse.releng.basebuilder from HEAD now that the Xerces plugin has been removed?</h4>
+
−
 
+
−
<p>If you use the org.eclipse.releng.basebuilder from HEAD in your builds and you use
+
−
  TestVersionTracker to create a test.properties file (search for &quot;TestVersionTracker&quot; in
+
−
  your customTargets.xml build scripts), please read on.</p>
+
−
 
+
−
        <p>Some older versions of the TestVersionTracker class required xerces
+
−
        on the classpath. We have removed the xerces jars from
+
−
        the HEAD stream only of org.eclipse.releng.basebuilder.</p>
+
−
      <p>For any team broken by this, a &lt;generateTestProperties&gt; custom
+
−
        Ant task has been created which does the same. It is available in the
+
−
        org.eclipse.releng.basebuilder/plugins/org.eclipse.build.tools plug-in
+
−
        from HEAD. To use all you will need to do is the following replacement:</p>
+
−
      <p>Replace text such as this (taken from GEF):</p><br>
+
−
 
+
−
<p><pre>&lt;property name=&quot;build.compiler&quot; value=&quot;org.eclipse.jdt.core.JDTCompilerAdapter&quot;/&gt;<br>&lt;javac verbose=&quot;true&quot; failonerror=&quot;true&quot; srcdir=&quot;${builderDirectory}/tools&quot; destdir=&quot;${builderDirectory}/tools&quot;
+
−
  classpath=&quot;${eclipse.home}/plugins/org.apache.xerces_4.0.13/xercesImpl.jar:${eclipse.home}/plugins/org.apache.xerces_4.0.13/xmlParserAPIs.jar&quot;/&gt;<br>&lt;java classname=&quot;TestVersionTracker&quot; &gt;
+
−
 
+
−
&lt;arg line=&quot;${workingDirectory}/eclipse/features/org.eclipse.gef.test_3.1.0/feature.xml
+
−
${buildDirectory} ${workingDirectory}/gef-testing/test.properties&quot; /&gt;
+
−
&lt;classpath&gt;
+
−
&lt;pathelement path=&quot;${eclipse.home}/plugins/org.apache.xerces_4.0.13/xercesImpl.jar:${eclipse.home}/plugins/org.apache.xerces_4.0.13/xmlParserAPIs.jar:${builderDirectory}/tools&quot; /&gt;
+
−
&lt;/classpath&gt;<br>&lt;/java&gt;</pre>
+
−
 
+
−
with this:
+
−
 
+
−
<pre>&lt;generateTestProperties
+
−
buildDirectory=&quot;${buildDirectory}&quot;
+
−
 
+
−
featureId=&quot;org.eclipse.sdk.tests&quot;
+
−
outputFile=&quot;${workingDirectory}/eclipse-testing/test.properties&quot;
+
−
/&gt;</pre></p><br>
+
−
 
+
−
<h4>How do I update from 3.1 to 3.1.1 or 3.1.2 using update manager?</h4>
+
−
 
+
−
<p>Refer to this document http://www.eclipse.org/eclipse/platform-releng/updatesfor3.1.1.html</p><br>
+
−
 
+
−
<h4>Why should I package plugins and features as jars?</h4>
+
−
<p>See the Core team's document <i>Running Eclipse from JARs</i> http://www.eclipse.org/eclipse/platform-core/documents/3.1/run_from_jars.html</p>
+
−
 
+
−
<h4>Why should I use qualifiers?</h4>
+
−
 
+
−
<p>  See the Core team's document <i>Recommendation to version plug-ins</i> http://www.eclipse.org/equinox/documents/plugin-versioning.html </p>
+
−
 
+
−
<h4>How do I incorporate qualifiers into the build process?</h4>
+
−
 
+
−
<p>Update your plugins and features to use qualifiers as described in the previous FAQ entry.</p>
+
−
 
+
−
<p>Additional steps that the platform releng team uses to incorporate qualifiers into the build process</p>
+
−
 
+
−
<p>In our bootstrap script that kicks off the build, versionQualifier set to an empty string by default</p>
+
−
 
+
−
<tt>#versionQualifier - qualifier to use in plug-ins and features where specified<br>
+
−
versionQualifier=""</tt><br>
+
−
 
+
−
For nightly builds<br>
+
−
<tt>if [ "$buildType" = "N" ]</tt><br>
+
−
<tt>then</tt><br>
+
−
        <tt>versionQualifier="-DforceContextQualifier=$buildId"</tt><br>
+
−
<tt>fi</tt><br>
+
−
 
+
−
<p>For nightly builds, we set the  qualifier to the buildId.
+
−
For integration builds, pde build sets it to the tag in the map file for plugins, and generates feature qualifiers.</p>
+
−
 
+
−
The versionQualifier property is passed to the antRunner in our bootstrap script
+
−
 
+
−
<tt>
+
−
$antRunner -buildfile all.xml $mail $testBuild $compareMaps -DbuildingOSGi=true -DmapVersionTag=$mapVersionTag -DbuildDirectory=$buildDirectory -DpostingDirectory=$postingDirectory -Dbootclasspath=$bootclasspath -DbuildType=$buildType -D$buildType=true -DbuildId=$buildId -Dbuildid=$buildId -DbuildLabel=$buildLabel -Dtimestamp=$timestamp -DmapCvsRoot=:ext:someuser@dev.eclipse.org:/cvsroot/eclipse -Dzipargs=-y $skipPerf $skipTest $tag $tagMaps -DjavacDebugInfo=true -DjavacSource=1.3 -DjavacTarget=1.2 -DcompilerArg="-enableJavadoc -encoding ISO-8859-1" <b>$versionQualifier</b>  -DJ2SE-1.5=$bootclasspath_15 -listener org.eclipse.releng.build.listeners.EclipseBuildListener</tt>
+
−
 
+
−
<h4>Eclipsecon 2006 presentation</h4>
+
−
<p>http://www.eclipsecon.org/2006/Sub.do?id=254</p>
+
−
 
+
−
<h4>Best releng practices from our Eclipsecon 2005 poster</h4>
+
−
 
+
−
  <p>1. Automate the build process from end-to-end and automate early.<br>
+
−
    2. Use PDE Build in Eclipse to generate build scripts.<br>
+
−
    3. Automate JUnit testing and performance monitoring.<br>
+
−
    4. Automate build notifications (email)<br>
+
−
    5. Use gentle humiliation to encourage developers to contribute carefully.
+
−
    (Clown nose technique).<br>
+
−
    6. Ensure stability in the build process by thorough testing of builder changes.<br>
+
−
    7. Schedule builds at regular intervals and enforce rebuild policies.<br>
+
−
    8. Use map files in a central cvs repository.<br>
+
−
    9. Build on Linux.<br>
+
−
    10. Have fun!
+
−
  <br></p><br>
+
−
 
+
−
 
+
−
<h4>Useful reference documents</h4>
+
−
 
+
−
<p>Build and Test Automation for plug-ins and features http://eclipse.org/articles/Article-PDE-Automation/automation.html </p>  
+
−
<p>        Eclipse's culture of shipping http://www.artima.com/lejava/articles/eclipse_culture.html </p>
+
−
<p>        The Eclipse Way: Proccesses that Adapt http://eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf
+
−
 
+
−
 
+
−
 
+
−
</p>
+
−
 
+
−
<h4>Who are the platform-releng committers?</h4>
+
−
 
+
−
<p>The platform releng team consists of Sonia Dimitrov and Kim Moir. </p>
+
−
 
+
−
<h4>As the holiday season approaches, what gifts are appropriate for your favourite release engineer?</h4>
+
−
 
+
−
<p>We enjoy fine chocolate and [http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/curries.png Shaan] </p>
+

Revision as of 01:08, 1 March 2006

Agenda & Attendee List

Presentations

Minutes - Wednesday DD Meeting

Eclipse 3.2 Debug Platform - Demos / feedback session on prototyping

  • Pawel Piech - Wind River
    • Implemented directly against platform
    • Pawel P - PDA Prototype
    • The current state of the flexible hierachy aligns well with WR's debugger implementation.
    • Main issues at this point:
      • Need retargetable actions
      • Need public interface to get at standard images for label providers
      • Column support in views is incomplete at this point
  • Alan Boxall
    • Implemented directly against platform
    • Moving from 3.0 to 3.1 - the biggest challenge was to get the multi-threaded UI to talk to their synchronous debug engine.
      • They queue up all asynchronous requests. They use a lot of caching.
    • They are using the compatibility mode right now.
    • Taking advantage of 3.2 EDM in the future: eventually, IBM's debug engines will drive the hieararchy.
    • Number of jobs is somewhat alarming. (See performance discussions below.)
    • Plan to do some prototyping against flexible hierarchy after 3.2 is released.
  • Mikhail Khodjaiants, QNX
    • Mikhail K - CDT Flexible Hiearchy Update
    • CDT has requests to provide customized versions of variables and registers view. Probably will happen after CDT 3.2.
    • Using compatibility mode right now for flexibile hierarchy (for 3.1). Still need more investigation for how to expose customization.
    • TI:
      • We need flexible hierarchy exposed at CDI layer.
      • We use disassmebly view. Need a disassembly memory renderer.
      • Summary, they need flexibility at top and bottom.
      • They would like to see CDT define a more embedded-centric user experience without major changes to CDI.
      • Some view customizations.
    • Freescale:
      • Multi-core flexibility is important.
    • Nokia:
      • Similar comments to TI.
  • ATI
    • Builds against Eclipse platform, but haven't had a chance to look at 3.2 yet.
  • AMI
    • Builds against Eclipse platform.
    • Migrated an old VB debugger. Looked at CDT and did some prototyping, but decided it would be too much work.
    • They are lacking some features using the platform directly, but also believe they have less problems. One big issue was using GDB with their architecture.
    • First product: Oct 05 and based on 3.1.
    • Biggest issue is trying to use the memory view with their architecture.
    • Haven't prototyped against 3.2 EDM yet, but they can benefit from simplified hiearchy. Update policies are also critically important because of very slow target connections. Will focus on 3.2 after April.
    • Continually re-evaluate CDT. Could potentially use parts of CDT.
  • PalmSource
    • Have a released product on 3.0 with a customized CDT.
    • Working on a 3.1-based product with un-modified CDT. Trying to use GDB.
    • Also like view customization.
  • TI: Demo of view customizations in E 3.1
    • Variables and registers view are in table tree format (using tree control)

EDM 3.2 Progress Update – Darin W (IBM)

  • Stuff in M5 (public API freeze)
    • Virtual tree - turned out to be more complicated than they thought.
    • Virtual table
    • Incremental load
  • Stuff not in M5
    • Scopes / drag and drop
    • Columns
  • Moving forward, our API's are provisional, so we can still make changes.
    • March 30 - M6 feature freeze - only 3 weeks of development left
    • Columns and removing the last remaining synchronous interfaces
  • What's next after the 3.2 release?
    • How much feedback they get will determine how quickly these provisional API's can be public
    • Would need feedback in first 3 months: July - Sept
    • The customized view content may have to go through another cycle.
  • 125374 - multi-column support in variables view: patch posted. Darin says this is close to the actual design. Ted would like more granuality in toggling specific columns on and off. Ted will add this to bug entry.
  • Plugable cell editors probably won't make the release. Ted to look at provided a patch to possibly help get this in.
  • API versioning - adding new interfaces on top of old ones vs. deprecating. When are interfaces collapsed together
    • Intention is that the adapters would live for a while in order to enable the backward-compatible debug model.
  • Using the editor with multiple debugging backends
    • Double-click gutter action - how is this resolved when the same editor is shared between two debug engines.
    • Seems to be a bigger problem that spans multiple projects: CDT, DD, PTP

Performance discussion

  • IBM will come to EclipseCon that shows performance across multiple versions
  • Concerns about the large numbers of working threads spawned
  • Will have some suggestions for performance improvements
  • Action items: each company should run its own performance numbers

Update Policy

  • Progress Update – Samantha (IBM)
    • Samantha C - Update Policy
      • Slide 4: Element, Model Proxy Factory, Model Proxy, and Model provided by client. "Update Policy" is actually "View Updater"
    • Implementation is in the model and is model-specific.
    • Still work to do before we have a generic implementation.
    • Update policy will have to be part of viewer, and model proxy will have to be part of the model.
  • Need to form a workgroup to address the issues in Samantha's presentation. Need to collect use cases from folks in this group.
  • Need to share a common look-and-feel, even if the implementation is in the model.
  • What's in 3.2
    • You can create model Proxies that tell how and when debug events are handled
    • Not there: a generic update policy

Memory View

  • Demo by Ted Williams (WR) of new renderer for memory view.
  • DD group would like this contributed
  • Other features
    • Programmatic foreground and background coloring
    • Customizable context menu
    • Symbol interleave with address bar
    • Optional confirm before write
    • Undo write
    • Column headings with sub-address - user can turn on and off

Contributions and Participation Discussion

  • See Felix's notes



  • Prposal: Technology sub-groups
    • Purpose is to create faster progress on the many technical areas the group wants to purpose.
Technology Lead Members
Debug view Paul Gingrich (TI) TBD
Memory Samantha Chan (IBM) Ted Williams (WR), Freescale, AMI
Expressions & Variables Ken Ryall (Nokia) Ted Williams (WR), Pete Nichols (IBM)
Registers Kirk Beitz (Freescale) Ted Williams (WR), Pete Nichols (IBM), ATI
Breakpoints Ewa Matejska (PalmSource) Pawel Piech (WR), Mikhail Khodjaiants (QNX), TI, Nokia
Console - Debug/Serial/Network Aaron Spear (Mentor) Freescale, AMI, PalmSource
Disassembly Chris Recoskie (TI) - temporary lead Wind River
Views - multi-context, pin/clone, update policy Darin Wright (IBM) Samantha Chan (IBM), Ted Williams (WR)
Debug Model Pawel Piech (Wind River) Mikhail Khodjaiants (QNX), Freescale, Nokia
Launching Pete Nichols (IBM) TI
Editor Ewa Matejska (PalmSource) Pete Nichols(IBM), Nokia
Source Lookup Pawel Piech (Wind River) Pete Nichols(IBM)
    • Assignment
      • Leader drives discussions and prototyping on their technology. Leader initiates conference calls, start a wiki page (see link above), collects requirements, and investigates/delegates prototyping. Leader is responsible for making sure the discussion is progressing. Leaders have commit rights to DD.
      • Team members help provide requirements and help protoype.
      • All communications should happen on dsdp-dd-dev mailing list for visibility.
      • By next meeting: Lead should have requirements at minimum, but should also have protoype if at all possible, since having something to look at will generate better feedback.
  • Current developer commitments (used to build table above)
    • TI
      • 1 half-time engineer
      • Plan to update memory rendings, registers view, and variables view over the course of this year. Targeting Eclipse 3.1.2. right now management. Eclipse 3.2 product will release late summer / early fall.
    • WR
      • 2 half-time+ engineers
      • Picking up 3.2 in fall release.
    • Freescale
      • Still working on first eclipse based product, so not yet ready to commit to providing fixes for any issues. After first release, they will have more breathing room for possible contributions.
    • PalmSource
      • Also releasing first product, but could probably get some resources approved if community can delegate some work, especially in CDT. Looking for direction and needs from Mikhail.
    • ATI (Mentor)
      • Still evangelizing internally. SPIRIT participation is definitely possible. Potentially some tool contributions for creating, parsing, and checking SPIRIT files.
    • AMI
      • Really want to contribute, but have no resources yet. Could possibily contribute a debug console.
    • Nokia
      • Would like to contribute work on the views. Currently working on second Eclipse product. Looking at adding extensible breakpoint behavior and possibly some work on variable detail formatting for c++. After that they'll look at feedback from customers to help set priorities.
    • IBM
      • 1 engineer
      • Memory update policies and possibly contribute inbound launch code. Need to think about other areas.
  • How can we get better participation to help Darin out on the debugger interfaces and views?
  • Where do we want to go next? Volunteers for implementation?
    • New breakpoint features?
    • More memory rendering?
    • Multi-core
    • Sample debugger implementation from Wind River?
    • Debug console
  • Committer List
    • This list is based on the sub-project leads who volunteer to build use-cases and coordinate prototyping for platform improvements. The commiters will have edit access to the Wiki and DSDP/DD CVS repository.
    • Paul Gingrich (TI)
    • Samantha Chan (IBM)
    • Ken Ryall (Nokia)
    • Kirk Beitz (Freescale)
    • Ewa Matejska (PalmSource)
    • Aaron Spear (Mentor)
    • Chris Recoskie (TI)
    • Darin Wright (IBM)
    • Pawel Piech (Wind River)
    • Pete Nichols (IBM)
    • Ted Williams (WR)

Miscellaneous

Minutes - Thursday TM/DD joint session

Update on DSDP, Plans for EclipseCon - Doug G

  • See DSDP Website. Discussed new sub-projects: MTJ and NAB. Project pages will be posted in 1 to 2 weeks.
  • All companies will be represented at EclipseCon. Aaron S, Mikhail K, Kirk B, Tom H won't be there, though.
  • AI: Doug to setup lunch tables - due by Mar 1. Will coordinate with Doug S to not duplicate CDT areas.
  • BOF - schedule at the conference.

SPIRIT Discussion

  • Hobson - Introduction
    • (presentations to be posted)
      • First presentation - SPIRIT for EDA - this is more for information
      • Second presentation - SPIRIT for Debuggers
    • Debug working group is probably needed to drive the SPIRIT definition.
    • Ideal if Eclipse could join the consortium. ARM and Mentor can be interfaces, too.
    • Hobson could work on setting up the debug working group. Hobson will also check on what they can make available for parsers. Hobson will check on licensing of SPIRIT XML files.
    • Next steps
      • Each member company to look into joining SPIRIT
      • DSDP-DD and DSDP-TM to nominate representative for a debug working group
      • DSDP-DD and/or DSDP-TM to build tools for generating/reading/validating SPIRIT files. AI for Aaron to talk to company about potential contributions. No Java Parser available yet for SPIRIT - we could contribute this in DD.
  • Doug - WR's data files standards
    • Two feature requests from SPIRIT
      • Board initialization specification
      • Help file indexing so registers can point to Silicon Vendor's pdf/html manuals
    • Flow: SoC describes silicon -> Board vendor describes hardware and initialization -> user customizes initialization.
  • Aaron Spear - general discussion on SPIRIT requirements
    • (presentation to be posted)
    • Feedback on additional register spec requirements
      • Unique ID
      • Initial grouping, but ability for a user to change groups
      • Textual descriptions - problematic for I18N - how should SPIRIT handle?
      • Mapping between debug format and registers - does this belong in SPIRIT or elsewhere?
      • Disassembly information should be a part of this - eventually we'd like table-driven disassembly - separate discussion
      • Endianness, default display size: byte, word, long, double, etc.
      • Help index
      • Long description for tool tip
    • Feedback on additional memory spec requirements
      • Flash - should be a separate discussion - CFI standard (?)
      • Cache
      • Virtual - should be a separate topic - ATI limited the XML to what's physically on the chip. - need to describe MMU structure
      • Need to think about run-time memory map changes that are tied to the OS. Debugger will need to look at the MMU structure and also need to know about kernel data structures to handle the effective-to-physical address translation.
      • Shared memory between cores
Retrieved from "https://wiki.eclipse.org/index.php?title=Platform-releng-faq-obsolete&oldid=2536"

Back to the top