[wildfly-dev] Updating the WildFly archetypes

[Eduardo Martins]

Webapp-ear sounds a bit weird, perhaps app-ear and app-web instead? :-)

On Mon, 18 Mar 2019 at 21:04, Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:

> OK, so there are two votes (mine and Eduardo's) for "create a blank
> archetype from scratch - no demo source included" and no vote for
> "continue using the quickstart" approach.
>
> Currently, I struggle with the archetype and will send a pull request in
> the next few days.
>
> Any objections against the name "wildfly-javaee-webapp-ear-archetype"
> (which means: a new subdirectory in git)?
>
> If this is done, the next step would be to create a
> "wildfly-javaee-webapp-archetype". And then someone could clean up the
> old archetypes.
>
> I think about adding a small integration test to the web project which
> shows how to create the @Deployment using ShrinkWrap? The test itself
> might have only dummy code, just the creation of the EAR file is
> relevant. This might be helpful to users.
>
> Best regards
>
> Wolfgang
>
> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
> > The archetype sources should actually be simpler to maintain, no need to
> “fix” the imported QS sources... I guess for most releases it would be to
> simply the effort to sync some dependency management versions for the
> generated parent pom, e.g. WildFly BOMs version.
> >
> > Wrt the html5-mobile archetype, I believe it is similar to the ones you
> were looking at, but pointing to an old QS that was removed at some point.
> >
> > —E
> >
> >> On 13 Mar 2019, at 19:14, Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:
> >>
> >>
> >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
> >>>
> >>>> On 12 Mar 2019, at 19:12, 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.
> >>>>
> >>>
> >>> Then why get any sources from QS repo, having a proper do-nothing app
> project all locally sounds better to me, probably less effort needed on
> every release too.
> >>>
> >>> —E
> >>>
> >>
> >> So you prefer to create a blank archetype which has no build
> >> dependencies, just containing the relevant pom.xml files and maybe some
> >> required files (don't know if there are any)? And this archetype is
> >> updated by someone (e.g. me) each time a new major release is done?
> >>
> >> Same applies to the other archetype, "wildfly-javaee7-webapp-archetype”.
> >> The wildfly-archetypes project contains two more archetypes
> >> ("wildfly-html5-mobile-archetype", "wildfly-subsystem-archetype"), but I
> >> did not even take a look at those.
> >>
> >> Personally, I prefer the standalone approach, too. It means more work to
> >> maintain it, but it is simpler ;-)
> >>
> >> Please vote for any of those solutions ;-):
> >> a) continue pulling from KitchensinkEAR quickstart ("blank" archetype
> >> and archetype with a basic project)...
> >> b) create standalone archetype (only "blank" archetype).
> >>
> >>
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190318/5dc2c252/attachment-0001.html