Re: [wildfly-dev] Updating the WildFly archetypes

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)gmx.de&gt; >> 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(a)gmx.de&gt; >> 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 >> >>>>> >> >>>>> There already exists a JIRA (created by myself): >> >>>>> 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(a)gmx.de >> >>>>>>> <mailto:wolfgang.knauf@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(a)gmx.de >> >>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins: >> >>>>>>>>>> >> >>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf >> >>>>>>> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@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(a)lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> wildfly-dev mailing list >> >>>> wildfly-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>> >> >>> >> >> >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> >> > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat >