[wildfly-dev] Updating the WildFly archetypes
Brian Stansberry
brian.stansberry at redhat.com
Mon Jun 3 11:05:25 EDT 2019
Excellent! Thank you so much Wolfgang!
On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins at redhat.com> wrote:
> Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is out I
> will also deploy the archetype, thanks a lot for your contribution! Yet now
> I have to ask, do you plan to submit similar for the other old javaee
> archetype? :-)
>
> Brian: yep it was just the JDK, I will deploy these too (no planned
> updates in such code tho)
>
> —E
>
> On 16 May 2019, at 10:09, Eduardo Martins <emartins at redhat.com> wrote:
>
> Hmm ok, maybe it just failed build due to some specific like JDK 11, will
> recheck that.
>
> —E
>
> On 16 May 2019, at 02:25, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
> 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
>
>
>
>
--
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/20190603/7e60d89e/attachment-0001.html
More information about the wildfly-dev
mailing list