Подупаковка моих классов статической метамодели в Eclipse Indigo

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

Я следовал инструкциям в Руководстве пользователя JPA для Canonical Model Generator. на Eclipse Galileo, но с Indigo вообще не работает. :(

Кто-нибудь использует классы статической метамодели в подпакете? Есть ли способ настроить его на Eclipse Indigo?


eclipse eclipselink annotation-processing jpa-2.0 eclipse-indigo
person ramsvidor    schedule 03.10.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Возможно, вам не следует менять пакет
Я бы посоветовал не делать этого, потому что их наличие в подпакете (или любом другом) нарушает текущую спецификацию JPA 2:

• Для каждого управляемого класса X в пакете p создается класс метамодели X_ в пакете p.[67]
...
[67] Мы ожидаем, что возможность использования различных пакетов будет предоставлена ​​в будущем выпуске. этой спецификации.
...
Реализации этой спецификации не обязаны поддерживать использование неканонических классов метамодели. Приложения, использующие неканонические классы метамодели, не будут переносимыми.

Другой способ организации — обычная практика JUnit: один и тот же пакет в другом исходном каталоге.

Но если нужно, вот как это делается

По крайней мере, с версией Eclipse работает следующее: Indigo Service Release 1 20110916-0149 и EclipseLink: eclipselink-2.3.0.v20110604-r9504. Имена JAR-файлов могут незначительно отличаться от версии к версии.

Если включено, отключите создание того же пакета, в котором находятся сущности:

  1. Перейдите в Свойства проекта - JPA и убедитесь, что значение исходной папки равно <None>.

Настройка генерации на другой пакет:

  1. Свойства - Обработка аннотаций
    [x] Включить настройки для конкретного проекта
    [x] Включить обработку аннотаций
    [x] Включить обработку в редакторе
    Сгенерированный исходный каталог: src (или там, где находятся исходники)
  2. Новый вариант процессора:
    key=eclipselink.canonicalmodel.subpackage
    value=sub | (желаемое имя пакета)
  3. Перейдите на один уровень глубже к Обработке аннотаций | Заводской путь и выберите Добавить внешние JAR-файлы и добавьте следующие jar-файлы:
    eclipselink/jlib/jpajavax.persistence_2.0.3.v201010191057.jar
    eclipselink/jlib/jpaeclipselink-jpa-modelgen_2.3.0.v20110604-r9504.jar
    > eclipselink/jlib/eclipselink.jar
  4. Позвольте Eclipse перестроить проект.
person Mikko Maunu    schedule 03.10.2011
comment
Просто для организации. Я думаю, что это не обязательно нарушает, спецификация говорит о том, что она еще не поддерживается самой спецификацией, что не означает, что реализации не будут ее поддерживать. В EclipseLink была поддержка для разделения моей статической канонической метамодели на Galileo, я просто не знаю, как использовать ее на Indigo. Между прочим, я все еще хочу использовать статическую каноническую метамодель. Неканонический означает, что приложение будет отвечать за создание классов метамодели, и тогда да, оно нарушает спецификацию, а это не то, чего я хочу. - person ramsvidor; 03.10.2011
comment
Тогда у нас совсем другое мнение. Я думаю, что да. Спецификация не указывает инструменты. Он определяет результат. Результат можно получить с помощью какого-либо инструмента или просто создав файлы самостоятельно. Инструмент, предоставляющий возможность генерировать метамодель для другого пакета, не нарушает спецификацию. В результате использования такой опции получается что-то, что нарушает спецификацию (в данном случае вещи в неправильном пакете). В любом случае, я опишу, как это сделать, отредактировав ответ. - person Mikko Maunu; 03.10.2011
comment
Я следовал этим инструкциям, но все равно ничего не делает. Мои классы метамодели все еще создаются в том же пакете моих сущностей. Моя точка зрения исходит из этой статьи, где говорится, что упаковка, управление версиями и соглашения об именах по-прежнему являются проблемой для спецификации, которая еще недостаточно ясна, и, таким образом, нет ничего плохого в том, чтобы иметь свой собственный подход к этому. В моем случае мне нужен другой подпакет, и я не хочу, чтобы он был в моем SCM. - person ramsvidor; 03.10.2011
comment
Хе-хе! Да, это странно! Я сделал именно то, что вы рекомендовали, прежде чем опубликовать этот вопрос. И я использую ту же версию, о которой вы упомянули: EclipseLink 2.3. В JPA UserGuide я упомянул, что они используют JPA 2.0_preview с EclipseLink 1.2. Может быть, это проблема. Либо поддержка этих опций процессора была удалена, либо ключи опций, возможно, изменились. - person ramsvidor; 03.10.2011
comment
Попробовал еще раз и записал каждый шаг (обновлено, чтобы ответить), хотите еще раз попробовать? Я не думаю, что версии в руководстве являются проблемой, потому что для меня это работает. Насчет статьи, что касается названий и пакетов, для меня уточнение достаточно ясное. Когда-нибудь у нас может быть какая-то другая спецификация, но до тех пор я стараюсь жить с этой. До тех пор, пока размещение файлов в свободно выбранной упаковке не означает, что результат может работать (или не работать) с другими поставщиками. - person Mikko Maunu; 03.10.2011
comment
Ах!! Только что просмотрел настройки моего проекта, и я ранее выбрал исходную папку канонической метамодели в настройках JPA! Я установил «Нет» и все работает! Спасибо за помощь, чувак! Очень ценю! - person ramsvidor; 03.10.2011
comment
Пожалуйста. Кстати, статья, на которую вы ссылаетесь, опубликована до того, как вышла окончательная спецификация 2.0, поэтому, возможно, она говорит о том, что что-то еще не определено четко. - person Mikko Maunu; 03.10.2011
comment
По состоянию на 2019 последняя спецификация JPA 2.2 по-прежнему требует, чтобы ваши классы метамодели находились в том же пакете, что и ваши сущности. Страница 238, §6.2.1.1 Каноническая метамодель. Ссылка: download.oracle.com/otn- pub/jcp/persistence-2_2-mrel-spec/ - person Z3d4s; 24.04.2019