[wildfly-dev] Updating the WildFly archetypes

Wolfgang Knauf wolfgang.knauf at gmx.de
Mon May 6 15:50:13 EDT 2019


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
>
>



More information about the wildfly-dev mailing list