On 12 Mar 2019, at 19:12, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
Hi Eduardo,
Am 12.03.19 um 08:58 schrieb Eduardo Martins:
> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom (dependency
management, plugins, etc.), which means that if we replace it with a “local” parent pom
then, for each release, we need to sync manually such parents poms content… I don’t see
any issue with using QS parent pom, it seems that those archetypes were designed to
generate clones of specific quickstarts with just different Maven GAVs. Have you tried to
install the SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use a
tag such as 16.0.0.Final, which parent was released to Maven, instead of pointing to QS
master branch ?
> Honestly I’m not sure this kind of app archetype is of much interest as it is, mostly
due to the app's complexity, probably would be more helpful almost “empty” apps, but
if the idea is to have a QS clone tool then perhaps a single generic archetype for that
would make more sense. I’m open to QS source changes needed to be friendly with such
archetype :-)
> —E
I agree that the "wildfly-javaee7-webapp-ear-archetype" archetype is not really
useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which consists of all
necessary pom.xml files and some deployment descriptor stubs. And *this* archetype is the
reason why I started working on it: it is a good starting point for a new JavaEE
application which already defines all necessary components.
I am willing to maintain this archetype for the next few years and trying to release a
version for each major WildFly version. As suggested I would add a static root pom.xml to
the archetype github project which is independent of the quickstart files, as they are not
"standalone". This main pom.xml has to be updated for each WildFly version, but
all the other files still can be pulled from the "KitchensinkEar" quickstart.
Then why get any sources from QS repo, having a proper do-nothing app project all locally
sounds better to me, probably less effort needed on every release too.
—E