Среда разработки:
Java 1.8, Maven, IntelliJ IDEA

Есть несколько проектов ( project1 , project2 ,...), которые используют одинаковые классы. Эти классы из одинаковых хочется

1) Сделать едиными и вынести их в отдельное место (директорию, проект, библиотеку - lib ), доступное каждому проекту projectX .

2) При этом файлы lib.java должны быть модифицируемыми, как и собственные файлы проектов, т.е. при сборке проекта projectX измененные файлы lib.java компилировались бы и попадали в сборку со всеми последними правками.

Вот здесь хорошо рассказано, как с помощью maven создать и подключить свою библиотеку. Но это получится бинарная библиотека lib.class . Чтобы обновлять поведение её классов, её нужно каждый раз пересобирать в виде отдельного проекта и отправлять в местный репозитарий, что есть весьма неудобно.

Как сделать так, чтобы было можно было разрабатывать projectX и параллельно в том же открытом проекте редактировать исходники lib.java ? Как вообще такая задача решается в Java стандартным образом?

Я новичок в Java , пришел из Delphi . В Delphi эта задача элементарно решается добавлением в sourcepath проекта всех нужных путей с исходниками. У Java тоже есть sourcepath , но непонятно, как и где его расширять, тем более на каталоги, внешние по отношению к проекту.

Заранее спасибо за все советы!

Спасибо всем участникам! Не все, к сожалению, поняли суть просьбы, но некоторые поняли, им особое спасибо.

"Библиотека" - это, пожалуй, слишком громкое слово, привычная ассоциация c пакетом (mvn install), наверное, сбивает с толку.
"Общие исходные файлы для разных проектов" - вот как точнее назвать то, что я хочу получить.

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

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

Вот уважаемый Zzz79 вроде бы знает как это сделать:

Дорогой Zzz79, а можно поподробнее, как это хозяйство настроить, где "прокинуть ауты", что и где прописать, чтобы изменения подхватывались в реальном времени? Нельзя ли глянуть на структуру аналогичного проекта?

Я попробовал, но получилось хреновенько. Сделал 2 проекта, каждый из 2-х модулей, один модуль общий для обоих проектов. Модули в смысле IDEA ("Project structure..."), а не maven, maven модули не позволили мне указать на "внешние" пути относительно проекта. Компилятор и среда пути к файлам модуля видят (после ручной настройки), в принципе можно и править, и собирать. Но настройки "библиотечного" модуля постоянно слетают при закрытии/открытии проекта, при каких-то еще событиях. Так жить нельзя.

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

Буду благодарен за образцы.

Jar файл, в моем нынешнем понимании, - это архив с откомпилированными бинарными файлами *.class, то есть собственно пакет (библиотека). В проекте, ясен пень, таких до сотни и больше, сторонних производителей. Могу и свой сделать. Но библиотеки jar с бинарными файлами как раз и создают проблему - не ясно, мне не ясно, как одновременно, в течение одной сборки проекта, компилировать и собственные файлы проекта, и исходные файлы библиотеки.

Или существуют мне пока неведомые управляемые jar-файлы с исходниками? Научите, тогда, пожалуйста, как с ними обходиться.

Можно и так. Смотрим дальше. Итак, открыто два проекта, первый - обертка, второй - библиотека. Из основного проекта идет вызов к библиотечному классу. Появилась нужда перейти к вызываемому методу и что-то в нем поправить. Просто нажать мышкой не получится, придется переключить окно на второй проект, там найти файл и метод. Дальше собрать библиотечный проект, переключиться обратно на основной, собрать основной. И все это вместо одного нажатия горячей клавиши. Как-то не айс. Но можно, спору нет.

Если вам нравится аналогия с Delphi, то в этой аналогии нет нужды собирать отдельную dll, а нужно воткнуть все необходимое в exe, за одну, естественно, сборку. Когда понадобится dll, будем делать dll, но не ранее того.

Ага, спасибо, смотрю, наверное, это поможет. Но там много наворотов, надо разбираться.

Елки-палки, что ж такие сложности для простой задачи - добавить пути поиска исходных файлов? При том что сам компилятор javac такую возможность предусматривает в sourcepath, а надстройки - maven, IDEA и иже с ними, рубят на подлете, и приходится так извращаться.

Не понял. А разве любое приложение не собирается в единый jar, который содержит все-все нужные классы, кроме разве что тех, которые входят в поставку целевой JRE?

Спасибо, Zzz79!


Я так сделал руками ("Project structure..."), но получилось плохо, написал выше. Попробую сейчас через gradle, как вы рекомендуете. Еще одна оболочка-плагин, чем дальше в лес, тем толще партизаны...


Я уж догадываюсь. Но не возьму никак в толк, что тут такого неправильного? А если "правильно", то получается неудобно. Это тоже неправильно.

Прописываю зависимость в pom.xml. Иначе пока и не умею. Насколько я вижу, в целевом jar в /BOOT-INF/lib после сборки находятся все необходимые библиотеки, в том числе и JDBC-драйвер.

Zzz79, так gradle - это получается альтернатива maven. Может, это и хорошая альтернатива, но мне она не подходит, не некоторым причинам я должен остаться на maven. Но за совет спасибо!

О как, классно! Про выводы не знаю, но информация крайне для меня ценная. По умолчанию, получается, работает compile .