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(a)gmx.de> wrote:
Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>
>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <wolfgang.knauf(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev