Перейти к содержимому
EDT-Bridge
Русский
Esc
navigateopen⌘Jpreview
На этой странице

История изменений

Заметные изменения EDT-Bridge, свежие сверху.

История изменений

Заметные изменения EDT-Bridge, свежие сверху. Записи сгруппированы по дням; версии, вышедшие в этот день, перечислены в заголовке. Формат основан на Keep a Changelog, проект следует семантическому версионированию. Jar плагина и обвязка edt-bridge-mcp используют один номер версии.

Не выпущено

Добавлено

  • edt_project_errors сообщает sourceType маркера и его extraInfo – именно это различает два семейства проверок: документированные приходят из фреймворка стандартов, а короткий код вроде SU200 – из собственной проверки метаданных EDT.
  • edt_check_info распознаёт короткий код и объясняет, что это, вместо ответа “ничего не найдено”. Никакого соответствия “код – идентификатор” внутри движка проверок, как предполагалось в 0.7.1, нет: семейства просто разные, и путь к описанию – совпадение по заголовку.

Исправлено

  • run-headless.ps1 отказывался стартовать, если существовал любой процесс графической EDT, включая уже закрываемый. Теперь проверяются настоящие конфликты – порт, замок воркспейса, общий каталог dropins. Рядом всплыли два: -Port менял только опрашиваемый порт, поэтому нестандартный порт поднимал второй сервер на 8770; и воркспейс без проектов объявлялся неготовым, хотя сервер работал.

21.07.2026 – 0.6.0, 0.7.0, 0.7.1

Добавлено

  • Агент конфигуратора как третий транспорт к информационной базе. Запущенный с /AgentMode, он держит открытый сеанс и принимает команды по SSH – и входит в базу под учётной записью пользователя, чего не могут ни синхронизация EDT, ни ibcmd. Серверная база, спрашивающая, кто к ней пришёл, стала достижима, вместе с расширениями. Один агент на базу, переиспользуется; edt_designer_agent показывает и останавливает.
  • edt_infobase_config_state – ждёт ли обновление конфигурации базы данных? Отвечает сама платформа: обновление запускается, а подтверждение ему отказывается, поэтому ничего не применяется, а ожидающие изменения возвращаются списком.
  • edt_update_database_config – применяет конфигурацию базы данных. Загрузка проекта этого не делает, и до применения каждый сеанс выполняет прежний код – именно так выглядит свежий HTTP-маршрут, отвечающий 404. sessionTermination=force проходит запрет / завершение / применение одним вызовом.
  • edt_infobase_sessions – сеансы кластера через rac: перечислить и завершить. Ни агент, ни ibcmd до них не дотягиваются. Понадобилось из-за тупика: убитый, а не закрытый конфигуратор держит замок конфигурации, и дальше любая операция падает так, будто базу конфигурирует кто-то ещё.
  • edt_delete_extension – снять расширение с базы, шаг, замкнувший односторонний жизненный цикл. Требует force поверх apply.
  • edt_infobase_dump – выгрузить базу в .dt через ibcmd: та самая резервная копия, которой место перед применением конфигурации.
  • edt_update_infobase принимает transport=agent: XML конфигуратора уходит прямо в базу, без временной базы и без .cf посередине – это и делает путь пригодным для конфигурации на миллион объектов.
  • edt_extension_properties принимает infobase и идёт через агента – только так расширения серверной базы вообще достижимы.
  • edt_add_route – добавить маршрут в HTTPService. Раньше это означало править .mdo руками и сочинять uuid блока urlTemplates и вложенного methods.
  • Инструменты поверх ibcmd принимают учётные данные информационной базы рядом с данными СУБД. Без них ibcmd спрашивает имя пользователя в стандартном вводе – для неинтерактивного вызова это зависание, а не ошибка, и EOF он игнорирует (134 МБ приглашений за 60 секунд, замерено). Вывод теперь читается порциями, а процесс снимается, как только приглашение появилось.
  • Инструменты поверх агента адресуют базу, которой EDT не знает: srv\база или каталог файловой.
  • У каждого вызова ibcmd свой рабочий каталог; иначе они запирают один и тот же, и следующий вызов где угодно падает.

