Am 05.03.19 um 00:27 schrieb Brian Stansberry:
AIUI your b.2 means decoupling the archetype from the QS code and
instead directly having the app code in the wildfly-archetypes codebase.
The downside to that is now there's another example app to maintain.
(More than one really, as there would be one per archetype.)
I think the key thing is this would need to be low maintenance. The root
QS depends on the wildfly-bom so if there aren't a lot of version
dependencies that would need to be in the archetype poms that will help.
Is your impression that the archetype pom would be low maintenance?
yes, this sounds like a very good idea: edit and maintain the root pom
of the archetype in the "archetype-resources" directory and sync only
all other files. This mean a bit of work each time the archetype is
updated for a new WildFly version, but less work than editing all files.
The only downside: I think the "ArchetypeSyncMojo" must be modified and
a "excludedFiles" property added, so that a sync will not overwrite the
archetype pom with the quickstart file.
I hope I can do this, if you think this sounds reasonable ;-).
Who is responsible for the maven-qstools-plugin? Probably he/she should
agree to those plans, too... And my change would have to be merged and a
new release of 1.7.0 (or 1.7.1?) to maven central would have to be
triggered. As this is my first step in WildFly coding, I am new to all