[wildfly-dev] Updating the WildFly archetypes

Eduardo Martins emartins at redhat.com
Fri May 10 16:10:06 EDT 2019 

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> 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> 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> 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 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>> 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>> 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
>>> 
>>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

More information about the wildfly-dev mailing list