[wildfly-dev] Updating the WildFly archetypes

Tue May 7 04:18:21 EDT 2019

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