Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox Minutes - 20081021"
(New page: == Agenda == * Deprecation of runtime Preferences * Enabling equals/hashCode compiler warning == Attendees == == Minutes ==) |
(→Minutes) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
* Deprecation of runtime Preferences | * Deprecation of runtime Preferences | ||
* Enabling equals/hashCode compiler warning | * Enabling equals/hashCode compiler warning | ||
| + | * Use of the graybox language pack for testing translations [https://bugs.eclipse.org/bugs/show_bug.cgi?id=217339 bug 217339] | ||
| + | * API tooling and OSGi API | ||
== Attendees == | == Attendees == | ||
| + | |||
| + | * Andrew Cattle | ||
| + | * Andrew Niefer | ||
| + | * DJ Houghton | ||
| + | * Jeff McAffer | ||
| + | * John Arthorne | ||
| + | * Pascal Rapicault | ||
| + | * Simon Kaegi | ||
| + | * Tom Watson | ||
== Minutes == | == Minutes == | ||
| + | |||
| + | * Deprecation of preferences | ||
| + | ** There is user confusion about what preference API to use | ||
| + | ** Since the equinox preference API has been around for several years we should deprecate the old org.eclipse.core.runtime.Preferences class and related methods | ||
| + | ** Need to double-check best practice for accessing new preferences so we can make the appropriate recommendation in the deprecation comment | ||
| + | |||
| + | * Enabling equals/hash warning | ||
| + | ** Some degenerate cases where equals method is just used as a filtering mechanism where hashCode is not interesting, but it doesn't hurt to add a hashCode in these cases (and technically these objects don't honour the contract of Object#equals) | ||
| + | ** We will enable it with severity=error | ||
| + | |||
| + | * Graybox language testing | ||
| + | ** Testing tool that generates fake translations to allow for NL testing without translations | ||
| + | ** Valuable for manual testing | ||
| + | |||
| + | * API tooling and OSGi | ||
| + | ** We don't have eclipse API tags on org.osgi.* packages, so we get API warnings when methods are added, etc. | ||
| + | ** Need to disable API tools testing of these packages because they don't evolve according to Eclipse rules | ||
| + | |||
| + | * Composite repositories | ||
| + | ** Currently work in progress to produce metadata/artifact repositories that amalgamate contents from several other repositories and present their contents as a single repository | ||
| + | ** Somewhat like the "associate site" concept in Update Manager | ||
| + | ** Composite repositories will not be modifiable via regular IRepository API | ||
Latest revision as of 15:09, 21 October 2008
Agenda
- Deprecation of runtime Preferences
- Enabling equals/hashCode compiler warning
- Use of the graybox language pack for testing translations bug 217339
- API tooling and OSGi API
Attendees
- Andrew Cattle
- Andrew Niefer
- DJ Houghton
- Jeff McAffer
- John Arthorne
- Pascal Rapicault
- Simon Kaegi
- Tom Watson
Minutes
- Deprecation of preferences
- There is user confusion about what preference API to use
- Since the equinox preference API has been around for several years we should deprecate the old org.eclipse.core.runtime.Preferences class and related methods
- Need to double-check best practice for accessing new preferences so we can make the appropriate recommendation in the deprecation comment
- Enabling equals/hash warning
- Some degenerate cases where equals method is just used as a filtering mechanism where hashCode is not interesting, but it doesn't hurt to add a hashCode in these cases (and technically these objects don't honour the contract of Object#equals)
- We will enable it with severity=error
- Graybox language testing
- Testing tool that generates fake translations to allow for NL testing without translations
- Valuable for manual testing
- API tooling and OSGi
- We don't have eclipse API tags on org.osgi.* packages, so we get API warnings when methods are added, etc.
- Need to disable API tools testing of these packages because they don't evolve according to Eclipse rules
- Composite repositories
- Currently work in progress to produce metadata/artifact repositories that amalgamate contents from several other repositories and present their contents as a single repository
- Somewhat like the "associate site" concept in Update Manager
- Composite repositories will not be modifiable via regular IRepository API