Как сделать модификации после сборки в Eclipse Builder - PullRequest
0 голосов
/ 08 сентября 2011

В настоящее время я работаю над плагином Eclipse, чтобы обеспечить поддержку манипуляции iPOJO. Принцип iPOJO заключается в изменении файлов .class, сгенерированных компилятором Java, для добавления некоторых методов и добавления / обновления записи в файле Manifest.mf.

В настоящее время мой плагин предоставляет проект Nature и добавляет Builder, добавляемый в конце списка разработчиков проектов, который вызывает Манипулятор iPOJO. Я использую его в проектах PDE.

Полный процесс работает, но у меня проблема:

Когда мой конструктор завершил свою работу (и процесс сборки), весь процесс сборки перезапускается, стирая выходную папку и снова вызывая моего сборщика. Если я не добавлю трюк безопасности, это заставит процесс построения цикла снова и снова.

Поскольку я работаю с IResource, IResourceDeltaEvent должен быть отправлен в конце процесса сборки, поэтому я думаю, что лучший способ избежать такой проблемы - это скрыть факт изменения ресурса.

Для ясности, я ищу способ изменить файлы классов после сборки PDE, не вызывая новую сборку и не отключая свойство автоматической сборки рабочей области.

Спасибо за ответы.

1 Ответ

1 голос
/ 11 сентября 2011

Мне немного неясно, что вы описываете.

Вы упоминаете, что хотите, чтобы это работало для сборок PDE, но сборки PDE происходят в основном вне рабочей области с использованием скриптов ant. Они не используют IResource, Builder или IResourceDeltaEvent.

Я предполагаю, что вы на самом деле имеете в виду не PDE-сборки, а построение проектов плагинов внутри рабочей области.

В общем, Eclipse (в частности JDT) ожидает, что он полностью контролирует выходные папки. Тем не менее, есть опция в Preferences -> Java -> Building -> Output Folder, которая называется «Перестроить файлы классов, сгенерированные другими». Убедитесь, что это отключено. Eclipse не должен пытаться восстановить файлы классов, к которым вы прикасаетесь. Если ваш конструктор касается только файлов классов, он не будет запускать другие сборки после изменения файлов классов. Единственное, что вы должны быть осторожны, чтобы не компилировать вещи дважды (и я думаю, что это проблема, которую вы описываете).

В качестве альтернативы вам может быть проще реализовать CompilationParticipant (и точку расширения org.eclipse.jdt.core.compilationParticipant). Это позволит вам точно знать, когда JDT вызывает компиляцию и что именно она компилирует.

Кроме того, вы будете уведомлены об операциях сверки (т. Е. Об изменениях в рабочих копиях, которые не были сохранены). Это может быть полезно для вас, если вы хотите манипулировать файлами по мере ввода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...