Изменено

  • edt_project_errors умеет отвечать на вопрос “что не так с модулем, который я только что правил”. Раньше он принимал имя проекта и возвращал всё – на большой конфигурации это 13 850 замечаний и ~5 МБ. Появились fqn / modulePath, severity и countOnly, а также total, bySeverity, bySource и ограничение списка.
  • edt_module_text принимает includeMethods (по умолчанию true): запрос одного метода больше не тянет за собой весь перечень модуля – 147 методов на одном рабочем модуле, и так при каждом чтении.
  • edt_module_text, edt_add_method и edt_delete_method понимают HTTPService.X и WebService.X: все три страдали от одного пробела в карте каталогов.
  • В таблицах инструментов README появился раздел про всё, что говорит с запущенной базой, с явным указанием транспорта – что чем достижимо, читателю нужно в первую очередь. Обе схемы перерисованы.
  • Набор тестов обвязки и workflow ci (Linux и Windows, 3.10 и 3.12), который оба релизных workflow вызывают первым, поэтому красные тесты останавливают релиз. Ядро набора – три регрессии, которые реально уехали в релиз.
  • Тесты JUnit для той части плагина, что не зависит от EDT: она вынесена в ...edtbridge.core, поэтому её собирает и проверяет обычный JDK.

Исправлено

  • self-update оставлял старый jar в dropins, когда релизный уже лежал там, – а две копии одного бандла и заставляют Equinox взять произвольный.
  • Схемы потеряли прозрачные углы; scripts/render-diagrams.sh теперь фиксирует флаги, которые это решают, – рецепт до сих пор нигде не жил.

19.07.2026 – 0.3.0, 0.3.1, 0.4.0, 0.4.1, 0.5.0

Добавлено

  • Формы целиком: edt_add_form создаёт управляемую форму штатным генератором EDT – тем самым, что стоит за мастером “Новая форма”. Элементы (edt_add_form_item и пара на изменение и удаление) идут через службу, которую вызывает сам редактор форм, поэтому имена, идентификаторы, фактический тип поля и автозаполнение колонок таблицы решает EDT. Так же и реквизиты с командами: edt_add_form_attribute и edt_add_form_command со своими парами, идентификаторы из штатной службы, заготовка обработчика пишется в модуль формы. Удаление перечисляет, что ещё ссылается, и требует force.
  • edt_adopt_object – заимствовать объект базовой конфигурации в расширение штатным адаптером EDT. Без него созданный проект расширения останавливался на полпути: перехват метода требует, чтобы владелец был заимствован.
  • edt_search_modules – полнотекстовый поиск по модулям проекта. Чтение идёт через буферы Eclipse, поэтому открытый в редакторе модуль ищется в том виде, в каком он сейчас, вместе с несохранённым.
  • edt_clean_project – сбросить результаты сборки, чтобы проверки прошли заново, программный аналог “Очистить” в EDT. Иначе устаревший маркер переживает код, который его вызвал.
  • edt_delete_project – удалить проект из воркспейса через Eclipse, чтобы обновилось дерево ресурсов; удаление папки руками оставляет призрачный проект, занимающий имя.
  • edt_extension_properties – читать и задавать то, что расширение несёт внутри базы (безопасный режим, защита от опасных действий, активность, область). Свежезарегистрированное расширение получает безопасный режим и защиту включёнными, а расширение, меняющее методы базовой конфигурации, ни под тем, ни под другим не работает.
  • edt_build_extension и edt_update_infobase сообщают changesMethods и, если он истинен, называют два флага, которые должны быть сняты.
  • Обвязкой edt-bridge-mcp можно управлять из шелла: call <инструмент>, tools, status. Раньше всё вне MCP-клиента означало писать своего клиента к порту 8770. Коды возврата разводят “вызов не состоялся” (1) и “инструмент отработал и вернул ошибку” (2).
  • self-update --from <каталог> ставит обвязку из локальной сборки вместо PyPI.
  • Инструменты платформы и баз: edt_platform_installations, edt_register_platform, edt_create_infobase, edt_build_extension (сборка .cfe через ibcmd).
  • edt_metadata_details сообщает флаги компиляции общего модуля и состав плана обмена – за тем и другим раньше приходилось идти в .mdo на диске.
  • edt_create_external_object принимает scriptVariant: EDT по умолчанию делает отдельный проект английским, из-за чего сгенерированные члены выходили как Object, а не Объект.
  • Страница настроек EDT-Bridge (токен, порт, переключатель evaluate), чтобы графическая EDT, запущенная обычным ярлыком, умела пускать инструменты записи.

