[wildfly-dev] Updating the WildFly archetypes
Brian Stansberry
brian.stansberry at redhat.com
Wed May 15 21:25:44 EDT 2019
These build for me.
They're not as out of date as I'd thought either.
On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins at redhat.com> wrote:
> If you think it’s not a small effort task then certainly agree that’s not
> a blocker, I look at the archetypes same way as the quickstarts, an
> aggregation project, so we may take outdated/faulty ones out of build and
> release the working+actual ones. We may give it a thought later if it makes
> sense effort wise to update or drop the subsystem ones, no worries.
>
> —E
>
> On Fri, 10 May 2019 at 21:46, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> Is that blocking this Eduardo?
>>
>> If not, updating those is a pretty big task and right now I don't see it
>> happening anytime soon.
>>
>> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins at redhat.com>
>> wrote:
>>
>>> 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
>>> >
>>>
>>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190515/af5c67aa/attachment-0001.html
More information about the wildfly-dev
mailing list