Re: [wildfly-dev] Updating the WildFly archetypes

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