[wildfly-dev] Updating the WildFly archetypes
Wolfgang Knauf
wolfgang.knauf at gmx.de
Thu May 16 16:14:09 EDT 2019
You mean "wildfly-subsystem-archetype", building with "mvn clean install
-Dmodule=some.module.name"?
They build for me using Java 1.8 and Java 11 (Win7, Maven 3.6.0).
But when built with Java 11, there is a message "command cmd not found"
(translated) - not an error, just a message. But the build seems to finish.
But I don't know this archetype...
Wolfgang
Am 16.05.19 um 11:09 schrieb Eduardo Martins:
> 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 <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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>
>> >>>>>>> <mailto: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>
>> >>>>>>> <mailto: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>
>> <mailto: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
>> <mailto:wildfly-dev at lists.jboss.org>
>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> wildfly-dev mailing list
>> >>>> wildfly-dev at lists.jboss.org
>> <mailto:wildfly-dev at lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> <mailto: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
>
>
> _______________________________________________
> 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