Как надежно настроить построитель улучшения байт-кода после компиляции в Eclipse?

Мне нужно настроить проект Eclipse с дополнительным компоновщиком, который улучшает байт-код Java, созданный более ранним компоновщиком (в идеале собственным Eclipse). Мне удалось заставить этот построитель запускаться и правильно улучшать вывод построителя Java Eclipse, но через несколько секунд Eclipse повторно запускает свой построитель Java и сбрасывает байт-код обратно. Он не перезапускает мой конструктор улучшений.

Мои настройки

  • Импортирован как «проект Gradle» в Eclipse 2019-12 (с Buildship).
  • Вручную (и автоматизированный с помощью Gradle) добавлен собственный построитель Ant (который в конечном итоге вызывает Gradle) для улучшения кода, который Eclipse Java Builder создает в bin/main, на месте. Этот построитель настроен для запуска при ручной сборке и автоматической сборке, а не после «очистки» или во время «очистки»< /эм>.
  • По умолчанию вышеприведенное заканчивается тремя компоновщиками, сверху вниз: 1. Gradle Project Builder, 2. Java Builder и 3. мой компоновщик расширения байт-кода (да, он указан последним).

Альтернативы, которые я пробовал

  1. Некоторые комбинации настроек моего компоновщика для запуска после/во время "очистки" также не увенчались успехом. Не знаю, к каким именно событиям они относятся, на самом деле.
  2. Если бы билдер обновил проект после ... и тоже нет - не помогло.
  3. Попробуйте удалить Java Builder, используя следующий бит в скрипте Gradle (не сработало - он возвращается сам по себе):

    eclipse {
        project {
            file {
                whenMerged { projectFile ->
                    projectFile.buildCommands.removeAll { it.name == 'org.eclipse.jdt.core.javabuilder' }
                }
            }
        }
     }
    
  4. Попытался отключить построитель Java вручную, и мой построитель расширения байт-кода также создал файлы (используя Gradle). При этом сохраняется следующий файл org.eclipse.jdt.core.javabuilder.launch со следующим содержимым... но при перезапуске сборщик снова включается:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <launchConfiguration type="org.eclipse.ant.AntBuilderLaunchConfigurationType">
    <booleanAttribute key="org.eclipse.ui.externaltools.ATTR_BUILDER_ENABLED" value="false"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_DISABLED_BUILDER" value="org.eclipse.jdt.core.javabuilder"/>
    <mapAttribute key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS"/>
    <booleanAttribute key="org.eclipse.ui.externaltools.ATTR_TRIGGERS_CONFIGURED" value="true"/>
    </launchConfiguration>
    
  5. Я пытался (и не смог) найти, изменяется ли (также) какой-либо файл рабочей области (в отличие от файла проекта), чтобы отключить построитель Java.

Вопросы

  1. Каков «правильный» способ настроить Eclipse для улучшения байт-кода после компиляции?
  2. Что заставляет Eclipse повторно запускать предыдущие сборщики без повторного запуска моего?
  3. Есть ли способ исправить (1)?
  4. Как надежно отключить построитель Java?

Кто-нибудь может помочь? Спасибо!

ОБНОВЛЕНИЕ Дополнительные сведения Я добавил 12 сборщиков и заставил их всех добавлять выходные данные в один и тот же файл журнала для исследования. 12 дополнительных построителей носят информационный характер: 4 перед Java Builder, 4 между Java и построителем расширений и 4 после построителя расширений. Каждый из 12 работает только в одном из четырех условий (отсюда 3x4). Они устроены следующим образом:

  1. Конструктор проектов Gradle
  2. 1a-after-clean (запускается только после "очистки")
  3. 1b-manual (запускается только во время сборки вручную)
  4. 1c-auto (запускается только во время автосборки)
  5. 1d-during-clean (запускается только во время "очистки")
  6. Конструктор Java
  7. 2a-after-clean (запускается только после "очистки")
  8. 2b-manual (запускается только во время сборки вручную)
  9. 2c-auto (запускается только во время автоматической сборки)
  10. 2d-during-clean (запускается только во время "очистки")
  11. Создание улучшений байт-кода
  12. 3a-after-clean (запускается только после "очистки")
  13. 3b-manual (запускается только во время сборки вручную)
  14. 3c-auto (запускается только во время автоматической сборки)
  15. 3d-during-clean (запускается только во время "очистки")

Каждый из 12 информационных конструкторов записывает время, свое имя и размер выбранного тестового класса. В нерасширенном виде он имеет длину 46243 байта. При расширении он становится 53338 байт.

Вот журнал после запуска «Очистить» только для этого проекта (включена «Автоматическая сборка»):

20:19:19
1d-during-clean
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:10 Test.class

20:19:19
2d-during-clean
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:10 Test.class

20:19:20
1c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:10 Test.class

20:19:27
2c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class


Buildfile: /.../some-ant.xml

run-gradle:
        [echo] Running Gradle: --parallel :...:enhanceEclipseBytecode
        ...
        [java] > Task :...:enhanceBytecode
        [java] Enhanced class: ...Test in ...
        ...
        [java] Enhanced 205 classes.
        [java] > Task :...:enhanceEclipseBytecode
        [java] BUILD SUCCESSFUL in 15s
        [java] 2 actionable tasks: 2 executed
BUILD SUCCESSFUL
Total time: 15 seconds
20:19:44
1c-auto
-rw-r--r--  1 Learner  ...\...  53338  3 Mar 20:19 Test.class

20:19:46
1c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:46
2c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:46
3b-manual
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:46
3c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:46
3d-during-clean
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:57
1c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:57
2c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:57
3b-manual
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:57
3c-auto
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

20:19:57
3d-during-clean
-rw-r--r--  1 Learner  ...\...  46243  3 Mar 20:19 Test.class

ОБНОВЛЕНИЕ 2: минимальный пример для воспроизведения

  1. Создайте папку - назовите ее как хотите.
  2. В этой папке создайте файл build.grade со следующим содержимым:

    buildscript {
        repositories {
            mavenCentral()
        }
    
        dependencies {
            classpath 'org.hibernate:hibernate-gradle-plugin:5.4.2.Final'
        }
    }
    
    plugins {
        id 'java'
        id 'eclipse'
    }
    
    apply plugin: 'org.hibernate.orm'
    
    repositories {
        mavenCentral()
    }
    
    dependencies {
        implementation 'org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final'
    }
    
    hibernate {
        sourceSets = [ project.sourceSets.main ]
        enhance {
            enableLazyInitialization = true;
            enableDirtyTracking = true;
            enableAssociationManagement = false;
            enableExtendedEnhancement = false;
        }
    }
    
  3. Создайте там src/main/java/learner/TestEntity.java следующим образом:

    package learner;
    
    import javax.persistence.*;
    
    @Entity
    public class TestEntity {
        @Id
        @Column(name = "id", nullable = false, updatable = false)
        private Long id = null;
    
        @Column(name = "name", columnDefinition = "TEXT")
        private String name = null;
    
        public Long getId() {
            return id;
        }
    
        public void setId(final Long id) {
            this.id = id;
        }
    
        public String getName() {
            return name;
        }
    
        public void setName(final String name) {
            this.name = name;
        }
    }
    
  4. Выполнить gradle compileJava. Откройте получившийся двоичный файл build/classes/java/main/learner/TestEntity.class в ASCII- или шестнадцатеричном просмотрщике и просмотрите там такие вещи, как $$_hibernate_write_name.

  5. Импортируйте этот проект в Eclipse (скажем, 2019-12) как проект Gradle и соберите его. Откройте получившийся bin/main/learner/TestEntity.class и не наблюдайте ничего из этого.

