[wildfly-dev] Updating the WildFly archetypes

[Brian Stansberry]

Hi Wolfgang,

I've reached out to try and find out the process for making changes to
maven-qstools-plugin, which has been inactive for a couple years.

The "copy in the pom after" idea could work fine too. It's a bit
convoluted, but really so is the whole archetype sync. :)

Best regards,
Brian


On Wed, Mar 6, 2019 at 2:54 PM Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:

> Here is another idea to avoid modifications to the qstools plugin:
>
> As written below, the root pom for the resulting archetype application
> is not pulled from kitchensink, but is placed in some directory in the
> archetype source tree, e.g.
> "wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\archetype_files"
> (this is probably a non-standard dir - do you have better suggestions?)
>
> The "maven-resources-plugin" copies this file to
> "${basedir}/target/classes/archetype-resources". If this copying takes
> place after the "qstools:archetypeSync" was done, it will overwrite the
> file pulled from the kitchensink app.
>
> What do you think?
>
> At least it works for me - the archetype can be built.
>
> Attached file "snippet_pom.xml" contains the snippet for
> "wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\pom.xml" which
> defines this file copying.
>
> The attached file "pom.xml" is the static file for the archetype -
> stills needs a bit of tuning...
>
> Greetings
>
> Wolfgang
>
>
> Am 05.03.19 um 23:00 schrieb Wolfgang Knauf:
> > 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
> >
> _______________________________________________
> 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/20190306/bd973dd8/attachment.html