Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-dd-dev] DD Features (Was: Device Debug 1.0.0 M6 candidateready for testing)

From my very recent (like 3 minutes ago) understanding of the use of features, I gather that we want to provide features that integrators will not have
to remove plugins from (originally, I thought integrators would just remove the org.eclipse.dd.gdb.launch jar file, if there
were not interested in it.)
 
If that is our goal, then your suggestion below makes a lot of sense.  My only concern is the naming of the features:
having DSF-MI contain all our GDB code, and GDB-MI just the ability to launch it, does not seem obvious to me.
But I wonder how the features to indicate that there is GDB -code- and GDB -launching-....
 
Is it easy to rename features?
 
Marc
 
 
-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx]On Behalf Of Pawel Piech
Sent: Friday, April 04, 2008 1:10 PM
To: Device Debugging developer discussions
Subject: [dsdp-dd-dev] DD Features (Was: Device Debug 1.0.0 M6 candidateready for testing)

I'm starting to second guess our features in general.  Currently we have:
  • Traditional Memory Rendering
  • IPXACT Editor & Checker
  • DSF SDK
    • This includes both DSF and MI components
  • GDB-MI Implementation (Requires DSF SDK)
    • This includes the GDB component only
The problem is that if someone wants to use DSF with a non-MI based debugger, they still have to include the MI component from the DSF-SDK feature.  I suggest that we crate a new feature: DSF-MI and include both MI and GDB plugins in it.  Then we can modify the GDB-MI feature to only contain the GDB launch registration.  For commercial debuggers that use the MI protocol, it shouldn't be a big burden to include the gdb and gdb.ui plugins, since they are rather light.

Opinions?

-Pawel

Pawel Piech wrote:
I don't think any of the other DD components have any down-stream dependencies, so we could move DD to +3.  I don't know if we can still do that in ganymede though, I'll ask the PMC.
-Pawel

Anthony Berent wrote:
Ted,

This puzzles me slightly, some of these (not just WST) look like M5 or
earlier builds, so are we really testing integration with the rest of
M6? For example the M6 version of org.eclipse.emf.edit.ui on the web
site is 2.4.0.v200804012208 whereas you are using 2.4.0.v200802090050.

I was, however, more concerned about the run-time environment, rather
than the build environment. In a sense, if we have to build with an
earlier version then, while that is a serious problem, it is one we can,
in theory, work around. If, however, what we have built can't run with
M6 then that is a show stopper. My worry was that I cannot test that the
editor runs correctly with M6 until WST M6 is available.

- Anthony

dsdp-dd-dev-bounces@xxxxxxxxxxx wrote:
  
Anthony,,

We built the M6 candidate against dependencies available from
the http://download.eclipse.org/releases/ganymede/ update site.

org.eclipse.cdt 5.0.0.200804020801
org.eclipse.wst.jsdt.feature 1.0.0.v200712072133-6--BcMAAvBMCfMOPw
org.eclipse.wst.common_core.feature
3.0.0.v200712031330-7C78ENQE_EkMNlSdX6U-yd
org.eclipse.wst.server_userdoc.feature
3.0.0.v200712031330-10-7w311913172_48
org.eclipse.jdt.source 3.4.0.v20080204-1800-7o7qEFDEFpPqiqYydmCVKgP
org.eclipse.emf.edit.ui 2.4.0.v200802090050
org.eclipse.wst.xml_userdoc.feature
3.0.0.v200712031330-40EC3_kE77Y8MG_DJEO
org.eclipse.wst.ws_wsdl15.feature
1.5.1.v200712121931-1407w31181_161226
org.eclipse.emf.common 2.4.0.v200802090050
org.eclipse.wst.server_ui.feature
3.0.0.v200712031330-790E8V9vDMOuK5HanZ_O9R59
org.eclipse.wst.web_userdoc.feature
3.0.0.v200712031330-20Ag8s733G486B6D7_
org.eclipse.wst.ws_ui.feature
2.0.1.v200712031330-7A2ECBBqiaHJGqcoqYC19_mKz0xg
org.eclipse.gef 3.4.0.v20080115-677-8082A5655G2337
org.eclipse.wst.ws_wsdl14.feature
1.4.0.v200712121931-13-7w31181722243_
org.eclipse.wst 3.0.0.v200712121937-7J788a8qMcwTMiBV2Q2Qxk89B8gj
org.eclipse.wst.xml_ui.feature
3.0.0.v200712031330-7C2EC_CnfcsMheslqXqNgUjsNubT
org.eclipse.wst.web_core.feature
3.0.0.v200712031330-42EAW_kE77b8C9Q8MGT
org.eclipse.wst.server_adapters.feature
3.0.0.v200712031330-4-CE_kE77c7B7ad
org.eclipse.xsd.edit 2.3.0.v200802090050
org.eclipse.wst.web_ui.feature
3.0.0.v200712031330-7F0EFHE7ifmPflnz-o-p8Bmz0rST
org.eclipse.emf.edit 2.4.0.v200802090050
org.eclipse.wst.xml_core.feature
3.0.0.v200712031330-7A7NEFGE7QYGHMHSV6SaSc
org.eclipse.wst.common_ui.feature
3.0.0.v200712031330-7D5EK_E9RvTVtnEmGdpyUmTeY7V0
org.eclipse.wst.ws_core.feature
2.0.1.v200712121934-7D7BEE7EB7sQRz0W9dwfE2
org.eclipse.wst.ws_userdoc.feature
3.0.0.v200712031330-34Ds9oA55P5L_97C9J
org.eclipse.xsd 2.4.0.v200802090050
org.eclipse.emf.ecore.edit 2.4.0.v200802090050
org.eclipse.emf.common.ui 2.4.0.v200802090050
org.eclipse.emf.ecore 2.4.0.v200802090050
org.eclipse.wst.server_core.feature
3.0.0.v200712031330-2-E8T8s733I364E

ted

Anthony Berent wrote:
    
Ted,

I will test it as far as I can, but it turns out that Web Tools
Platform (WTP), on which the IP-XACT editor is dependent, have not
yet released their M6, and are on the same Ganymede schedule as us
(offset of +2). Unless we get the staging changed for future
milestones I will never be able to fully test against the correct
version before the milestone. 

I will try using their latest integration build, but I don't know
what the quality of this is, or how similar it is to their real M6.

- Anthony

--------------------------

Anthony Berent

ARM Ltd

+44 1223 400763

      
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
    
--------------------------

Anthony Berent

ARM Ltd

+44 1223 400763


  


_______________________________________________ dsdp-dd-dev mailing list dsdp-dd-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev


Back to the top