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
On 5 Mar 2019, at 22:00, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
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