У нас есть 5-10 разработчиков, работающих над Eclipse с Java, здесь, в нашем магазине, и мы часто отлаживаем классы, которые не поддерживают отладку toString().
А вот и Деталь форматирования , чтобы сохранить день. Ура! Но только мой день. Если я хочу поделиться радостью с моими коллегами-разработчиками, я ДУМАЮ, что я должен сделать некоторое копирование и вставку, как и они.
Это отстой. У нас есть N различных систем контроля версий, которые работают в Eclipse ... кажется, что это то, что люди хотели бы обойти.
Ничего в диалоге file-> export ... Ничего через поиск в онлайн-справке. Ничего.
Мне удалось отследить хотя бы некоторые настройки до /workspace/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.dbug.ui.prefs, но есть основания полагать, что это еще не все. Кроме того, мысль о том, чтобы положить что-то глубоко в скрытую папку в систему управления версиями, заставляет меня нервничать.
Есть ли лучший способ поделиться деталями форматеров? В идеале это было бы то, что мы могли бы просто проверить в нашем репозитории и распространить таким образом.
РЕДАКТИРОВАТЬ: я использую Helios, Service Release 1, идентификатор сборки 20100917-0705.
В дополнение к точке расширения javaLogicalStructures (для добавления логической структуры к заданным классам) есть также точка с именем detailPaneFactories. Но это для того, чтобы создать на панели текст (или что-то еще, благодаря этой точке расширения), к которому обращается средство форматирования деталей. Ни один из них не позволяет расширителям перечислять существующие средства форматирования деталей (или логические структуры в этом отношении).
В нижней части расширения detailPaneFactories есть кое-что интересное:
Supplied Implementation:
The debug platform contributes a detail pane factory providing a default
text source viewer detail pane. The default detail pane displays textual
details of a selected element based on the corresponding debug model
presentation's implementation of computeDetail(IValue value,
IValueDetailListener listener).
computeDetail звучит многообещающе. Я буду держать вас в курсе (если кто-то еще не победит меня ... ура щедрости).
Хм ... org.eclipse.jdt.debug.ui.JavaDebugUtils.getPreferenceStore () звучит многообещающе, но я все равно предпочел бы не писать плагин для этого сам.
Ах ... хорошо. Вот код org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager, используемый для их загрузки:
/**
* Populate the detail formatters map with data from preferences.
*/
private void populateDetailFormattersMap() {
String[] detailFormattersList= JavaDebugOptionsManager.parseList(JDIDebugUIPlugin.getDefault().getPreferenceStore().getString(IJDIPreferencesConstants.PREF_DETAIL_FORMATTERS_LIST));
fDetailFormattersMap= new HashMap(detailFormattersList.length / 3);
for (int i= 0, length= detailFormattersList.length; i < length;) {
String typeName= detailFormattersList[i++];
String snippet= detailFormattersList[i++].replace('\u0000', ',');
boolean enabled= ! JavaDetailFormattersPreferencePage.DETAIL_FORMATTER_IS_DISABLED.equals(detailFormattersList[i++]);
fDetailFormattersMap.put(typeName, new DetailFormatter(typeName, snippet, enabled));
}
}
Таким образом, строка в хранилище настроек - это просто набор CSV с именами типов, фрагментами, включенными, именами типов ... замените \ u0000 на, во фрагментах, и все готово.
Это обрабатывает экспорт (черт, вы можете просто сбросить строку настроек целиком).
Импорт не будет намного сложнее, хотя было бы неплохо не перезаписывать существующие типы или не предоставлять пользователю возможность сделать это, возможно, даже с различием двух рассматриваемых фрагментов.
OTOH, я бы действительно скорее не полагался бы на внутреннюю работу класса в *.internal.*.