Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] [Bug 256448] New: How to treat propertyTesters from an API point of view

https://bugs.eclipse.org/bugs/show_bug.cgi?id=256448  
Product/Component: Community / Architecture Council
           Summary: How to treat propertyTesters from an API point of view
           Product: Community
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Architecture Council
        AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx
        ReportedBy: martin.oberhuber@xxxxxxxxxxxxx
                CC: Darin_Wright@xxxxxxxxxx, zx@xxxxxxxxx


Eclipse Platform provides the
  org.eclipse.core.expressions.propertyTesters
extension point that allows plug-ins to register properties which can be
checked from various extensions such as menus, launch configurations and the
like.

I'm looking for best practices on documenting and versioning such properties.

1. Creators of menus who want to test properties need to know what properties
   are available, i.e. what ID's of properties are defined by the various 
   plug-ins available in the target platform. They may also look for
   documentation on each available property. How should providers of 
   propertyTester extensions document their available properties? Does
   anybody on the AC already document this, and how? What should be the
   Best Practice

2. Is there an existing bug on PDE that requests auto-generation of the 
   respective documentation from the extensions, as well as "browse" 
   functionality in the plug-in manifest editor to show available properties
   at those places where a property can be checked?

3. In my view, propertyTester extensions are part of the API of a plug-in.
   How do we treat plug-in versioning for such extensions? I'd think that
   addition of a new proeprtyTester extension would require reving up the
   minor version of a bundle, and users of propertyTester extensions should
   require the minimum version of a bundle that introduced the corresponding
   Property.
   Is it possible to add API Tooling for propertyTester extensions?
   Is there an existing bug which requests this?

I guess that there are more similar cases of API exposed not through Java but
through plugin.xml markup (basically every new extension point, and every new
slot in an extension point expose new API, but @since versions are currently
only available on a coarse granularity and API tooling does not check them.

In the propertyTester case, there is even a single slot only to list multiple
properties that happen to be provided by a single IPropertyTester
implementation. I think that this is bad practice in terms of traceability of
API additions, and I'd propose to split these up into separate slots, each of
which can be marked with an @since tag separately.

What do other AC members think about this?


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


Back to the top