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(a)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(a)redhat.com
>>>> <mailto:emartins@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(a)redhat.com
>>>>> <mailto:emartins@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(a)redhat.com
>>>>>> <mailto:brian.stansberry@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(a)redhat.com
<mailto: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
>>>>>>