Запрет копирования и вставки, есть ли способ совместно использовать средства форматирования деталей Java

В нашем магазине 5-10 разработчиков работают над Eclipse с Java, и мы часто отлаживаем классы, у которых нет удобных для отладки toString () .

Вместе с тем приходит Детальный форматировщик , чтобы спасти положение. Ура! Но только мой день. Если я хочу поделиться радостью со своими коллегами-разработчиками, я ДУМАЮ, что мне нужно копировать и вставлять, как и они.

Это отстой. У нас есть N разных систем контроля версий, которые работают в Eclipse ... похоже, что это было бы чем-то, что люди хотели бы передать.

Ничего в диалоговом окне файл-> экспорт ... Ничего, поискав в онлайн-справке. Ничего.

Мне удалось отследить по крайней мере некоторые настройки в /workspace/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.dbug.ui.prefs , но есть причина верить, что это еще не все. К тому же, мысль о том, чтобы поместить что-то глубоко в скрытую папку в систему управления версиями, заставляет меня напрягаться.

Есть ли лучший способ поделиться средствами форматирования деталей? В идеале это было бы что-то, что мы могли бы просто проверить в нашем репозитории кода и распространить таким образом.

РЕДАКТИРОВАТЬ: Я использую Helios, Service Release 1, build id 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 () звучит многообещающе, но я бы я все же предпочел бы не писать плагин для этого сам.

А ... ну. Вот' s код 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 с именем типа, фрагментом кода, enabled, type-name ... замените \ u0000 на, во фрагментах, и все готово.

Это обрабатывает экспорт (черт возьми, вы могли бы просто выгрузить строку предпочтений целиком).

Импорт был бы не намного сложнее, хотя было бы неплохо не перезаписывать существующие типы или не давать пользователю возможность для этого, возможно, даже с разницей в двух рассматриваемых фрагментах.

OTOH, я бы действительно предпочел бы не полагаться на внутреннюю работу класса в *. internal. * .