Не совсем согласен. У вас так и так будет некий пул потоков. В одном случае он конфигурится в коде (например пул из 10 потоков под Executor), а в другом он настраивается конфигурацией jboss. В итоге jvm будет оперировать +- равным числом потоков, но настройку размера пула можно свести к одной конфигурации.
Насколько мне известно, gradle сам ничего не знает про библиотеки, включенные в application server. А почему версии будут не совпадать? Вам достаточно добавть только те библиотеки нужных версий, которые непосредственно используются. Для IDE этого будет достаточно, чтобы корректно поддержать проект.
Про адекватность полностью согласен, но мой ответ был исключительно в контексте сертификации. Для меня отсутствие сертификата не является показателем способности или неспособности к обучению. Я видел и бестолковых кандидатов с сертификатами и перспективных людей без них (с частью из них я сейчас и работаю).
По сути, STS - это сборка Eclipse с инструментами для упрощения работы со стеком продвигаемым Springsource: Spring, Groovy, Gradle... В принципе, можно просто подключить их сайт с обновлениями и накатить нужные плагины на чистый Eclipse. Я предпочитаю сборку, из-за того, что у нас стек построен на Spring.
Зачем вам еще одна бд (ваш лог файлик), чтобы его тыкать и синхронизировать, при условии крайне малого объема данных в основной бд? При малых данных скорость доступа будет очень высока. Плюс, зная структуру запросов, вы можете расставить индексы, тем самым еще больше увеличив производительность.
Насчет тяжеловесности - зависит от цели. Для одностраничного приложения - да, будет тяжеловесно. Для чего-то более серьезного - имеет смысл.
Насчет отображения - вроде не обязательно, если задавать пути через Path (docs.oracle.com/javaee/6/api/javax/persistence/cri...). Я лично так его не использовал, поэтому не могу точно подсказать.
Именно поэтому я и назвал его хаком - это не работает в некоторых случаях и может перестать работать в любой момент. Тут уж каждый для себя выбирает, в зависимости от условий- скорость изменений или надежность.
Ну так и правила сборки там же задаются. Если это частичная сборка проекта (например, весь проект - war, но собрать надо jar из части файлов), то есть смысл подумать о подпроекте.
