Bugzilla – Full Text Bug Listing
| Summary: | The example (examplary) components within TPTP should be a separate download | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | LO <lars> | ||||
| Component: | TPTP | Assignee: | Kendric Wang <kendricw> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P1 | CC: | aling13, eclipse, hkyleung, jcayne, jkubasta, paulslau, popescu, sluiman | ||||
| Version: | unspecified | Keywords: | plan | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_157493.html | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
LO
Valentina, can you please comment on this packaging concern? Thanks. Steve, request the fix for 4.2.1 Hubert, is this is approved, can we have the fix as a patch applied to the existing build ? my apologies, comment #2 is for a different request If you look at the TPTP charter proposal, TPTP is intended to deliver a common platform together with a sample implementation of this platform. Can you give more information on this request other than the confusion factor ?Log Analyzer is a completely usable implementation and is packaged and used by a few consuming products. If we have to provide separate install options for the two, then we need to understand what is the benefit of doing that. We'll need to create more plugins and more detailed feature split to have this separation and this is something other people don't want to see. I am not desconsidering this request , is just that we need a more detailed description of the things that are required to be downloadable in a separate feature and the reason behind this need. The project should definitly provide samples/examplary tools, but to me it simply seems logical to separate the samples from the platform! I can see several advantages with this separation, one is of course that we (as TPTP consumer/customer) does not have to do the repackaging (e.g. remove the samples before shipping). And if this separation would create more plugins I think the de-coupling seems healthy in a design perspective, since it indicates that the samples are not clearly separated from the platform. But I can also see problems because some of the tools are more than samples! Mark this an an enhancement request I support this request. To me it is more than an enhancement request, considering the PMC statements about "Design for Extensibility" (more flexible, more generic). Maybe the severity can be bumped? My motivation is this: we want to use just the launch framework (including the profiling run group and the profiling monitor) to integrate our profiling tools for C/C++ runtimes into Eclipse. We strongly prefer not to see any Java related items. Currently, TPTPs Java launch configurations are prominently displayed in the profiling dialog. They are useless for our customers, so I fear that this will have a negative impact on internal acceptance of our prototype and may threaten our goal of integrating with TPTP. The Java profiler is a very elegant showcase yet still a sample that belongs in its own plugin. Currently it (a) doesn't have its own plugin (launch configs), and (b) is spread across platform and trace projects (launch configs are in platform, the analysis views in trace). Also, we currently have no use for logging so the log navigator, log view, statistical graph and UML2 log interactions should be optional. They are all in the platform project so they become visible when installing it and may confuse our customers. By selecting plugin sets with trial and error it is possible to eliminate some of it but a more modular packaging supported by the TPTP project would help greatly and make it easier to integrate with TPTP one step at a time. Henk Aling Wind River TPTP will review this request as it opens the plan for the next release. Just a side note to the other comments; the exemplary profiling and logging views ( the views used to display data collected from the application ) are packaged in separate plugins so they can be optionally packaged by consuming products. This is the case for the Log Viewer and Profiling Statistical views. As a consuming product, all you have to do is create a new feature structure which allows you to optionally package these views. TPTP will review the need to provide these features itself. The platform feature contains the core set of views that allows a user to start profiling or monitoring an application and interact with that application. This is not an exemplary functionality and it is not intended to be provided as a potential replacement. Regarding this comment: ” The Java profiler is a very elegant showcase yet still a sample that belongs in its own plugin. Currently it (a) doesn't have its own plugin (launch configs), and (b) is spread across platform and trace projects (launch configs are in platform, the analysis views in trace).” The idea is to split the core function from the exemplary implementation of the framework. The launch configuration is a core function and is made available in one plugin, under the platform; the profiling views are packaged in another plugin so that consuming products can choose to not include them with the core function. Trace view are trace functionality so they are packaged under the trace project. The fact is that it will be really hard to offer a solution to cover everybody’s needs. We had a few approaches on how to split the code and for any of them there was a user not being satisfied by it. A consumer who wants to have custom packaging of the TPTP function can define its own feature structure. Nevertheless, TPTP will review this request to see if we can provide better feature customization at the project level. Created attachment 80403 [details]
Feature description document
Approved by the AG for TPTP 4.5 with the following comments: -The sizing should include 2 - 3 PDs for documentation for documenting the extension point schemas and possibly a small tutorial on how to contribute an example. -The sizing should include 1 - 2 PDs for build and infrastructure for feature creation/updates. -Each project should contribute a sub-feature of the parent example feature for TPTP, which will be used to contribute project-specific examples. -The parent feature should include a plug-in that contains the example infrastructure. -There has always been a concern about contributing an example due to the lack of documentation (hopefully covered by this enhancement) and confusing APIs. It would be beneficial to review the API used to contribute an example during this enhancement. -How will backward compatibility when restructuring features be monitored and evaluated? For example, testing Update Manager or consuming product installs. -List each of the logging and UI examples in this Description Document. The top-level example feature (org.eclipse.tptp.examples) and its branding plug-in have been checked into HEAD and added to the build. The example features for Platform and Monitoring are now included by this top-level example feature instead of each project's runtime feature. In terms of packaging, the examples features are still dropped into the drivers. Since the example features are not included anymore in the runtime features, the consumers will not be forced to include it with their product. In terms of updating, the top level examples feature is packaged into the tptp-sdk so it will be detected and and can be installed through the update manager. The remaining work is in creating documentation for the extension point schemas and a "how-to-contribute-examples" tutorial. (See above comments) The "how-to-contribute-examples" documentation has been included in 4.5i7. The files can be found in Platform/org.eclipse.tptp.examples under \doc and \images directories. (In reply to comment #11) > The "how-to-contribute-examples" documentation has been included in 4.5i7. The > files can be found in Platform/org.eclipse.tptp.examples under \doc and \images > directories. > Kendric, this type of document should be included in the product ISV documentaiton and/or posted on the TPTP web site: http://www.eclipse.org/tptp/home/documents/extenders.php >> Extending TPTP Added link to the Examples document from the TPTP extenders page. Verified in TPTP-4.5.0-200806200100. |