Совсем недавно задавался похожим вопросом...
1) Вместо configurations.compile лучше использовать configurations.runtime.
2) В моём случае следующее утверждение не верно:
Но возникает проблема: в случае, если у Common есть какая-то зависимость, а у Module-1 её нет, на уровне Module-1 придется описывать все необходимые зависимости Common, что неприемлимо.
В нашем проекте 'module-1' и 'common' это два независимых проекта. Commons публикуется в Artifactory (или локальный репозиторий), при этом pom файл содержит все прописанные для него зависимости. При сборке module-1 "вытягиваются" как его собственные зависимости так и зависимости специфичные для common, при этом они все попадают в итоговый jar.
3) Ещё одно отличие нашего проекта в том, что jar файлы не распаковываются, а подгружаются с помощью jar-in-jar-loader.zip из eclipse (не нашёл как его скачать отдельно, но из eclipse его можно добыть так:
blog.eqlbin.ru/2012/04/runnable-jar-eclipse.html ). Итоговый таск выглядит примерно так:
task staticJar (type: Jar, dependsOn: 'classes') {
archiveName = 'static.jar'
destinationDir = releaseDir
from sourceSets.main.output
from zipTree("${libsDir}/jar-in-jar-loader.zip")
into ('libs') {
from configurations.runtime
}
def manifestClasspath = './ ' + configurations.runtime.collect { 'libs/' + it.getName() }.join(' ')
manifest {
attributes(
'Main-Class': 'org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader',
'Rsrc-Main-Class': 'org.company.main.class',
'Rsrc-Class-Path': manifestClasspath
)
}
}