On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins@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@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@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@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@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@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@gmx.de
>>>>>>> <mailto:wolfgang.knauf@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@gmx.de
>>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>>>>>>>>
>>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>>>>> <wolfgang.knauf@gmx.de <mailto:wolfgang.knauf@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@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat