Как определить во время выполнения путь к каталогу проекта Mavenized Eclipse

Question

Всего новичок в Maven, пытающийся (вместе с остальной частью большой команды) преобразовать чудовищную кучу унаследованного кода из муравья в Maven. Работает достаточно хорошо, но у меня следующая проблема.

У меня есть проект, давайте назовем его Core, который во время выполнения должен загрузить некоторые файлы, зарегистрированные в рамках различных проектов, назовем их ресурсами A и B. Код Core запускается в определенном рабочем каталоге, давайте назовем его core / runtime , и есть файл свойств, который он читает, чтобы определить, что загружать из ресурсов A и B, с указанием относительного пути к рассматриваемым ресурсам, например,

  resource.ham=../../resources-a/files/ham.rsrc
  resource.eggs=../../resources-b/files/eggs.rsrc

(Да, я знаю, что это плохо и неправильно, и мы должны загружать ресурсы как ресурсы , из JAR через загрузчик классов и, возможно, какой-то контейнер или инжектор зависимости или что-то в этом роде. Не мой идея, а не моя текущая проблема, не на столе, которая будет решена сейчас.)

(Серьезно, , пожалуйста не беспокойтесь, предлагая исправить основную проблему. Мы знаем , что нам нужно исправить основную проблему. Мы знали, что нам нужно решить основную проблему до мы переключились на Maven, и до того, как мы переключились на Maven, глупый хак действительно сработал. Я знаю, что это заставляет вас чувствовать себя хорошо, но это не помогает . Это Десятилетняя кодовая база с десятками тысяч классов, поверьте мне, в ней есть много более важных вещей.)

Этот взлом относительного пути является проблемой только в Eclipse во время разработки; в самом развернутом приложении файлы живут где-то совершенно иначе и загружаются более разумным способом.

Во всяком случае, все это работало нормально, когда это были ванильные проекты Eclipse, поэтому в указанных каталогах были такие пути:

  c:\workspace\core\runtime
  c:\workspace\resources-a\files
  c:\workspace\resources-b\files

Однако теперь, когда они проверены как проекты Maven, каталоги теперь выглядят примерно так:

  c:\workspace\core\runtime # Inexplicably unchanged
  c:\workspace\maven.8675309\resources-a\files
  c:\workspace\maven.6345789\resources-b\files

Вопросы:

• Можно ли сделать так, чтобы эти maven.7762323 каталоги исчезли?
• Если нет, есть ли в Eclipse какой-нибудь способ получить путь к каталогу проекта, а затем передать его как системное свойство в конфигурации запуска, или что-то в этом роде?

Любое решение должно быть одним, которое я могу проверить в SVN, чтобы другие разработчики в моей команде могли использовать его «из коробки».

Обновление

Хорошо, я выяснил, откуда берутся каталоги maven.[number]: Когда вы выбираете родительский каталог в репозитории SVN и говорите «Извлечь как проект Maven», вы получаете каталог maven.[number], соответствующий родительскому, с все актуальные проекты в виде подкаталогов. Было бы очень удобно, если бы весь код находился в одном родительском каталоге или даже в одном и том же репозитории SVN.

Answer 1

Хорошо, решение было использовать {workspace_loc: имя проекта } переменные, чтобы установить несколько каталогов проектов в качестве системных свойств, и использовать их для вывода всего остального. Теперь, если я могу просто выяснить, как заставить смешную систему загружать JAR-плагины для работы с Maven ...

Answer 2

• Можно ли убрать эти каталоги maven.7762323?

Откуда они? Что вы имеете в виду под отмеченными как Maven ?

(РЕДАКТИРОВАТЬ: как ОП написал в комментарии, эти каталоги взяты из m2eclipse, который позволяет проверять maven проекты из SVN. Я не использую эту функцию, поэтому я не знаю много об этом. Насколько я понимаю, эти имена являются временными, и m2eclipse должен переименовать их в конце оформления заказа. Возможно, что-то пошло не так с затмением во время оформления заказа. На самом деле я не уверен.)

• Если нет, есть ли в Eclipse какой-нибудь способ получить путь к каталогу проекта, а затем передать его как системное свойство в конфигурации запуска или что-то в этом роде?

Eclipse имеет переменную {build_project}, которую можно использовать в аргументах конфигурации времени выполнения. Может быть, {workpsace_loc} будет более уместным в вашем случае. Весь список доступен с описанием на вкладке Аргументы конфигурации времени выполнения.

---

( РЕДАКТИРОВАТЬ: Я все еще не уверен, что у меня есть реальная цель, но у меня такое ощущение, что использование svn:externals может помочь.)