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

"Библиотека" - это, пожалуй, слишком громкое слово, привычная ассоциация 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 .