[wildfly-dev] Updating the WildFly archetypes

[Wolfgang Knauf]

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.


Do you agree to this plan ;-)?


Wolfgang

> 
>> On 5 Mar 2019, at 22:00, Wolfgang Knauf <wolfgang.knauf at 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
> 
>