[wildfly-dev] Updating the WildFly archetypes

[Wolfgang Knauf]

Hi Eduardo,

i sent a pull request for this new archetype, without beans.xml.
Depending on your findings, we can add it afterwards if necessary.

But as far as I understand it, this file is optional now
(https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
- so this could be considered a bug...

Best regards

Wolfgang


Am 12.06.19 um 22:37 schrieb Eduardo Martins:
> Hi Wolfgang, when reviewing it seemed to me that in the *ear* archetype the beans.xml was not needed. I can’t tell if that’s the case for this new archetype without you submitting it for review, but if it fails to deploy without it… ;-)
>
> —E
>
>> On 12 Jun 2019, at 20:57, Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:
>>
>> Hi to all,
>>
>> just wanted to ask for an update: do you think that the error message is
>> acceptable and I should create the archetype without "beans.xml" anyway
>> (and add an info to the readme.txt file)?
>> Or should I add a default "beans.xml" to the archetype to avoid it?
>> Or is it worth a JIRA?
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>> Hi Eduardo,
>>>
>>> while building a "wildfly-javaee-webapp-archetype", I think I found a
>>> small WildFly issue: you remember that you pointed me to the fact that
>>> "beans.xml" is optional?
>>> But when creating a blank project from my new web archetype (which
>>> defines a "faces-config.xml", but no "beans.xml"), the attached error is
>>> in the WildFly console. But it seems the app is deployed anyway.
>>>
>>> The error disappears if I add e.g. an annotated EJB, or if I add a
>>> "beans.xml".
>>>
>>> Do you think this is a WildFly bug? Or should I add a default
>>> "beans.xml" just to avoid this error?
>>>
>>> I did not test it with a blank project from the EAR archetype - will do
>>> this in the next few days.
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>>
>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>> Thanks for the deploy, Eduardo!
>>>>
>>>> If you consider it reasonable I will create an archetype for "web app
>>>> only", similar to the old "wildfly-javaee7-webapp-archetype".
>>>> But I will probably need a few weeks...
>>>>
>>>> What happens to the old archetype
>>>> "wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as it
>>>> does not build anyway. It might be relevant only for research.
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>>
>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>> Excellent!  Thank you so much Wolfgang!
>>>>>
>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins at redhat.com
>>>>> <mailto: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
>>>>>>      <mailto: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
>>>>>>>      <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
>>>>>>>
>
>