[wildfly-dev] Updating the WildFly archetypes
Wolfgang Knauf
wolfgang.knauf at gmx.de
Thu Mar 21 07:47:38 EDT 2019
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
>
More information about the wildfly-dev
mailing list