Исправлено

  • edt_create_extension создавал проект, который не принимала ни одна база: загрузка падала с “Загрузка не должна менять принадлежность основного объекта конфигурации”. Корневой Configuration строился фабрикой метаданных, а она даёт обычную полную конфигурацию. Теперь корень – заимствованная базовая конфигурация, тот же шаг, что делает штатный мастер, и движок пишет всё, что расширению положено. Заодно закрылись два следствия: заимствованные объекты несут uuid-связь с базовым объектом вместо привязки по имени, а язык базовой конфигурации приходит вместе с ней.
  • edt_dump_external_object снова собирает .epf/.erf там, где EDT не может: она берёт самую свежую сборку линейки, поэтому линейка с тонкими клиентами наверху падала с MatchingRuntimeNotFound. Появился путь через диск, а сухой прогон перестал врать про него.
  • Модули внешних объектов разрешаются по FQN – ExternalDataProcessor и ExternalReport просто отсутствовали в карте каталогов.
  • self-update не мог обновить обвязку на свежем pipx: в venv, собранном через uv, вообще нет pip. Установщик больше не используется – колесо распаковывается поверх пакета средствами стандартной библиотеки.
  • Обвязка два релиза сообщала устаревшую версию: __init__.py нёс литерал, который pyproject.toml не использовал. Теперь версия пакета берётся из этого одного атрибута.
  • MCP-сервер сообщает собственную версию плагина из манифеста бандла, а не захардкоженную строку, поэтому дашборд и хендшейк не могут разойтись.
  • Обвязка фиксирует UTF-8 в стандартных потоках. На Windows они по умолчанию брали кодовую страницу ANSI, и “→” в описании инструмента рвал tools/list – клиент не регистрировал ни одного инструмента.
  • edt_infobases раскрывает группы, поэтому сгруппированные и серверные базы больше не теряются.

Изменено

  • Внутреннее: единый шлюз к модели разбит на шлюзы по областям (проект, чтение и запись метаданных, формы, платформа, отладка, BSL, документация). Чистый рефакторинг.

18.07.2026 – 0.1.0, 0.1.1, 0.2.0, 0.2.1

Добавлено

  • Полный цикл создать / разработать / собрать / доставить по MCP, инструменты записи – с сухим прогоном по умолчанию.
  • Обвязка edt-bridge-mcp (pipx): перенаправляет в запущенную EDT, сама поднимает headless, если ни одна не открыта, и доставляет jar плагина в dropins/.
  • edt_platform_help – Синтакс-помощник платформы из поставки EDT: настоящий справочник по API, с поиском, на русском и английском.
  • Многопоточный MCP-сервер и фолбэк по порту: если 8770 занят, берётся следующий свободный, и обвязка его находит.

Исправлено

  • apply при создании проектов работает надёжно: собирается и присоединяется отдельная Configuration или внешняя обработка, вместо того чтобы спорить с жизненным циклом headless EDT.

Изменено

  • Типографика по правилам проекта во всём репозитории – среднее тире вместо длинного, три точки вместо символа многоточия, – включая описания инструментов и обвязку.

11.07.2026 – 0.0.1

Добавлено

  • Первый выпуск: инструменты чтения по MCP (проекты, проблемы валидации, детали и списки метаданных, ссылки, валидация запросов, формы), встроенная панель и MCP-сервер на localhost.

Эта страница была полезной?