[wildfly-dev] Updating the WildFly archetypes

[Brian Stansberry]

On Tue, Mar 12, 2019 at 2:25 PM Wolfgang Knauf <wolfgang.knauf at 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.
>
>
> Do you agree to this plan ;-)?
>

If you an Eduardo thinks it's better to have something simpler directly in
the archetype rather than syncing in the QS code, that is fine with me.

>
>
> 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
> >
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190312/25bc1654/attachment.html