Затмение и как оно справляется с JARS - Странный случай - PullRequest
Новая
       24

Затмение и как оно справляется с JARS - Странный случай

2 голосов
/ 08 октября 2010

Попытка внести небольшие изменения в движок Apache Velocity.

Вот что я могу и не могу сделать.

Я делаю изменение в функции слияния (). Изменение, которое я делаю, не имеет значения, потому что я еще не сделал это. ;) Сейчас я согласен на стрельбу из оператора println.

У меня есть две ссылки на merge (). Если я изменю функцию на mergeBAD (), Eclipse скажет мне, что не может найти merge (). Имеет смысл правильно? Раньше я включал в свой путь сборки класса две фляги, которые вы получаете при скорости загрузки, но вместо этого я создал проект, используя предоставленные файлы src, и использовал проект THAT в качестве зависимости. Опять же, тот факт, что невозможно найти merge (), когда я переименую его в mergeBAD, вселяет надежду.

Но когда я запускаю свой веб-сервер, нажимаю точку останова и перехожу на вызов слияния, он не может найти источник! Я снова указываю на проект, и он «находит» источник, ни одно из внесенных мной изменений (в частности, операторов println) не выполнено. Они просто пропущены. (

Что на Божьей зеленой земле могло быть причиной этого? Это сводит меня с ума. Я провел весь день сегодня, пытаясь понять, что не так. Я не могу продолжать без возможности изменить скорость. Из какой именно базы кода затмение запускает файлы скорости?

Большое спасибо заранее ТАК! :)

1 Ответ

3 голосов
/ 08 октября 2010

Это типичный случай путаницы между путь к классу сборки и путь к классу времени выполнения .

Ваш путь к классу сборки содержит ссылки на ваш проект Java(содержит изменения в Velocity) ... но я уверен, что ваш путь к классу времени выполнения содержит ссылки на исходные файлы JAR Velocity.

Управление путь к классу сборки и classpath времени выполнения в веб-проектах в Eclipse (WTP - проект веб-инструментов) претерпел значительные изменения за последние несколько выпусков WTP.Мы можем провести вас черезЕсли вы физически добавили JAR-файлы Velocity в WEB-INF/lib, давайте начнем с их удаления.

ОК, после удаления файла Velocity.jar из WEB-INF/lib выполните следующие действия:

  1. Щелкните правой кнопкой мыши проект, выберите «Свойства».
  2. Перейдите в «Путь сборки Java».Выберите вкладку «проекты» и убедитесь, что ваш пользовательский проект Velocity (давайте назовем его «MyVelocity») там НЕ .
  3. Все еще в «Путь сборки Java», выберите «Библиотеки»"и убедитесь, что Velocity JAR там тоже нет.

Выполнив описанные выше действия, мы очистили ваше Web-приложение от любых ссылок на MyVelocity (ваш проект) или любой другой Velocity JAR.

Теперь самое интересное.Я научу вас, как правильно «добавлять» проекты Java в веб-проекты как зависимости.

  1. Все еще в свойствах проекта, перейдите к Deployment Assembly.
  2. Нажмите «Добавить».
  3. Выберите «Проект», а затем «Далее».
  4. Выберите «MyVelocity» и убедитесь, что флажок «Справочник по веб-библиотеке» установлен.
  5. Нажмите «Готово».

Вернувшись в диалоговое окно Deployment Assembly, вы должны увидеть MyVelocity, сопоставленный с WEB-INF/lib/MyVelocity.jar.

Нажмите OK.

Что мы сделалито есть для сопоставления MyVelocity с зависимостью WEB-INF/lib.Таким образом, MyVelocity автоматически добавляется в путь сборки во время компиляции - поэтому очень важно, чтобы не было добавлено в путь сборки, что приводит к дублированию сборки.-path записи.

Теперь все должно работать для вас.Дайте мне знать, если у вас возникнут проблемы.

PS Эти инструкции верны, если вы разрабатываете отдельный проект WAR;если ваш WAR-файл является частью EAR, вы можете (при определенных обстоятельствах, например, если MyVelocity используется другими модулями J2EE внутри EAR) по-разному отображать MyVelocity в общем местоположении;если это так, дайте мне знать, и я уточню подробнее.

...