Re: [wildfly-dev] Updating the WildFly archetypes

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