person Learner    schedule 03.03.2020    source источник
comment
Мой связанный с этим вопрос с точки зрения Gradle на форуме Gradle: discuss.gradle.org/t/   -  person Learner    schedule 04.03.2020
comment
1. Добавьте компоновщик проекта после компоновщика Java. 2. Возможно, изменены файлы, которые не являются производными (не в выходной папке) или характер Java-проекта. 3.+4. Инкрементальный компоновщик Java компилирует код и находит проблему. Для Java-проекта отключать его не имеет смысла. Работает ли усилитель байт-кода инкрементно?   -  person howlger    schedule 04.03.2020
comment
1. Кастомный билдер уже после Java билдера. 2. Проект имеет Java-природу. Ничего не меняется, кроме выходной папки. Я не знаю, нужно ли Eclipse обновляться, чтобы замечать и учитывать изменения выходной папки или нет. 3+4. Я не хочу его отключать - это была альтернатива невозможности с ним работать. Enhancer не является инкрементным, но является идемпотентным - повторный запуск его на уже обработанном выводе ничего не делает, и это занимает 5-7 секунд независимо (быстро).   -  person Learner    schedule 04.03.2020
comment
Добавлено много деталей.   -  person Learner    schedule 04.03.2020
comment
специальный построитель Ant (который в конечном итоге вызывает Gradle) ← Содержит ли скрипт Gradle eclipse { ... }. Если да, это может вызвать другую сборку. Что произойдет, если компоновщик проекта Ant просто удалит один файл .class и не будет трогать другие файлы или запускать Gradle или что-то еще? Взгляните на подключаемый модуль Eclipse org.eclipse.help.webap где компоновщик проекта Ant используется для компиляции jsp файлов после компоновщика Java.   -  person howlger    schedule 04.03.2020
comment
Gradle содержит eclipse {...}, так работает интеграция с Buildship. Gradle также самостоятельно выполняет этап улучшения байт-кода. Однако сам Gradle не вызывается во второй раз — я могу это подтвердить. Предварительная компиляция JSP - это другое и более простое, не затрагивающее тот же набор файлов, который выводит Eclipse.   -  person Learner    schedule 04.03.2020
comment
Buildship не требует наличия eclipse {...}. Прикосновение, создание или удаление непроизводных файлов (производный — это атрибут папки/файла Eclipse) запускает сборку. Пожалуйста, ответьте на мой вопрос Что произойдет, если компоновщик проекта Ant просто удалит один файл .class и не затронет другие файлы, не запустит Gradle или что-то еще? Предоставьте минимальный воспроизводимый пример.   -  person howlger    schedule 04.03.2020
comment
Buildship не требует этого, но он не ставит задачи улучшения байт-кода иначе в Gradle в Eclipse (в частности, плагин org.hibernate.orm), вероятно, для продвижения использования собственного компилятора Eclipse. Так что это уже обходной путь для этого. Несмотря на это, есть что-то подозрительное в конструкторе Eclipse и, возможно, в том, как Buildship взаимодействует с Eclipse. Я уже предоставил много подробностей, но, конечно, постараюсь привести минимальный пример.   -  person Learner    schedule 04.03.2020
comment
Конечно, вы предоставили много деталей, но ничего, что могло бы воспроизвести проблему. Удаление Java Builder было неверным путем, и мне неясно, было ли это полностью отменено или все еще вызывает проблемы, или другие вещи все еще основаны на нем. Прежде чем вы сможете добавить построитель проекта Ant через Gradle, он должен работать без вызова Gradle или запуска последующей сборки, переопределяющей расширенные файлы.   -  person howlger    schedule 04.03.2020
comment
Просто добавил минимальный пример.   -  person Learner    schedule 04.03.2020
comment
Re Удаление Java Builder было неправильным путем. Конечно неправильно! Это не то, чего мы хотим. Это что-то пытались, поскольку вещи не работают. Как вы можете видеть в минимальном примере, сборщик Java не удаляется, но ничего не происходит. Мы попытались добавить шаг для работы с выводом Java Builder, но он был перезаписан. Один из простых способов настроить этот обходной путь — добавить построитель (муравей или программу, не имеет значения) для выполнения gradle compileJava и build/classes/java/main/learner/TestEntity.class поверх bin/main/learner/TestEntity.class.   -  person Learner    schedule 04.03.2020
comment
Воспроизвести что? Я имею в виду, почему все файлы .class должны улучшаться каждый раз при сохранении файла .java? Почему недостаточно запустить задачу расширения Gradle перед запуском или отладкой приложения Java (например, вручную одно за другим или через группу запуска как одно действие)?   -  person howlger    schedule 04.03.2020
comment
Поскольку разработчикам также необходимо (1) запускать приложение из Eclipse, а не Gradle, и (2) они также запускают тестовый код (не все приложение), который требует улучшения основного кода. Это не о причине, почему. Есть много примеров, почему улучшение кода необходимо и/или полезно. Проблема здесь в том, как настроить Eclipse в этой среде.   -  person Learner    schedule 04.03.2020
comment
У меня есть полный минимальный проект с информационными/моделирующими сборщиками муравьев... в zip-файле размером 9,4 КБ. Не уверен, где это приемлемо размещать. ... опубликовано по адресу discuss.gradle.org/t/   -  person Learner    schedule 04.03.2020
comment
Я понял это ГЛАВНО. Предоставлю свой ответ, когда смогу.   -  person Learner    schedule 04.03.2020
comment
В вашем случае запуск энхансера в качестве построителя проекта не требуется. Поскольку нет необходимости компилировать другие классы или получать предупреждения, усовершенствование в качестве компоновщика проекта не добавляет ценности. Конструктор проектов означает запуск его при сохранении, поэтому он должен быть быстрым (в миллисекундах, а не в секундах). Чтобы улучшить файл .class непосредственно перед запуском/отладкой приложения или набора тестов из Eclipse, используйте так называемую Launch Group . Конфигурации запуска можно использовать совместно, поэтому их нужно настроить только один раз. Это действительно так просто.   -  person howlger    schedule 05.03.2020
comment
Вы все еще упускаете суть. Если бы в Eclipse были неявные группы запуска, которые автоматически добавляют подготовительные шаги перед запуском всего, что выходит из определенного проекта, я бы смог это использовать, да. Но это не так. Без улучшения во время сборки (независимо от того, сколько времени это займет или нет), каждый раз, когда кто-то хочет запустить что-то вроде теста JUnit или что-то еще из проектов, им придется либо вручную запускать улучшение, либо вручную создавать/изменять конфигурации запуска что они хотят запустить. Это действительно так грязно.   -  person Learner    schedule 05.03.2020
comment
Ух ты. Создание самого проекта занимает больше времени, и это не так важно. Конечно, мне необходимо использовать некоторые функции, но мне также не необходимо использовать Eclipse. Мы все могли бы сделать это с помощью командной строки, Gradle и vi. Некоторые люди здесь действительно делают. Обратите внимание, что этот проект изолирован и не часто изменяется большинством людей.   -  person Learner    schedule 05.03.2020


Ответы (1)


Было несколько вещей, в которых я был неясен/неправ, и не смог найти соответствующую документацию, чтобы узнать подробности. Вот краткое изложение того, что нужно знать, чтобы сделать это правильно (некоторые из них я понял с самого начала, но не все):

  1. Интеграция Gradle/Buildship в Eclipse пытается использовать внутренний компилятор Eclipse. Это разработано Eclipse и имеет свои преимущества во время разработки ... а также недостатки в такие времена - невозможность использовать внешних / производственных сборщиков (в данном случае модель Gradle) для создания здания. По этой причине любое улучшение байт-кода (плагины или нет), работающее внутри Gradle, вообще не будет иметь никакого эффекта в Eclipse (если только они не делают что-то специфичное для Eclipse). (я правильно понял)
  2. Чтобы выполнить улучшение байт-кода в Eclipse (не подходящее или то, что может сделать какой-либо плагин Eclipse), необходимо добавить пользовательские компоновщики и расположить их после компоновщика Java по умолчанию (вручную или автоматически). (я тоже правильно понял)
  3. Из коробки Eclipse предлагает два вида компоновщиков — «Муравей» и «Программа». Нет Gradle там. Тип «Программа» не является кросс-платформенным, только Ant. Ant можно использовать для выполнения каких-либо действий или запуска Gradle кросс-платформенным способом (Java exec в методе main() Gradle). (я тоже правильно понял)
  4. [ЗДЕСЬ Я ОШИБАЛСЯ] Eclipse предлагает четыре «события», к которым можно привязать Ant Builder: После «Очистки», Ручная сборка , Автоматическая сборка и Во время "чистки". Я не понял, когда они бегут. Например, я думал, что "Во время очистки" запускается во время очистки, а После "Очистки" должен запускаться после этого, чтобы позволить пользовательскому компоновщику проводить собственную чистку после уборки. Я думал, что за этим последует автоматическая сборка, если включена «Сборка автоматически» или «Сборка немедленно» отмечена в диалоговом окне «Очистка». Это НЕ так. После того, как "Очистить" на самом деле относится к шагу сборки, а не к очистке, и за ним НЕ будет следовать шаг *Автоматическая сборка (этот шаг выполняется только при сохранении редактирования и включении параметра "Автоматическая сборка" . В файле *.launch компоновщика это гораздо более очевидно - After a "Clean" на самом деле называется full, а сборки Auto и Manual называются auto и incremental. Это означает, что построитель расширений должен быть настроен на запуск после "очистки" в дополнение к автоматической сборке и ручной сборке< /em> и НЕ ДОЛЖЕН быть настроен для запуска *Во время «очистки». Моя ошибка заключалась в том, что я настроил его для запуска только для автоматических и ручных сборок.
  5. [ЗДЕСЬ Я ТАКЖЕ ОШИБАЛСЯ] Я указал рабочий набор соответствующих ресурсов на вкладке Параметры сборки для построителя улучшений. Я установил эти ресурсы как исходный код (для улучшения) и build.gradle (содержащий усилитель). Поскольку они не меняются в большинстве сборок, Eclipse предпочитает не запускать построитель. Теперь очевидная истина видения 20-20 заключается в том, что релевантными ресурсами для этого компоновщика являются выходные двоичные файлы компоновщика Java (и build.gradle), а не исходный код Java. Однако это не совсем правильный выбор (в отдельности), так как Eclipse в нашем случае попадает в бесконечный цикл — он думает, что энхансер изменил двоичные файлы, и, поскольку он настроен на запуск при изменении двоичных файлов, запускает построить заново. Мы вообще не можем НЕ устанавливать соответствующие ресурсы, поскольку это, кажется, означает «все/все». Улучшитель должен быть сделан таким образом, чтобы НЕ касаться файлов, которые уже были улучшены [UPDATE], и этого недостаточно. Читать дальше.

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

[ОБНОВЛЕНИЕ 1]

  1. [Я НЕ ЗНАЛ ЭТОГО] В Eclipse есть настройка рабочей области (флажок, переопределяемый для каждого проекта) в Настройки -> Java -> Компилятор -> Построение -> Папка вывода с названием «Перестроить файлы классов, измененные другими», официально описанные как « Укажите, следует ли перестроить файлы классов, которые были изменены другими, чтобы отменить изменение.". По умолчанию он не отмечен/выключен, что кажется правильным для этого случая. Однако это не работает так, как рекламируется. Какими бы ни были настройки, Eclipse Java Builder будет реагировать на свои выходные изменения (как если бы они были входными данными, я называю это дефектом) и «отменять изменения», вызывая бесконечные циклы сборки. Я обнаружил, что об этом симптоме сообщалось много раз - ищите это. При «правильной» настройке и отсутствии взлома сборщик Java продолжает отменять изменения, а Eclipse продолжает их повторно запускать, вызывая бесконечный цикл независимо от настройки.
  2. [ХАК, КОТОРЫЙ КАЖЕТСЯ РАБОТАЕТ СЕЙЧАС] Помимо того, что все вышеперечисленное настроено правильно, я модифицировал энхансер, чтобы гарантировать две вещи (может потребоваться только одна или обе, не уверен): (а) что существующие файлы *.class НЕ удаляются и создаются заново, а перезаписываются и (b) их время последнего изменения возвращается к тому, что было до улучшения . Это, кажется, достаточно обманывает обнаружение модификации Eclipse, чтобы вырваться из цикла, даже если размеры файлов разные. Это с Eclipse 2019-12 (4.14.0.v20191210-0610), и он может перестать работать с любым обновлением. Надеюсь, к тому времени они исправят дефект бесконечного цикла сборки.
person Learner    schedule 04.03.2020
comment
На самом деле ... это еще не окончательный ответ ... В более крупном проекте это, в зависимости от того, как настроены соответствующие ресурсы, либо заканчивается бесконечным циклом строителя (когда включена автоматическая сборка), либо возникает начальная проблема . - person Learner; 05.03.2020
comment
Просто добавил [ОБНОВЛЕНИЕ 1] к моему ответу выше, чтобы ответить на то, что я сказал в своем предыдущем комментарии выше. - person Learner; 06.03.2020
comment
Я разместил минимальный рабочий пример (без обходных путей обновления 1) по адресу discuss.gradle.org/t/ - person Learner; 06.03.2020
comment
Неправильно и не ответ. Например, (4) то, что вы называете четырьмя событиями, на самом деле является видами сборки (см. документация, на которую я ссылался в своем первом комментарии). Кроме того, входные (исходные) и выходные папки - это Java, а не сборщик проектов (опция, упомянутая в (6), касается не того, когда, а того, что делает сборка). Вы должны знать эти основы, чтобы, как вы, не создавать бесконечный цикл, например, записывая в файл журнала. - person howlger; 06.03.2020
comment
Есть лучшие решения, чем сборщик проектов, который занимает секунды даже при изменении одного исходного файла. Launch Groups или один из решения, перечисленные Лэнсом, можно использовать вместо них. - person howlger; 06.03.2020
comment
а) Так делать не следует, и по этой причине я согласен, что это неправильно. Однако это ответ, так как в этой ситуации работает только это. (b) В (4) это 4 события, так как Во время очистки это не сборка - это очистка и потому что это триггеры (триггерные события) для последующих сборок . (c) Входы и выходы не могут быть одновременно Java. Для собственного Java-конструктора Eclipse входные данные — *.java, а выходные — *.class. Я пришел сюда не потому, что утверждал, что все знаю, а наоборот. Однако решения никто не предложил - только изменить проблему так, как я не мог. - person Learner; 06.03.2020
comment
(d) Файл журнала не находится ни в одной из выходных папок. Несмотря на то, что он остается там сегодня, он не вызывает петель. (e) Добавление нескольких секунд для поддержания сборки в актуальном состоянии и работы в обычном режиме Eclipse предпочтительнее добавления в список того, что разработчики должны помнить и/или тратить время на выполнение. Это особенно верно для нас, потому что это изолированный проект, над которым работают немногие, и не все время из многих десятков проектов, на создание которых в противном случае уходит гораздо больше нескольких секунд. - person Learner; 06.03.2020
comment
(a), (b), (c), (d) и (e) неверны по уже упомянутым причинам. В противном случае документация врет, и я ошибаюсь в сборщиках проектов, которые я реализовал и которые годами используются в производстве. - person howlger; 06.03.2020
comment
Возможно, вы реализовали обычные сборщики, как и я (и у нас есть и другие виды, работающие годами), но не энхансеры байт-кода. Итак, да, документация лжет из-за дефектов, а не намеренно. И, да, вы ошибаетесь в масштабах этой проблемы (не обязательно других строителей). - person Learner; 06.03.2020
comment
Что делают компоновщики проектов Eclipse, которые вы реализовали? Где именно лежит документация? - person howlger; 06.03.2020
comment
Я сделал несколько сборщиков (исходного) кода, в отличие от улучшения байт-кода. Выше я отметил в своем ответе, что неверно и / или иным образом неисправно в отношении (6) и (7). - person Learner; 06.03.2020
comment
Речь идет о сборщиках проектов Eclipse, верно? Генераторы кода - это нечто другое (даже если есть некоторое совпадение). Я спросил вас, где это можно найти в документации, а не там, где вы это утверждали. Поэтому, пожалуйста, просто добавьте ссылку на документацию, на которую вы ссылаетесь (например, если вы говорите, что не работает так, как рекламируется, укажите также, что именно и где именно рекламируется). Или, если есть отчет об ошибке, дайте ссылку на него или сообщите номер ошибки. Eclipse имеет открытый исходный код, так что давайте исправим то, что не так. - person howlger; 06.03.2020
comment
Это и генераторы кода (на основе аннотаций и других данных из источника), и компоновщики проектов Eclipse (поскольку одни и те же вещи должны работать не только из командной строки, но и в Eclipse). В некоторых случаях выходными файлами являются *.java, в других — другие файлы ресурсов, которые необходимы последующим проектам, импортированным в Eclipse. Документация, на которую я ссылался для флажка, ясна и прямо там, в Eclipse, просто щелкните знак вопроса. Я не искал отчеты об ошибках по всем проблемам, но нашел по крайней мере одну все еще открытую и активную. Когда я найду больше времени, я прокомментирую там. - person Learner; 07.03.2020
comment
Вы утверждаете, что документация лжет, но не можете сказать, где именно. Теперь вы говорите о еще не исправленной ошибке, не сообщая о какой именно. Конструктор проектов Eclipse может генерировать код, а может и не генерировать. Флажок делает именно то, о чем говорит его метка: если он отключен, изменения в выходных папках Java будут игнорироваться; если включено, соответствующий файл .java будет перекомпилирован. - person howlger; 07.03.2020
comment
Что заставляет вас предполагать, что у сборщиков проектов есть входные (путевые) и выходные папки или изменения? Они этого не сделали. Все построители проектов запускаются при каждом изменении проекта (редактирование, удаление, добавление файлов или папок, включая атрибуты файлов/папок и метки времени). Изменение, сделанное компоновщиком проекта, также является изменением, которое снова запускает все компоновщики проекта. Бесконечное строительство указывает на то, что вы не поняли эту концепцию. Поэтому, пожалуйста, прекратите кричать, что документация лжет, что есть дефект или что все остальные его не понимают (см. кодекс поведения) . - person howlger; 07.03.2020
comment
Вау! Я вижу, что у тебя здесь высокий балл, но, похоже, ты всегда полагаешься на правоту, даже когда это не так. Соответствующие ресурсы = входы. Что нужно обновить = выход. Я упомянул документацию. Я также сказал, что буду ссылаться на дефекты обратно. Я видел их, но не добавил в закладки и потратил дни, работая с ними. Мне нужен настоящий отдых. - person Learner; 07.03.2020
comment
Вот ОДИН: bugs.eclipse.org/bugs/ show_bug.cgi?id=417735 - person Learner; 07.03.2020
comment
Не боритесь с теми, кто пытается вам помочь, боритесь с проблемой. Отчет об ошибке не имеет отношения, и более пяти лет бездействия указывает на то, что ошибка больше не существует в последних версиях. Разработчик проекта получает список измененных ресурсов и может использовать этот список, чтобы решить, действовать или нет. В компоновщике проектов Ant это делается через соответствующие ресурсы. Если параметр рабочей области Обновлять с помощью встроенных перехватчиков или пула отключен, необходимо настроить ресурсы на обновление после завершения. В противном случае Eclipse не увидит изменений, внесенных Ant непосредственно в файловую систему. - person howlger; 12.03.2020