Всем привет!

Предыстория.
На днях, ректрутер одной компании задал мне вопрос на тему работал ли я с "Intellij plugin platform" и "Eclipse RCP". Сначала даже не понял вопроса и ответил что нет. И естественно решил загуглить что же это, скажу честно, ответ (правильные статьи) мне не сразу пришел. Итого - разработка десктоп приложений.
Да, было время давно, я попробовал что такое Swing, помню как он меня ужаснул своим позиционированием компонентов, и больше к нему не возвращался. Теперь же понял что надо таки подтянуть скилы по нему и написать приложение.

Продолжение предыстории.
Было решено создать десктопное приложение, и прикрутить его к своему "пэт-проекту" на maven (назовем его "вэб-проект"). Это вэб-проект на spring-boot с кучей дополнительно используемых технологий и естественно с полноценным REST интерфейсом с авторизацией.
И эта идея мне нравится все больше - сначала это должен был быть тупо Swing с 5-7 формами, круды и вьюшки.
Но затем пришли более интересные мысли - реализовать нормальный MVC c использованием Spring (больше для красоты), слой репозитория сделать зависимым от того как юзер захочет работать - или через REST интерфейс, или напрямую с БД (тут пригодится существующая реализация, из самого вэб-проекта).

Мысли о реализации.
Так как идея создания десктоп приложения родилась достаточно быстро, то и реализовать пробу хотелось скорей. В вэб-проекте создал пакет desctop и накидал туда пробы (только swing). Да, все красиво работает - на рест интерфейс посылает запросы, получает json-ответы, затем их разбирает на TransferObject'ты и использует еще несколько (пока несколько) классов-сущностей (всего их около 10).
Далее возник резонный вопрос - ведь десктопное приложение это отдельный проект по сути, ему нужен свой jar-ник. Т.е. его надо отделить от основного (вэб-проекта).

Разделение (ранее многомодульностью не занимался, тут все проделывалось впервые)
Проба 1. Создаю родительский maven-проект, в нем создаю детей: web и desktop. Родитель остается чистым (про pom.xml), а детей соответственно раскидываю по их направлениям. Получает так, что desktop имеет зависимость на web, со всеми его зависимостями. На этом этапе мне что-то не понравилось.
Проба 2. Возвращаюсь в начало. В вэб-проекте создаю child "desktop", в него переношу десктопную часть. И узнаю, что собрать проект "desktop" я не могу, потому что родительский пакет должен быть "pom", а не "war".

Мысль последняя (не испробованная, и есть сомнения).
Сделать как "Проба 1", и из ребенка "web" вынести в родителя классы, общие для web и для desktop. Тогда дети останутся "при своих".

Вопросы:
1) правильная ли последняя мысль?
2) допустил ли ошибки в пробах 1 и 2 (если их видно из описанного)?
3) прошу советов - как такое реализовывается в энтерпрайзе?

Petro123Imperous,
Зачем два вопроса рассматривать в одном?
Eclipse и банальное использование библиотек jar в обоих проектах.
Нет, эклипс это часть предыстории, к вопросу не относится.

А объясните пожалуйста что вы подразумеваете под "толстый клиент", я вроде понимаю, но боюсь что не верно.
Толстый клиент тянет все зависимости (модули) и реализует весь функционал?

Petro123Imperous,
Толстый клиент это БЛ на клиенте.
эммм, что такое БЛ?

Petro123Автор нафигачил много букв, а потом ударился в молчанку.
Диалога не будет.
Конструктива тоже.

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

Вот вспомнилась фраза:
Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать.
— Антуан де Сент-Экзюпери

Т.е. нафигачить лишнего совершенно не хочется, но при этом и делить, по сути то что никак более использоваться не будет, как-то нет желания.

Приложение, со времени создания топика, находится на паузе.

ОзверинImperous, а что значит:

Imperous слой репозитория сделать зависимым от того как юзер захочет работать - или через REST интерфейс, или напрямую с БД (тут пригодится существующая реализация, из самого вэб-проекта).

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

Petro123ImperousНе заморачивайся, это к вопросу не относится.тут есть в топике конкретный вопрос?
Да, в самом первом посте, внизу.
авторВопросы:
1) правильная ли последняя мысль?
2) допустил ли ошибки в пробах 1 и 2 (если их видно из описанного)?
3) прошу советов - как такое реализовывается в энтерпрайзе?

ОзверинImperousпропущено...


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

это довольно сильно относится к вопросу, т.к. если слой доступа к данным будет общим для клиента на свинге и на веб сервиса, то и выносить его надо в отдельный jar`ник со всеми моделями, пропертями к базе и так далее, если же нет - то и не надо...

согласен, но это второстепенно.
на первом этапе сущности и ТО.