[wildfly-dev] Updating the WildFly archetypes

Eduardo Martins emartins at redhat.com
Thu May 16 05:09:14 EDT 2019


Hmm ok, maybe it just failed build due to some specific like JDK 11, will recheck that.

—E

> On 16 May 2019, at 02:25, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> These build for me.
> 
> They're not as out of date as I'd thought either.
> 
> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins at redhat.com <mailto:emartins at redhat.com>> wrote:
> If you think it’s not a small effort task then certainly agree that’s not a blocker, I look at the archetypes same way as the quickstarts,  an aggregation project, so we may take outdated/faulty ones out of build and release the working+actual ones. We may give it a thought later if it makes sense effort wise to update or drop the subsystem ones, no worries.
> 
> —E
> 
> On Fri, 10 May 2019 at 21:46, Brian Stansberry <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
> Is that blocking this Eduardo?
> 
> If not, updating those is a pretty big task and right now I don't see it happening anytime soon.
> 
> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins at redhat.com <mailto:emartins at redhat.com>> wrote:
> Brian, any idea what to do wrt the subsystem archetypes? ATM even build fails and most likely there is someone else better than me to look into that…
> 
> —E
> 
> > On 7 May 2019, at 09:18, Eduardo Martins <emartins at redhat.com <mailto:emartins at redhat.com>> wrote:
> > 
> > Hi Wolfgang, I actually did start reviewing it, but unfortunately had to put it on hold due to unexpected blocker kind of priority tasks/issues needed to be solved asap. If nothing urgent comes I should be able to finish the review the next couple of days.
> > 
> > —E
> > 
> >> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf at gmx.de <mailto:wolfgang.knauf at gmx.de>> wrote:
> >> 
> >> Hi,
> >> 
> >> just want to ask for an update ;-)
> >> 
> >> Best regards
> >> 
> >> Wolfgang
> >> 
> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
> >>> I will review it, soon hopefully.
> >>> 
> >>> —E
> >>> 
> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf at gmx.de <mailto:wolfgang.knauf at gmx.de>> wrote:
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> just want to ask about the state of the pull request and further steps...
> >>>> 
> >>>> Best regards
> >>>> 
> >>>> Wolfgang
> >>>> 
> >>>> Am 21.03.19 um 12:47 schrieb Wolfgang Knauf:
> >>>>> OK, I sent a pull request:
> >>>>> https://github.com/wildfly/wildfly-archetypes/pull/3 <https://github.com/wildfly/wildfly-archetypes/pull/3>
> >>>>> 
> >>>>> There already exists a JIRA (created by myself):
> >>>>> https://issues.jboss.org/browse/WFLY-9703 <https://issues.jboss.org/browse/WFLY-9703> - but I cannot assign it to
> >>>>> myself, probably because I only have the role "jira user".
> >>>>> 
> >>>>> Next steps (if the pull request is accepted):
> >>>>> -someone has to release if to maven central. See the release scripts in
> >>>>> the wildfly-archetypes root. This is probably something that has to done
> >>>>> by the JBoss team.
> >>>>> -the old archetype can be removed.
> >>>>> -I will create a similar archetype replacement for
> >>>>> "wildfly-javaee7-webapp-archetype"
> >>>>> 
> >>>>> 
> >>>>> Wolfgang
> >>>>> 
> >>>>> Am 19.03.19 um 12:09 schrieb Wolfgang Knauf:
> >>>>>> 
> >>>>>> Am 18.03.19 um 22:49 schrieb Eduardo Martins:
> >>>>>>> Webapp-ear sounds a bit weird, perhaps app-ear and app-web instead? :-)
> >>>>>> 
> >>>>>> 
> >>>>>> What do you think about "wildfly-javaee-ear-archetype" and
> >>>>>> "wildfly-javaee-web-archetype"?
> >>>>>> 
> >>>>>> 
> >>>>>> Attached is a suggested integration test prototype, which shows how to
> >>>>>> create the EAR file using ShrinkWrap. The test code will be placed in
> >>>>>> the web module. The kitchensink quickstart had the tests in the EJB jar,
> >>>>>> but this is the wrong place if you also want to test the web layer.
> >>>>>> 
> >>>>>> If this is all sound OK, I will start committing it to my git repository
> >>>>>> and sending the pull request.
> >>>>>> 
> >>>>>> Best regards
> >>>>>> 
> >>>>>> Wolfgang
> >>>>>> 
> >>>>>>> 
> >>>>>>> On Mon, 18 Mar 2019 at 21:04, Wolfgang Knauf <wolfgang.knauf at gmx.de <mailto:wolfgang.knauf at gmx.de>
> >>>>>>> <mailto:wolfgang.knauf at gmx.de <mailto: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 <mailto:wolfgang.knauf at gmx.de>
> >>>>>>>     <mailto:wolfgang.knauf at gmx.de <mailto: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 <mailto:wolfgang.knauf at gmx.de> <mailto:wolfgang.knauf at gmx.de <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >>>>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >>> 
> >>> 
> >> 
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> > 
> 
> 
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
> 
> 
> -- 
> 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/20190516/9b6056e5/attachment-0001.html 


More information about the wildfly-dev mailing list