Hi Brian,
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[1] 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?
[1]
https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
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
this stuff.
Best regards
Wolfgang