From wolfgang.knauf at gmx.de  Sat Mar  2 06:55:55 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Sat, 2 Mar 2019 12:55:55 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
Message-ID: <e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>

Hi,

just wanted to send a reminder about the questions below...

Best regards

Wolfgang

Am 24.02.19 um 21:02 schrieb Wolfgang Knauf:
> About problem b from below: I can think of two possibilities to resolve it:
> 
> b.1) modify the qstools class "ArchetypeSyncMojo" so that it merges the 
> "kitchensink-ear" pom.xml and the quickstart pom into one file.
> But I don't like the idea: The quickstarts root pom.xml has 778 lines - 
> this is way too much overhead for a newly created project. So I prefer...
> 
> b.2) creating an archetype from scratch, with only "relevant" snippets 
> in pom.xml and discard the "copy automatically from kitchensink sample" 
> code.
> 
> What do you think? Or is it possible to split the root pom file for the 
> quickstart into a bundle of feature sets? It seems maven does not 
> support this.
> 
> Best regards
> 
> Wolfgang
> 
> Am 22.02.19 um 22:26 schrieb Wolfgang Knauf:
>> Thanks for the reply, Brian. But before discussing the naming scheme, 
>> I would like to understand the concept of the old archetype creation 
>> and make it work again ;-).
>>
>> I made some progress on the failing build, but now I reached a point 
>> where the concept "pulling from the kitchensink-ear app" seems to be 
>> broken by design....
>>
>> To sum it up:
>>
>> a) in the kitchensink sample, the names of the subdirectories ("ear", 
>> "ejb", "war") have changed. This causes the the archetype build to 
>> fail => this error is fixable, see below.
>> But is it intended to provide an archetype with subdirectories "ear", 
>> "ejb" and "war" instead of "myapp-ear", "myapp-ejb" and "myapp-war"? I 
>> prefer the old naming scheme ;-).
>>
>>
>> b) after fixing this, the archetype test will fail:
>>
>> [ERROR]?? The project foo.bar:multi:[unknown-version] 
>> (C:\Temp\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\target\test-classes\projects\multi\project\multi\pom.xml) 
>> has 1 error
>> [ERROR]???? Non-resolvable parent POM for 
>> foo.bar:multi:[unknown-version]: Could not find artifact 
>> foo.bar:multi:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at 
>> wrong local POM @ line 21, column 13 -> [Help 2]
>>
>>
>> The reason is the "relativePath" in "....\kitchensink-ear\pom.xml", 
>> which is the root pom in the archetype:
>>
>>
>> ???? <parent>
>> ???????? <groupId>org.wildfly.quickstarts</groupId>
>> ???????? <artifactId>quickstart-parent</artifactId>
>> ???????? <version>16.0.0.CR1-SNAPSHOT</version>
>> ???????? <relativePath>../pom.xml</relativePath>
>> ???? </parent>
>>
>> ==>of course this parent file is not found in the generated archetype, 
>> thus it fails. This will make the archetype unusable.
>>
>> How to resolve this problem? I don't think that it is a good idea to 
>> include all the stuff from the quickstart pom.xml - that's way too 
>> much for any user generated application. Keep it simple ;-).
>>
>>
>> Best regards
>>
>> Wolfgang
>> ======================================
>>
>> And now a detailed analysis of the first problem (broken build because 
>> of renamed directories) - for those who are interested in the details:
>>
>>
>> When building the "wildfly-javaee7-webapp-ear-archetype", it fails 
>> with this error message:
>>
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-archetype-plugin:2.1:integration-test 
>> (default-integration-test) on project 
>> wildfly-javaee7-webapp-ear-archetype:
>> [ERROR] Archetype IT 'multi' failed: 
>> org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error 
>> merging velocity templates: Unable to find resource 
>> 'archetype-resources/__rootArtifactId__-ejb/pom.xml'
>>
>>
>> Taking a look at the files: in Git you find the files for the 
>> archetype in the subdir 
>> "wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb" 
>>
>> (https://github.com/wildfly/wildfly-archetypes/tree/master/wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb) 
>>
>> Those files shall be overwritten by the build: they are picked from 
>> the kitchensink sample and converted to a archetype version (with some 
>> placeholders like "${rootArtifactId}").
>>
>> After the maven build has failed, 
>> "..../archetype-resources/__rootArtifactId__-ejb" contains only empty 
>> directories - all files inside are deleted.
>> The files that are copied from the kitchensink-ear project are now in 
>> the directories "..../archetype-resources/ear", 
>> ".../archetype-resources/ejb", ".../archetype-resources/web".
>> This is not the place where the tests expect it.
>>
>> See attached screenshot "archetype_structure.png"
>>
>>
>>
>> Now about the explanation:
>> At the time of creation of this archetype project, the 
>> "kitchensink-ear" module had three submodules 
>> "wildfly-kitchensink-ear-ear", "wildfly-kitchensink-ear-ejb" and 
>> "wildfly-kitchensink-ear-web".
>>
>> Here are old sources:
>> https://github.com/wildfly/quickstart/tree/ed12afad407a2946b85db37bfeec1d2d1dd0201d/kitchensink-ear 
>>
>>
>>
>> In the file 
>> "wildfly-archetypes\wildfly-javaee7-webapp-archetype\pom.xml", there 
>> are defined several archetype replacement rules for the "qstools" 
>> plugin. One is this:
>>
>> <archetypeExpressionReplaceValue>wildfly-kitchensink</archetypeExpressionReplaceValue> 
>>
>> This means: in all path components containing "wildfly-kitchensink" 
>> this will be replaced by "__rootArtifactId__"
>> E.g. "wildfly-kitchensink-ear-ejb" will become 
>> ""__rootArtifactId__ear-ejb"
>>
>>
>> See source code for the replacements at 
>> https://github.com/jboss-developer/maven-qstools-plugin/blob/master/src/main/java/org/jboss/maven/plugins/qstools/ArchetypeSyncMojo.java 
>>
>>
>>
>> BUT the "kitchensink-ear" module has three submodules "ear", "ejb" and 
>> "web". So, no replacement occurs, and the files are copied to 
>> ".../archetype-resources/ejb" instead of 
>> ".../archetype-resources/__rootArtifactId__-ejb".
>>
>>
>> This error is fixable if the file 
>> "...\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\src\main\resources\META-INF\maven\archetype-metadata.xml" 
>>
>> is changed:
>> replace
>> ??? <module id="ejb" dir="__rootArtifactId__-ejb" name="ejb">
>> with:
>> ??? <module id="ejb" dir="ejb" name="ejb">
>>
>>
>>
>>
>>
>>
>> Am 22.02.19 um 05:05 schrieb Brian Stansberry:
>>>
>>>
>>> On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf <wolfgang.knauf at gmx.de 
>>> <mailto:wolfgang.knauf at gmx.de>> wrote:
>>>
>>> ??? OK, after some digging around: the archetypes are generated based on
>>> ??? the
>>> ??? "Kitchensink" quickstart. So, actually there should be not much 
>>> changes
>>> ??? to the archetype files itself, just a "rebuild". But currently, a
>>> ??? "maven
>>> ??? install" for the archetype fails for me. More research needed...
>>>
>>> Oops; I missed this post and responded to your first one! Thanks for 
>>> digging into this!
>>>
>>> ??? Wolfgang
>>>
>>>
>>>
>>> ??? Am 19.02.19 um 22:12 schrieb Wolfgang Knauf:
>>> ???? > Hi,
>>> ???? >
>>> ???? > the archetypes at https://github.com/wildfly/wildfly-archetypes
>>> ???? >? ? (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for
>>> ??? WildFly 8,
>>> ???? > and when updating the WildFly version in pom.xmls, a lot of 
>>> further
>>> ???? > changes is required, see 
>>> https://issues.jboss.org/browse/WFLY-9703
>>> ???? > (which is only part of the changes).
>>> ???? >
>>> ???? > I am interested in creating new archetypes for WildFly 15. What
>>> ??? do you
>>> ???? > think?
>>> ???? >
>>> ???? > My plan is to name them e.g.
>>> ???? > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a 
>>> new
>>> ???? > archetype version each time a new WildFly major version is 
>>> released.
>>> ???? >
>>> ???? > If you are OK with this, I will struggle with my first steps in
>>> ??? Git, and
>>> ???? > I probably will ask some more or less dumb questions about
>>> ??? details ;-).
>>> ???? >
>>> ???? > Best regards
>>> ???? >
>>> ???? > Wolfgang
>>> ???? > _______________________________________________
>>> ???? > wildfly-dev mailing list
>>> ???? > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> ???? > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> ???? >
>>> ??? _______________________________________________
>>> ??? wildfly-dev mailing list
>>> ??? wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> ??? https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>> -- 
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat

From brian.stansberry at redhat.com  Mon Mar  4 18:27:43 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 4 Mar 2019 17:27:43 -0600
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
Message-ID: <CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>

On Sat, Mar 2, 2019 at 5:58 AM Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:

> Hi,
>
> just wanted to send a reminder about the questions below...
>
> Best regards
>
> Wolfgang
>
> Am 24.02.19 um 21:02 schrieb Wolfgang Knauf:
> > About problem b from below: I can think of two possibilities to resolve
> it:
> >
> > b.1) modify the qstools class "ArchetypeSyncMojo" so that it merges the
> > "kitchensink-ear" pom.xml and the quickstart pom into one file.
> > But I don't like the idea: The quickstarts root pom.xml has 778 lines -
> > this is way too much overhead for a newly created project. So I prefer...
> >
> > b.2) creating an archetype from scratch, with only "relevant" snippets
> > in pom.xml and discard the "copy automatically from kitchensink sample"
> > code.
> >
> > What do you think? Or is it possible to split the root pom file for the
> > quickstart into a bundle of feature sets? It seems maven does not
> > support this.
>

TBH, I'm learning this stuff as I read these posts. I'd never heard of
an ArchetypeSyncMojo
before. ;) So it seems it ...

a) Deletes whatever is in src/main/resources/archetypes.
b) Copies into src/main/resources/archetypes what's in
https://github.com/wildfly/quickstart/tree/master/kitchensink-ear (or
whatever git repo the plugin config points to)
c) Does some text replacement.

I doubt we'd want to modify the quickstart code in any significant way, not
unless Eduardo Martins wants to for some other reason. I get what you're
saying though about how copying in the QS code means the new project pom
would depend on the root QS pom, which is not usable. Even if we could work
around the <relativePath>../pom.xml</relativePath> problem, I don't think
users would want their app to have our QS root pom as its parent.

And yes, your b.1 sounds like too much. I expect it would break regularly.

AIUI your b.2 means decoupling the archetype from the QS code and instead
directly having the app code in the wildfly-archetypes codebase. The
downside to that is now there's another example app to maintain. (More than
one really, as there would be one per archetype.)

I think the key thing is this would need to be low maintenance. The root QS
depends on the wildfly-bom[1] so if there aren't a lot of version
dependencies that would need to be in the archetype poms that will help. Is
your impression that the archetype pom would be low maintenance?

[1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109

> >
> > Best regards
> >
> > Wolfgang
> >
> > Am 22.02.19 um 22:26 schrieb Wolfgang Knauf:
> >> Thanks for the reply, Brian. But before discussing the naming scheme,
> >> I would like to understand the concept of the old archetype creation
> >> and make it work again ;-).
> >>
> >> I made some progress on the failing build, but now I reached a point
> >> where the concept "pulling from the kitchensink-ear app" seems to be
> >> broken by design....
> >>
> >> To sum it up:
> >>
> >> a) in the kitchensink sample, the names of the subdirectories ("ear",
> >> "ejb", "war") have changed. This causes the the archetype build to
> >> fail => this error is fixable, see below.
> >> But is it intended to provide an archetype with subdirectories "ear",
> >> "ejb" and "war" instead of "myapp-ear", "myapp-ejb" and "myapp-war"? I
> >> prefer the old naming scheme ;-).
> >>
> >>
> >> b) after fixing this, the archetype test will fail:
> >>
> >> [ERROR]   The project foo.bar:multi:[unknown-version]
> >>
> (C:\Temp\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\target\test-classes\projects\multi\project\multi\pom.xml)
>
> >> has 1 error
> >> [ERROR]     Non-resolvable parent POM for
> >> foo.bar:multi:[unknown-version]: Could not find artifact
> >> foo.bar:multi:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at
> >> wrong local POM @ line 21, column 13 -> [Help 2]
> >>
> >>
> >> The reason is the "relativePath" in "....\kitchensink-ear\pom.xml",
> >> which is the root pom in the archetype:
> >>
> >>
> >>      <parent>
> >>          <groupId>org.wildfly.quickstarts</groupId>
> >>          <artifactId>quickstart-parent</artifactId>
> >>          <version>16.0.0.CR1-SNAPSHOT</version>
> >>          <relativePath>../pom.xml</relativePath>
> >>      </parent>
> >>
> >> ==>of course this parent file is not found in the generated archetype,
> >> thus it fails. This will make the archetype unusable.
> >>
> >> How to resolve this problem? I don't think that it is a good idea to
> >> include all the stuff from the quickstart pom.xml - that's way too
> >> much for any user generated application. Keep it simple ;-).
> >>
> >>
> >> Best regards
> >>
> >> Wolfgang
> >> ======================================
> >>
> >> And now a detailed analysis of the first problem (broken build because
> >> of renamed directories) - for those who are interested in the details:
> >>
> >>
> >> When building the "wildfly-javaee7-webapp-ear-archetype", it fails
> >> with this error message:
> >>
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-archetype-plugin:2.1:integration-test
> >> (default-integration-test) on project
> >> wildfly-javaee7-webapp-ear-archetype:
> >> [ERROR] Archetype IT 'multi' failed:
> >> org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error
> >> merging velocity templates: Unable to find resource
> >> 'archetype-resources/__rootArtifactId__-ejb/pom.xml'
> >>
> >>
> >> Taking a look at the files: in Git you find the files for the
> >> archetype in the subdir
> >>
> "wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb"
>
> >>
> >> (
> https://github.com/wildfly/wildfly-archetypes/tree/master/wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb)
>
> >>
> >> Those files shall be overwritten by the build: they are picked from
> >> the kitchensink sample and converted to a archetype version (with some
> >> placeholders like "${rootArtifactId}").
> >>
> >> After the maven build has failed,
> >> "..../archetype-resources/__rootArtifactId__-ejb" contains only empty
> >> directories - all files inside are deleted.
> >> The files that are copied from the kitchensink-ear project are now in
> >> the directories "..../archetype-resources/ear",
> >> ".../archetype-resources/ejb", ".../archetype-resources/web".
> >> This is not the place where the tests expect it.
> >>
> >> See attached screenshot "archetype_structure.png"
> >>
> >>
> >>
> >> Now about the explanation:
> >> At the time of creation of this archetype project, the
> >> "kitchensink-ear" module had three submodules
> >> "wildfly-kitchensink-ear-ear", "wildfly-kitchensink-ear-ejb" and
> >> "wildfly-kitchensink-ear-web".
> >>
> >> Here are old sources:
> >>
> https://github.com/wildfly/quickstart/tree/ed12afad407a2946b85db37bfeec1d2d1dd0201d/kitchensink-ear
> >>
> >>
> >>
> >> In the file
> >> "wildfly-archetypes\wildfly-javaee7-webapp-archetype\pom.xml", there
> >> are defined several archetype replacement rules for the "qstools"
> >> plugin. One is this:
> >>
> >>
> <archetypeExpressionReplaceValue>wildfly-kitchensink</archetypeExpressionReplaceValue>
>
> >>
> >> This means: in all path components containing "wildfly-kitchensink"
> >> this will be replaced by "__rootArtifactId__"
> >> E.g. "wildfly-kitchensink-ear-ejb" will become
> >> ""__rootArtifactId__ear-ejb"
> >>
> >>
> >> See source code for the replacements at
> >>
> https://github.com/jboss-developer/maven-qstools-plugin/blob/master/src/main/java/org/jboss/maven/plugins/qstools/ArchetypeSyncMojo.java
> >>
> >>
> >>
> >> BUT the "kitchensink-ear" module has three submodules "ear", "ejb" and
> >> "web". So, no replacement occurs, and the files are copied to
> >> ".../archetype-resources/ejb" instead of
> >> ".../archetype-resources/__rootArtifactId__-ejb".
> >>
> >>
> >> This error is fixable if the file
> >>
> "...\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\src\main\resources\META-INF\maven\archetype-metadata.xml"
>
> >>
> >> is changed:
> >> replace
> >>     <module id="ejb" dir="__rootArtifactId__-ejb" name="ejb">
> >> with:
> >>     <module id="ejb" dir="ejb" name="ejb">
> >>
> >>
> >>
> >>
> >>
> >>
> >> Am 22.02.19 um 05:05 schrieb Brian Stansberry:
> >>>
> >>>
> >>> On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf <wolfgang.knauf at gmx.de
> >>> <mailto:wolfgang.knauf at gmx.de>> wrote:
> >>>
> >>>     OK, after some digging around: the archetypes are generated based
> on
> >>>     the
> >>>     "Kitchensink" quickstart. So, actually there should be not much
> >>> changes
> >>>     to the archetype files itself, just a "rebuild". But currently, a
> >>>     "maven
> >>>     install" for the archetype fails for me. More research needed...
> >>>
> >>> Oops; I missed this post and responded to your first one! Thanks for
> >>> digging into this!
> >>>
> >>>     Wolfgang
> >>>
> >>>
> >>>
> >>>     Am 19.02.19 um 22:12 schrieb Wolfgang Knauf:
> >>>      > Hi,
> >>>      >
> >>>      > the archetypes at https://github.com/wildfly/wildfly-archetypes
> >>>      >    (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for
> >>>     WildFly 8,
> >>>      > and when updating the WildFly version in pom.xmls, a lot of
> >>> further
> >>>      > changes is required, see
> >>> https://issues.jboss.org/browse/WFLY-9703
> >>>      > (which is only part of the changes).
> >>>      >
> >>>      > I am interested in creating new archetypes for WildFly 15. What
> >>>     do you
> >>>      > think?
> >>>      >
> >>>      > My plan is to name them e.g.
> >>>      > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a
> >>> new
> >>>      > archetype version each time a new WildFly major version is
> >>> released.
> >>>      >
> >>>      > If you are OK with this, I will struggle with my first steps in
> >>>     Git, and
> >>>      > I probably will ask some more or less dumb questions about
> >>>     details ;-).
> >>>      >
> >>>      > Best regards
> >>>      >
> >>>      > Wolfgang
> >>>      > _______________________________________________
> >>>      > wildfly-dev mailing list
> >>>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org
> >
> >>>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>      >
> >>>     _______________________________________________
> >>>     wildfly-dev mailing list
> >>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>>
> >>>
> >>> --
> >>> Brian Stansberry
> >>> Manager, Senior Principal Software Engineer
> >>> Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190304/daccceec/attachment-0001.html 

From dvilkola at redhat.com  Tue Mar  5 12:57:52 2019
From: dvilkola at redhat.com (Diana Vilkolakova)
Date: Tue, 5 Mar 2019 18:57:52 +0100
Subject: [wildfly-dev] [WFLY-11697] WS integration with Elytron on the
	client side
Message-ID: <CAHvwbVdAddRcieKs_bp3bkUagCr51xNNX-223iik+r_N26tXrg@mail.gmail.com>

Hello All,
I've created a proposal [1] for WS client integration with Elytron.
Any feedback is
welcomed.

[1]: https://github.com/wildfly/wildfly-proposals/pull/174
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190305/6dd13c36/attachment.html 

From darran.lofthouse at jboss.com  Tue Mar  5 13:41:30 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 5 Mar 2019 18:41:30 +0000
Subject: [wildfly-dev] WildFly 17 Security Features
Message-ID: <CAMxVf4Pyrot0OB59Grm0nYEuQTCSH5nQ52WYnOe2EuY3NLSZjg@mail.gmail.com>

Here is a blog post highlighting the security features we are hoping to be
delivering during WildFly 17: -

https://darranl.blogspot.com/2019/03/security-features-for-wildfly-17.html

Regards,
Darran Lofthouse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190305/5993f203/attachment.html 

From wolfgang.knauf at gmx.de  Tue Mar  5 17:00:03 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Tue, 5 Mar 2019 23:00:03 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
Message-ID: <1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>

Hi Brian,

Am 05.03.19 um 00:27 schrieb Brian Stansberry:

> 
> AIUI your b.2 means decoupling the archetype from the QS code and 
> instead directly having the app code in the wildfly-archetypes codebase. 
> The downside to that is now there's another example app to maintain. 
> (More than one really, as there would be one per archetype.)
> 
> I think the key thing is this would need to be low maintenance. The root 
> QS depends on the wildfly-bom[1] so if there aren't a lot of version 
> dependencies that would need to be in the archetype poms that will help. 
> Is your impression that the archetype pom would be low maintenance?
> 
> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
> 

yes, this sounds like a very good idea: edit and maintain the root pom 
of the archetype in the "archetype-resources" directory and sync only 
all other files. This mean a bit of work each time the archetype is 
updated for a new WildFly version, but less work than editing all files.

The only downside: I think the "ArchetypeSyncMojo" must be modified and 
a "excludedFiles" property added, so that a sync will not overwrite the 
archetype pom with the quickstart file.

I hope I can do this, if you think this sounds reasonable ;-).

Who is responsible for the maven-qstools-plugin? Probably he/she should 
agree to those plans, too... And my change would have to be merged and a 
new release of 1.7.0 (or 1.7.1?) to maven central would have to be 
triggered. As this is my first step in WildFly coding, I am new to all 
this stuff.

Best regards

Wolfgang

From wolfgang.knauf at gmx.de  Wed Mar  6 15:36:32 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Wed, 6 Mar 2019 21:36:32 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
Message-ID: <5bb8aebd-c44f-4656-5762-93f4f3e91bf8@gmx.de>

Here is another idea to avoid modifications to the qstools plugin:

As written below, the root pom for the resulting archetype application 
is not pulled from kitchensink, but is placed in some directory in the 
archetype source tree, e.g. 
"wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\archetype_files" 
(this is probably a non-standard dir - do you have better suggestions?)

The "maven-resources-plugin" copies this file to 
"${basedir}/target/classes/archetype-resources". If this copying takes 
place after the "qstools:archetypeSync" was done, it will overwrite the 
file pulled from the kitchensink app.

What do you think?

At least it works for me - the archetype can be built.

Attached file "snippet_pom.xml" contains the snippet for 
"wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\pom.xml" which 
defines this file copying.

The attached file "pom.xml" is the static file for the archetype - 
stills needs a bit of tuning...

Greetings

Wolfgang


Am 05.03.19 um 23:00 schrieb Wolfgang Knauf:
> Hi Brian,
> 
> Am 05.03.19 um 00:27 schrieb Brian Stansberry:
> 
>>
>> AIUI your b.2 means decoupling the archetype from the QS code and
>> instead directly having the app code in the wildfly-archetypes codebase.
>> The downside to that is now there's another example app to maintain.
>> (More than one really, as there would be one per archetype.)
>>
>> I think the key thing is this would need to be low maintenance. The root
>> QS depends on the wildfly-bom[1] so if there aren't a lot of version
>> dependencies that would need to be in the archetype poms that will help.
>> Is your impression that the archetype pom would be low maintenance?
>>
>> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
>>
> 
> yes, this sounds like a very good idea: edit and maintain the root pom
> of the archetype in the "archetype-resources" directory and sync only
> all other files. This mean a bit of work each time the archetype is
> updated for a new WildFly version, but less work than editing all files.
> 
> The only downside: I think the "ArchetypeSyncMojo" must be modified and
> a "excludedFiles" property added, so that a sync will not overwrite the
> archetype pom with the quickstart file.
> 
> I hope I can do this, if you think this sounds reasonable ;-).
> 
> Who is responsible for the maven-qstools-plugin? Probably he/she should
> agree to those plans, too... And my change would have to be merged and a
> new release of 1.7.0 (or 1.7.1?) to maven central would have to be
> triggered. As this is my first step in WildFly coding, I am new to all
> this stuff.
> 
> Best regards
> 
> Wolfgang
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snippet_pom.xml
Type: text/xml
Size: 1139 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190306/b79f45a9/attachment.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pom.xml
Type: text/xml
Size: 8099 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190306/b79f45a9/attachment-0001.xml 

From jucook at redhat.com  Wed Mar  6 16:53:42 2019
From: jucook at redhat.com (Justin Cook)
Date: Wed, 6 Mar 2019 16:53:42 -0500
Subject: [wildfly-dev] [ELY-1712] Proposal for Enhanced Audit Logging in
	Elytron
Message-ID: <CABXKk4BZyeeb_-5YL8LY7LF6wOR6=TKxpZCHHt-wSNvtvyyS8A@mail.gmail.com>

Hello All,
I've created a proposal [1] to enhance audit logging in Elytron. Any
feedback is welcome.

[1] https://github.com/wildfly/wildfly-proposals/pull/184
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190306/4430ace0/attachment-0001.html 

From brian.stansberry at redhat.com  Wed Mar  6 17:27:32 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 6 Mar 2019 16:27:32 -0600
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <5bb8aebd-c44f-4656-5762-93f4f3e91bf8@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<5bb8aebd-c44f-4656-5762-93f4f3e91bf8@gmx.de>
Message-ID: <CAPhbRDae3wmY8dGujQ7zfEb71BR8iHjT9PK-OVTEALGUTtT3rA@mail.gmail.com>

Hi Wolfgang,

I've reached out to try and find out the process for making changes to
maven-qstools-plugin, which has been inactive for a couple years.

The "copy in the pom after" idea could work fine too. It's a bit
convoluted, but really so is the whole archetype sync. :)

Best regards,
Brian


On Wed, Mar 6, 2019 at 2:54 PM Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:

> Here is another idea to avoid modifications to the qstools plugin:
>
> As written below, the root pom for the resulting archetype application
> is not pulled from kitchensink, but is placed in some directory in the
> archetype source tree, e.g.
> "wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\archetype_files"
> (this is probably a non-standard dir - do you have better suggestions?)
>
> The "maven-resources-plugin" copies this file to
> "${basedir}/target/classes/archetype-resources". If this copying takes
> place after the "qstools:archetypeSync" was done, it will overwrite the
> file pulled from the kitchensink app.
>
> What do you think?
>
> At least it works for me - the archetype can be built.
>
> Attached file "snippet_pom.xml" contains the snippet for
> "wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\pom.xml" which
> defines this file copying.
>
> The attached file "pom.xml" is the static file for the archetype -
> stills needs a bit of tuning...
>
> Greetings
>
> Wolfgang
>
>
> Am 05.03.19 um 23:00 schrieb Wolfgang Knauf:
> > Hi Brian,
> >
> > Am 05.03.19 um 00:27 schrieb Brian Stansberry:
> >
> >>
> >> AIUI your b.2 means decoupling the archetype from the QS code and
> >> instead directly having the app code in the wildfly-archetypes codebase.
> >> The downside to that is now there's another example app to maintain.
> >> (More than one really, as there would be one per archetype.)
> >>
> >> I think the key thing is this would need to be low maintenance. The root
> >> QS depends on the wildfly-bom[1] so if there aren't a lot of version
> >> dependencies that would need to be in the archetype poms that will help.
> >> Is your impression that the archetype pom would be low maintenance?
> >>
> >> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
> >>
> >
> > yes, this sounds like a very good idea: edit and maintain the root pom
> > of the archetype in the "archetype-resources" directory and sync only
> > all other files. This mean a bit of work each time the archetype is
> > updated for a new WildFly version, but less work than editing all files.
> >
> > The only downside: I think the "ArchetypeSyncMojo" must be modified and
> > a "excludedFiles" property added, so that a sync will not overwrite the
> > archetype pom with the quickstart file.
> >
> > I hope I can do this, if you think this sounds reasonable ;-).
> >
> > Who is responsible for the maven-qstools-plugin? Probably he/she should
> > agree to those plans, too... And my change would have to be merged and a
> > new release of 1.7.0 (or 1.7.1?) to maven central would have to be
> > triggered. As this is my first step in WildFly coding, I am new to all
> > this stuff.
> >
> > Best regards
> >
> > Wolfgang
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190306/bd973dd8/attachment.html 

From wolfgang.knauf at gmx.de  Thu Mar  7 16:25:51 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Thu, 7 Mar 2019 22:25:51 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <CAPhbRDae3wmY8dGujQ7zfEb71BR8iHjT9PK-OVTEALGUTtT3rA@mail.gmail.com>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<5bb8aebd-c44f-4656-5762-93f4f3e91bf8@gmx.de>
	<CAPhbRDae3wmY8dGujQ7zfEb71BR8iHjT9PK-OVTEALGUTtT3rA@mail.gmail.com>
Message-ID: <1dfbcbc5-c4d3-f92b-7617-5cb57ab6d91e@gmx.de>

Hi Brian,

ok, I think now I can start reworking the archetype...

What name do you suggest? "wildfly-javaee-webapp-ear-archetype" - just 
remove the "7" from the current archetype.
This means:
a) rename the "wildfly-javaee7-webapp-ear-archetype" directory in GIT?
or
b) create a new project?

========================
Two more questions:

there is a file "kitchensink-ear\readme.adoc", which is added to the 
archetype.

But this will probably not work in the archetype, because it includes of 
other adoc files in "../shared-doc"

Just remove it? I might also add a static file, like the "readme.md" 
from the old archetype if necessary - but if it is static, it should 
explain the archetype itself.

==========================

There is a profile "arq-managed" defined in 
https://github.com/wildfly/quickstart/blob/master/pom.xml, which I would 
also copy to the static archetype pom.xml.

I assume it does not work the way it is declared in the quickstart root 
"pom.xml":

When running the "arq-managed" profile (after copying it to my sample 
application), I see this error:
org.jboss.arquillian.container.spi.client.container.LifecycleException: 
Could not start container
Caused by: java.lang.IllegalArgumentException: WFLYLNCHR0001: The path 
'null' does not exist

Does it work for you in the quickstarts?

As far as I know, it requires also the maven-dependency-plugin which 
downloads the Wildfly server, and it needs a "systemPropertyVariables" 
named "jboss.home" pointing to the WildFly download - see snippet below.

Or did you resolve this otherwise? Does it work if an environment 
variable JBOSS_HOME is present and set outside?
The quickstart pom.xml defines "jboss.home.name"


Adding my snippet to download the WildFly server to the root pom is not 
smart - downloading and unpacking the wildFly server will be executed 
before EJB and WAR project are scanned for tests, thus running twice - 
so it would be better to just comment it and add an explanation "copy 
this to the EJB/WAR pom.xml where the tests are located"?

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-dependency-plugin</artifactId>
	<version>3.0.2</version>
	<executions>
		<execution>
			<id>unpack</id>
			<phase>pre-integration-test</phase>
			<goals>
				<goal>unpack</goal>
			</goals>
			<configuration>
				<artifactItems>
					<artifactItem>
						<groupId>org.wildfly</groupId>
						<artifactId>wildfly-dist</artifactId>
						<version>${version.wildfly}</version>
						<type>zip</type>
						<overWrite>false</overWrite>
						<outputDirectory>target</outputDirectory>
					</artifactItem>
				</artifactItems>
			</configuration>
		</execution>
	</executions>
</plugin>

<plugin>
	<artifactId>maven-failsafe-plugin</artifactId>
	<version>${version.failsafe.plugin}</version>
	<executions>
		<execution>
			<goals>
				<goal>integration-test</goal>
				<goal>verify</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<systemPropertyVariables>
		 
<jboss.home>${project.basedir}/target/wildfly-${version.wildfly}</jboss.home>
		</systemPropertyVariables>
	</configuration>
</plugin>

Thanks

Wolfgang

Am 06.03.19 um 23:27 schrieb Brian Stansberry:
> Hi?Wolfgang,
> 
> I've reached out to try and find out the process for making changes to 
> maven-qstools-plugin, which has been inactive for a couple years.
> 
> The "copy in the pom after" idea could work fine too. It's a bit 
> convoluted, but really so is the whole archetype sync. :)
> 
> Best regards,
> Brian
> 
> 
> On Wed, Mar 6, 2019 at 2:54 PM Wolfgang Knauf <wolfgang.knauf at gmx.de 
> <mailto:wolfgang.knauf at gmx.de>> wrote:
> 
>     Here is another idea to avoid modifications to the qstools plugin:
> 
>     As written below, the root pom for the resulting archetype application
>     is not pulled from kitchensink, but is placed in some directory in the
>     archetype source tree, e.g.
>     "wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\archetype_files"
> 
>     (this is probably a non-standard dir - do you have better suggestions?)
> 
>     The "maven-resources-plugin" copies this file to
>     "${basedir}/target/classes/archetype-resources". If this copying takes
>     place after the "qstools:archetypeSync" was done, it will overwrite the
>     file pulled from the kitchensink app.
> 
>     What do you think?
> 
>     At least it works for me - the archetype can be built.
> 
>     Attached file "snippet_pom.xml" contains the snippet for
>     "wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\pom.xml" which
>     defines this file copying.
> 
>     The attached file "pom.xml" is the static file for the archetype -
>     stills needs a bit of tuning...
> 
>     Greetings
> 
>     Wolfgang
> 
> 
>     Am 05.03.19 um 23:00 schrieb Wolfgang Knauf:
>      > Hi Brian,
>      >
>      > Am 05.03.19 um 00:27 schrieb Brian Stansberry:
>      >
>      >>
>      >> AIUI your b.2 means decoupling the archetype from the QS code and
>      >> instead directly having the app code in the wildfly-archetypes
>     codebase.
>      >> The downside to that is now there's another example app to maintain.
>      >> (More than one really, as there would be one per archetype.)
>      >>
>      >> I think the key thing is this would need to be low maintenance.
>     The root
>      >> QS depends on the wildfly-bom[1] so if there aren't a lot of version
>      >> dependencies that would need to be in the archetype poms that
>     will help.
>      >> Is your impression that the archetype pom would be low maintenance?
>      >>
>      >> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
>      >>
>      >
>      > yes, this sounds like a very good idea: edit and maintain the
>     root pom
>      > of the archetype in the "archetype-resources" directory and sync only
>      > all other files. This mean a bit of work each time the archetype is
>      > updated for a new WildFly version, but less work than editing all
>     files.
>      >
>      > The only downside: I think the "ArchetypeSyncMojo" must be
>     modified and
>      > a "excludedFiles" property added, so that a sync will not
>     overwrite the
>      > archetype pom with the quickstart file.
>      >
>      > I hope I can do this, if you think this sounds reasonable ;-).
>      >
>      > Who is responsible for the maven-qstools-plugin? Probably he/she
>     should
>      > agree to those plans, too... And my change would have to be
>     merged and a
>      > new release of 1.7.0 (or 1.7.1?) to maven central would have to be
>      > triggered. As this is my first step in WildFly coding, I am new
>     to all
>      > this stuff.
>      >
>      > Best regards
>      >
>      > Wolfgang
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat

From jmesnil at redhat.com  Fri Mar  8 06:12:12 2019
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Fri, 8 Mar 2019 12:12:12 +0100
Subject: [wildfly-dev] [WFLY--11824] Proposal to create a WildFly Operator
	for Kubernetes/OpenShift
Message-ID: <CADNGjTGx4YEuwfrdstyKLfeGSPDuZGPRVm5K9Hkuh7ACSmXHwg@mail.gmail.com>

Hi,

I've created a proposal[1] to create a WildFly Operator for
Kubernetes/OpenShift under the wildfly organization in GitHub.
We are in the early stages of requirements and there are many things that
we want to do with this operator. We want to get this operator available
soon to the community so that all our users can use it to manage WildFly in
container platforms.

Any feedback is welcome.

Jeff
[1] https://github.com/wildfly/wildfly-proposals/pull/187

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190308/b5f2b3bd/attachment.html 

From wolfgang.knauf at gmx.de  Fri Mar  8 16:29:02 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Fri, 8 Mar 2019 22:29:02 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <1dfbcbc5-c4d3-f92b-7617-5cb57ab6d91e@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<5bb8aebd-c44f-4656-5762-93f4f3e91bf8@gmx.de>
	<CAPhbRDae3wmY8dGujQ7zfEb71BR8iHjT9PK-OVTEALGUTtT3rA@mail.gmail.com>
	<1dfbcbc5-c4d3-f92b-7617-5cb57ab6d91e@gmx.de>
Message-ID: <3886b95c-1b97-81a4-cde5-84bc38194443@gmx.de>

See below...

Am 07.03.19 um 22:25 schrieb Wolfgang Knauf:
> Hi Brian,
> 
> ok, I think now I can start reworking the archetype...
> 
> What name do you suggest? "wildfly-javaee-webapp-ear-archetype" - just 
> remove the "7" from the current archetype.
> This means:
> a) rename the "wildfly-javaee7-webapp-ear-archetype" directory in GIT?
> or
> b) create a new project?
> 
> ========================
> Two more questions:
> 
> there is a file "kitchensink-ear\readme.adoc", which is added to the 
> archetype.
> 
> But this will probably not work in the archetype, because it includes of 
> other adoc files in "../shared-doc"
> 
> Just remove it? I might also add a static file, like the "readme.md" 
> from the old archetype if necessary - but if it is static, it should 
> explain the archetype itself.
> 
> ==========================
> 

Forget about my previous question regarding the "arq-managed" profile - 
it works if the "jboss.home" property is specified either by 
"-Djboss.hom=" or by setting the environment variable JBOSS_HOME. I just 
learned something new ;-).


So only the above questions are still open.

Wolfgang

From brian.stansberry at redhat.com  Mon Mar 11 09:08:24 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 11 Mar 2019 08:08:24 -0500
Subject: [wildfly-dev] WildFly roadmap and key dates for WildFly 17
Message-ID: <CAPhbRDbzkFd9RNq+UGtNGp1enSrcRLNRxHOgn08y6mZzojwePw@mail.gmail.com>

Work is now underway on WildFly 17, so I wanted to blog about what I see
coming in the next few releases. You can read that at
https://wildfly.org/news/2019/03/09/Onward-to_WildFly-17/. I'd love to get
your feedback here. I'm particularly interested in peoples' thoughts on
what they'd like to see in Jakarta EE 9.

If you're interested in the details of new features that are being worked,
I really encourage you to keep an eye on
https://github.com/wildfly/wildfly-proposals/pulls and comment on any
proposals you see there. I encourage folks who submit a new proposal to
post here with a quick intro and a link.

WildFly 17 is scheduled for release three months after 16, continuing the
quarterly cadence. Here are the key dates:

   - Fri, May 10 ? PRs ready for merge for all features coming in via
   WildFly Core
   - Tue, May 14 ? All features ready for merge
   - Wed, May 15 ? WildFly 17 Beta. No new features after this date.
   - Fri, May 24 ? All changes for WildFly Core ready
   - Tue, May 28 ? All changes for WildFly ready
   - Thu, May 30 ? WildFly 17 Final released


Best regards,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190311/4262bb81/attachment.html 

From cfang at redhat.com  Mon Mar 11 22:17:55 2019
From: cfang at redhat.com (Cheng Fang)
Date: Mon, 11 Mar 2019 22:17:55 -0400
Subject: [wildfly-dev] Missing transformer tests
In-Reply-To: <CAPhbRDY1moR6TcU+r2gGpte3jYJRZUgEk032dVb52eid6jLf3w@mail.gmail.com>
References: <CAJfxLg6q7aKO7pBSb70m2ceS35+9KV7ya_5b9VF_s3OhjB1JkQ@mail.gmail.com>
	<CAPhbRDY1moR6TcU+r2gGpte3jYJRZUgEk032dVb52eid6jLf3w@mail.gmail.com>
Message-ID: <CABM4dPRhpH5uEAKhAd5JVTHsE6uDioQK452BrhD4pnkzwXn-4g@mail.gmail.com>

For ejb3 subsystem, 2 attributes (bean-cache and cache-container under
passivation-store element) changed their access-type from read-only to
read-write.  The change occurred in WildFly 16 (Dec 20, 2018
<https://github.com/wildfly/wildfly/commit/f8ceb2daac6ee16b27991a402dcda63d8e54967a#diff-6b005fa5eeb1b374b19a3a9f1fe9f64eL48>).
I created WFLY-11778 <https://issues.jboss.org/browse/WFLY-11778> (Missing
ejb3 transformer tests) to track the ejb3 part of this issue.

Since there is no structural changes, and the new one has wider
access-type, any operations from old version HC should have no problem.  Do
we still need transformer tests in this case?

Thanks,
Cheng



On Fri, Feb 8, 2019 at 10:41 AM Brian Stansberry <
brian.stansberry at redhat.com> wrote:

>
>
> On Fri, Feb 8, 2019 at 9:07 AM Kabir Khan <kkhan at redhat.com> wrote:
>
>> TL;DR: It looks like we may be missing transformer tests in the following
>> subsystems: ejb3, infinispan, jca, logging, undertow. I've not dug in
>> beyond that.
>>
>> Full:
>> We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing
>> WF14) for transformer testing until EAP 7.2.0 was released. [1] renames
>> this to be EAP_7_2_0 and points to EAP 7.2.0.
>>
>> In addition I have some WIP to update the full mixed domain and subsystem
>> tests to do the same. When doing this I noticed that the only subsystem
>> that had transformer tests referencing EAP_7_2_0_TEMP was modcluster. I
>> knew messaging-activemq had some changes, which Emmanuel is looking at.
>>
>> I've run the model comparison tool against master/7.2.0: and see changes
>> which might be significant:
>>
>> ====== Resource root address: ["subsystem" => "ejb3"] - Current version:
>> 0.0.0; legacy version: 5.0.0 =======
>> --- Problems for relative address to root ["passivation-store" => "*"]:
>> Different 'access-type' for attribute 'bean-cache'. Current:
>> "read-write"; legacy: "read-only"
>> Different 'access-type' for attribute 'cache-container'. Current:
>> "read-write"; legacy: "read-only"
>>
>> ====== Resource root address: ["subsystem" => "infinispan"] - Current
>> version: 0.0.0; legacy version: 8.0.0 =======
>> * --- Problems for relative address to root ["remote-cache-container" =>
>> "*"]:
>> Different 'default' for attribute 'protocol-version'. Current: "2.9";
>> legacy: "2.8"
>>
>>
>> ====== Resource root address: ["subsystem" => "jca"] - Current version:
>> 0.0.0; legacy version: 5.0.0 =======
>> --- Problems for relative address to root ["distributed-workmanager" =>
>> "*","long-running-threads" => "*"]:
>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>> * Missing parameters for operation 'add' in current: [handoff-executor];
>> missing in legacy []
>> --- Problems for relative address to root ["distributed-workmanager" =>
>> "*","short-running-threads" => "*"]:
>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>> * Missing parameters for operation 'add' in current: [handoff-executor];
>> missing in legacy []
>> --- Problems for relative address to root ["workmanager" =>
>> "*","long-running-threads" => "*"]:
>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>> * Missing parameters for operation 'add' in current: [handoff-executor];
>> missing in legacy []
>> --- Problems for relative address to root ["workmanager" =>
>> "*","short-running-threads" => "*"]:
>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>> * Missing parameters for operation 'add' in current: [handoff-executor];
>> missing in legacy []
>> --- Problems for relative address to root ["workmanager" =>
>> "default","long-running-threads" => "*"]:
>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>> * Missing parameters for operation 'add' in current: [handoff-executor];
>> missing in legacy []
>> --- Problems for relative address to root ["workmanager" =>
>> "default","short-running-threads" => "*"]:
>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>> * Missing parameters for operation 'add' in current: [handoff-executor];
>> missing in legacy []
>>
>>
>> ====== Resource root address: ["subsystem" => "logging"] - Current
>> version: 0.0.0; legacy version: 7.0.0 =======
>> * --- Problems for relative address to root ["json-formatter" => "*"]:
>> Different 'default' for attribute 'record-delimiter'. Current: "
>> "; legacy: ""
>> * --- Problems for relative address to root ["logging-profile" =>
>> "*","json-formatter" => "*"]:
>> Different 'default' for attribute 'record-delimiter'. Current: "
>> "; legacy: ""
>> * --- Problems for relative address to root ["logging-profile" =>
>> "*","xml-formatter" => "*"]:
>> Different 'default' for attribute 'record-delimiter'. Current: "
>> "; legacy: ""
>> * --- Problems for relative address to root ["xml-formatter" => "*"]:
>> Different 'default' for attribute 'record-delimiter'. Current: "
>> "; legacy: ""
>>
>>
>> ====== Resource root address: ["subsystem" => "undertow"] - Current
>> version: 0.0.0; legacy version: 7.0.0 =======
>> --- Problems for relative address to root ["application-security-domain"
>> => "*"]:
>> * Missing attributes in current: []; missing in legacy [enable-jaspi,
>> integrated-jaspi]
>> * Missing parameters for operation 'add' in current: []; missing in
>> legacy [enable-jaspi, integrated-jaspi]
>>
>> Although WF16 doesn't provide any domain mode guarantees for previous
>> releases, this will one day end up as a product release and then it is
>> important that we have these tests in place. It is easier to add them as we
>> go along than to retrofit them when that time comes.
>>
>
> Thanks, Kabir for running the check and for the heads up!
>
> This needs to be correct in WildFly regardless of any EAP requirements.  I
> believe the domain mode transformation chain from WF 14 all the way back to
> at least 11 is correct. There is no reason it shouldn't be extended to 16.
>
> Even though any fix would only come in 16, the correct way to write the
> transformation for something that changed in 15 is as if it had been done
> in 15. Write the transformation code for 15 -> 14 (constants, method names
> etc) and then if there are further changes for 16 -> 15, do those. Let
> future readers of the code read code that reflects the history of the
> management API.
>
>>
>> Thanks,
>>
>> Kabir
>>
>>
>>
>> [1] https://github.com/wildfly/wildfly-core/pull/3664
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190311/9e813352/attachment.html 

From brian.stansberry at redhat.com  Mon Mar 11 23:10:09 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 11 Mar 2019 22:10:09 -0500
Subject: [wildfly-dev] Missing transformer tests
In-Reply-To: <CABM4dPRhpH5uEAKhAd5JVTHsE6uDioQK452BrhD4pnkzwXn-4g@mail.gmail.com>
References: <CAJfxLg6q7aKO7pBSb70m2ceS35+9KV7ya_5b9VF_s3OhjB1JkQ@mail.gmail.com>
	<CAPhbRDY1moR6TcU+r2gGpte3jYJRZUgEk032dVb52eid6jLf3w@mail.gmail.com>
	<CABM4dPRhpH5uEAKhAd5JVTHsE6uDioQK452BrhD4pnkzwXn-4g@mail.gmail.com>
Message-ID: <CAPhbRDaTDtd5ywe4Z6Lhhh-U1Susz2Cp8fHcxUOcpx1TDgqLFw@mail.gmail.com>

On Mon, Mar 11, 2019 at 9:19 PM Cheng Fang <cfang at redhat.com> wrote:

> For ejb3 subsystem, 2 attributes (bean-cache and cache-container under
> passivation-store element) changed their access-type from read-only to
> read-write.  The change occurred in WildFly 16 (Dec 20, 2018
> <https://github.com/wildfly/wildfly/commit/f8ceb2daac6ee16b27991a402dcda63d8e54967a#diff-6b005fa5eeb1b374b19a3a9f1fe9f64eL48>).
> I created WFLY-11778 <https://issues.jboss.org/browse/WFLY-11778> (Missing
> ejb3 transformer tests) to track the ejb3 part of this issue.
>
> Since there is no structural changes, and the new one has wider
> access-type, any operations from old version HC should have no problem.  Do
> we still need transformer tests in this case?
>

A transformer is about a WF 16 master controlling a 15 or earlier HC. So
it's about dealing with the fact that the master can accept a
write-attribute for those attributes but if it tries to tell the legacy HC
to apply the operation, that HC cannot.

What does the failure look like if you have a WF 16 master and the
subordinate host is running 15 or earlier and you use write-attribute for
those? I suspect it looks ok.

It will fail because on the 15 host those attributes are not writable. And
that's fine; it has to fail. What a transformer would do in a case like
this would be to fail with a more understandable failure message (since the
master knows the real problem and can tailor the message, whereas the
legacy host just gets data it doesn't understand and might fail in an odd
way.) But in this case I think the legacy host would fail in an
understandable way, saying the attribute is not writable. A transformer on
the master probably wouldn't be written to produce a much better message.


> Thanks,
> Cheng
>
>
>
> On Fri, Feb 8, 2019 at 10:41 AM Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>>
>>
>> On Fri, Feb 8, 2019 at 9:07 AM Kabir Khan <kkhan at redhat.com> wrote:
>>
>>> TL;DR: It looks like we may be missing transformer tests in the
>>> following subsystems: ejb3, infinispan, jca, logging, undertow. I've not
>>> dug in beyond that.
>>>
>>> Full:
>>> We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing
>>> WF14) for transformer testing until EAP 7.2.0 was released. [1] renames
>>> this to be EAP_7_2_0 and points to EAP 7.2.0.
>>>
>>> In addition I have some WIP to update the full mixed domain and
>>> subsystem tests to do the same. When doing this I noticed that the only
>>> subsystem that had transformer tests referencing EAP_7_2_0_TEMP was
>>> modcluster. I knew messaging-activemq had some changes, which Emmanuel is
>>> looking at.
>>>
>>> I've run the model comparison tool against master/7.2.0: and see changes
>>> which might be significant:
>>>
>>> ====== Resource root address: ["subsystem" => "ejb3"] - Current version:
>>> 0.0.0; legacy version: 5.0.0 =======
>>> --- Problems for relative address to root ["passivation-store" => "*"]:
>>> Different 'access-type' for attribute 'bean-cache'. Current:
>>> "read-write"; legacy: "read-only"
>>> Different 'access-type' for attribute 'cache-container'. Current:
>>> "read-write"; legacy: "read-only"
>>>
>>> ====== Resource root address: ["subsystem" => "infinispan"] - Current
>>> version: 0.0.0; legacy version: 8.0.0 =======
>>> * --- Problems for relative address to root ["remote-cache-container" =>
>>> "*"]:
>>> Different 'default' for attribute 'protocol-version'. Current: "2.9";
>>> legacy: "2.8"
>>>
>>>
>>> ====== Resource root address: ["subsystem" => "jca"] - Current version:
>>> 0.0.0; legacy version: 5.0.0 =======
>>> --- Problems for relative address to root ["distributed-workmanager" =>
>>> "*","long-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["distributed-workmanager" =>
>>> "*","short-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "*","long-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "*","short-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "default","long-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "default","short-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>>
>>>
>>> ====== Resource root address: ["subsystem" => "logging"] - Current
>>> version: 0.0.0; legacy version: 7.0.0 =======
>>> * --- Problems for relative address to root ["json-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>> * --- Problems for relative address to root ["logging-profile" =>
>>> "*","json-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>> * --- Problems for relative address to root ["logging-profile" =>
>>> "*","xml-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>> * --- Problems for relative address to root ["xml-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>>
>>>
>>> ====== Resource root address: ["subsystem" => "undertow"] - Current
>>> version: 0.0.0; legacy version: 7.0.0 =======
>>> --- Problems for relative address to root ["application-security-domain"
>>> => "*"]:
>>> * Missing attributes in current: []; missing in legacy [enable-jaspi,
>>> integrated-jaspi]
>>> * Missing parameters for operation 'add' in current: []; missing in
>>> legacy [enable-jaspi, integrated-jaspi]
>>>
>>> Although WF16 doesn't provide any domain mode guarantees for previous
>>> releases, this will one day end up as a product release and then it is
>>> important that we have these tests in place. It is easier to add them as we
>>> go along than to retrofit them when that time comes.
>>>
>>
>> Thanks, Kabir for running the check and for the heads up!
>>
>> This needs to be correct in WildFly regardless of any EAP requirements.
>> I believe the domain mode transformation chain from WF 14 all the way back
>> to at least 11 is correct. There is no reason it shouldn't be extended to
>> 16.
>>
>> Even though any fix would only come in 16, the correct way to write the
>> transformation for something that changed in 15 is as if it had been done
>> in 15. Write the transformation code for 15 -> 14 (constants, method names
>> etc) and then if there are further changes for 16 -> 15, do those. Let
>> future readers of the code read code that reflects the history of the
>> management API.
>>
>>>
>>> Thanks,
>>>
>>> Kabir
>>>
>>>
>>>
>>> [1] https://github.com/wildfly/wildfly-core/pull/3664
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190311/c04e61bb/attachment-0001.html 

From emartins at redhat.com  Tue Mar 12 03:58:14 2019
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 12 Mar 2019 07:58:14 +0000
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
Message-ID: <0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>

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

> On 5 Mar 2019, at 22:00, Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:
> 
> Hi Brian,
> 
> Am 05.03.19 um 00:27 schrieb Brian Stansberry:
> 
>> AIUI your b.2 means decoupling the archetype from the QS code and instead directly having the app code in the wildfly-archetypes codebase. The downside to that is now there's another example app to maintain. (More than one really, as there would be one per archetype.)
>> I think the key thing is this would need to be low maintenance. The root QS depends on the wildfly-bom[1] so if there aren't a lot of version dependencies that would need to be in the archetype poms that will help. Is your impression that the archetype pom would be low maintenance?
>> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
> 
> yes, this sounds like a very good idea: edit and maintain the root pom of the archetype in the "archetype-resources" directory and sync only all other files. This mean a bit of work each time the archetype is updated for a new WildFly version, but less work than editing all files.
> 
> The only downside: I think the "ArchetypeSyncMojo" must be modified and a "excludedFiles" property added, so that a sync will not overwrite the archetype pom with the quickstart file.
> 
> I hope I can do this, if you think this sounds reasonable ;-).
> 
> Who is responsible for the maven-qstools-plugin? Probably he/she should agree to those plans, too... And my change would have to be merged and a new release of 1.7.0 (or 1.7.1?) to maven central would have to be triggered. As this is my first step in WildFly coding, I am new to all this stuff.
> 
> Best regards
> 
> Wolfgang



From tomaz.cerar at gmail.com  Tue Mar 12 04:57:08 2019
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 12 Mar 2019 09:57:08 +0100
Subject: [wildfly-dev] Missing transformer tests
In-Reply-To: <CABM4dPRhpH5uEAKhAd5JVTHsE6uDioQK452BrhD4pnkzwXn-4g@mail.gmail.com>
References: <CAJfxLg6q7aKO7pBSb70m2ceS35+9KV7ya_5b9VF_s3OhjB1JkQ@mail.gmail.com>
	<CAPhbRDY1moR6TcU+r2gGpte3jYJRZUgEk032dVb52eid6jLf3w@mail.gmail.com>
	<CABM4dPRhpH5uEAKhAd5JVTHsE6uDioQK452BrhD4pnkzwXn-4g@mail.gmail.com>
Message-ID: <CAMquZP5rPEzL=9b7ypvPp_qvtd30LBUYGTxw7N5kZ=iEDwLDPg@mail.gmail.com>

> Since there is no structural changes, and the new one has wider
access-type, any operations from old version HC should have no problem.  Do
we still need transformer tests in this case?

A test would not hurt, just to make sure everything else works.
If there are no structural changes beyond access-type test should  be also
very simple.

--
tomaz

On Tue, Mar 12, 2019 at 3:19 AM Cheng Fang <cfang at redhat.com> wrote:

> For ejb3 subsystem, 2 attributes (bean-cache and cache-container under
> passivation-store element) changed their access-type from read-only to
> read-write.  The change occurred in WildFly 16 (Dec 20, 2018
> <https://github.com/wildfly/wildfly/commit/f8ceb2daac6ee16b27991a402dcda63d8e54967a#diff-6b005fa5eeb1b374b19a3a9f1fe9f64eL48>).
> I created WFLY-11778 <https://issues.jboss.org/browse/WFLY-11778> (Missing
> ejb3 transformer tests) to track the ejb3 part of this issue.
>
> Since there is no structural changes, and the new one has wider
> access-type, any operations from old version HC should have no problem.  Do
> we still need transformer tests in this case?
>
> Thanks,
> Cheng
>
>
>
> On Fri, Feb 8, 2019 at 10:41 AM Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>>
>>
>> On Fri, Feb 8, 2019 at 9:07 AM Kabir Khan <kkhan at redhat.com> wrote:
>>
>>> TL;DR: It looks like we may be missing transformer tests in the
>>> following subsystems: ejb3, infinispan, jca, logging, undertow. I've not
>>> dug in beyond that.
>>>
>>> Full:
>>> We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing
>>> WF14) for transformer testing until EAP 7.2.0 was released. [1] renames
>>> this to be EAP_7_2_0 and points to EAP 7.2.0.
>>>
>>> In addition I have some WIP to update the full mixed domain and
>>> subsystem tests to do the same. When doing this I noticed that the only
>>> subsystem that had transformer tests referencing EAP_7_2_0_TEMP was
>>> modcluster. I knew messaging-activemq had some changes, which Emmanuel is
>>> looking at.
>>>
>>> I've run the model comparison tool against master/7.2.0: and see changes
>>> which might be significant:
>>>
>>> ====== Resource root address: ["subsystem" => "ejb3"] - Current version:
>>> 0.0.0; legacy version: 5.0.0 =======
>>> --- Problems for relative address to root ["passivation-store" => "*"]:
>>> Different 'access-type' for attribute 'bean-cache'. Current:
>>> "read-write"; legacy: "read-only"
>>> Different 'access-type' for attribute 'cache-container'. Current:
>>> "read-write"; legacy: "read-only"
>>>
>>> ====== Resource root address: ["subsystem" => "infinispan"] - Current
>>> version: 0.0.0; legacy version: 8.0.0 =======
>>> * --- Problems for relative address to root ["remote-cache-container" =>
>>> "*"]:
>>> Different 'default' for attribute 'protocol-version'. Current: "2.9";
>>> legacy: "2.8"
>>>
>>>
>>> ====== Resource root address: ["subsystem" => "jca"] - Current version:
>>> 0.0.0; legacy version: 5.0.0 =======
>>> --- Problems for relative address to root ["distributed-workmanager" =>
>>> "*","long-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["distributed-workmanager" =>
>>> "*","short-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "*","long-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "*","short-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "default","long-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>> --- Problems for relative address to root ["workmanager" =>
>>> "default","short-running-threads" => "*"]:
>>> * Missing attributes in current: [handoff-executor]; missing in legacy []
>>> * Missing parameters for operation 'add' in current: [handoff-executor];
>>> missing in legacy []
>>>
>>>
>>> ====== Resource root address: ["subsystem" => "logging"] - Current
>>> version: 0.0.0; legacy version: 7.0.0 =======
>>> * --- Problems for relative address to root ["json-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>> * --- Problems for relative address to root ["logging-profile" =>
>>> "*","json-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>> * --- Problems for relative address to root ["logging-profile" =>
>>> "*","xml-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>> * --- Problems for relative address to root ["xml-formatter" => "*"]:
>>> Different 'default' for attribute 'record-delimiter'. Current: "
>>> "; legacy: ""
>>>
>>>
>>> ====== Resource root address: ["subsystem" => "undertow"] - Current
>>> version: 0.0.0; legacy version: 7.0.0 =======
>>> --- Problems for relative address to root ["application-security-domain"
>>> => "*"]:
>>> * Missing attributes in current: []; missing in legacy [enable-jaspi,
>>> integrated-jaspi]
>>> * Missing parameters for operation 'add' in current: []; missing in
>>> legacy [enable-jaspi, integrated-jaspi]
>>>
>>> Although WF16 doesn't provide any domain mode guarantees for previous
>>> releases, this will one day end up as a product release and then it is
>>> important that we have these tests in place. It is easier to add them as we
>>> go along than to retrofit them when that time comes.
>>>
>>
>> Thanks, Kabir for running the check and for the heads up!
>>
>> This needs to be correct in WildFly regardless of any EAP requirements.
>> I believe the domain mode transformation chain from WF 14 all the way back
>> to at least 11 is correct. There is no reason it shouldn't be extended to
>> 16.
>>
>> Even though any fix would only come in 16, the correct way to write the
>> transformation for something that changed in 15 is as if it had been done
>> in 15. Write the transformation code for 15 -> 14 (constants, method names
>> etc) and then if there are further changes for 16 -> 15, do those. Let
>> future readers of the code read code that reflects the history of the
>> management API.
>>
>>>
>>> Thanks,
>>>
>>> Kabir
>>>
>>>
>>>
>>> [1] https://github.com/wildfly/wildfly-core/pull/3664
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190312/99a8114a/attachment.html 

From paul.ferraro at redhat.com  Tue Mar 12 09:24:32 2019
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Tue, 12 Mar 2019 09:24:32 -0400
Subject: [wildfly-dev] Missing transformer tests
In-Reply-To: <CAJfxLg6q7aKO7pBSb70m2ceS35+9KV7ya_5b9VF_s3OhjB1JkQ@mail.gmail.com>
References: <CAJfxLg6q7aKO7pBSb70m2ceS35+9KV7ya_5b9VF_s3OhjB1JkQ@mail.gmail.com>
Message-ID: <CAF5qqoP4n+sUCRwcA4-zTKzyBu_z1i=SXhrB+HyafE-vHBoXow@mail.gmail.com>

Thanks for identifying these.  As for the missing Infinispan subsystem
transformer, we were previously using the default protocol version
from the hotrod client as our default value in the model.  This makes
it very easy to miss default value changes during Infinispan upgrades.
I've changed this to use an explicit value, which should hopefully
prevent this problem in the future.
https://issues.jboss.org/browse/WFLY-11839

On Fri, Feb 8, 2019 at 10:07 AM Kabir Khan <kkhan at redhat.com> wrote:
>
> TL;DR: It looks like we may be missing transformer tests in the following subsystems: ejb3, infinispan, jca, logging, undertow. I've not dug in beyond that.
>
> Full:
> We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing WF14) for transformer testing until EAP 7.2.0 was released. [1] renames this to be EAP_7_2_0 and points to EAP 7.2.0.
>
> In addition I have some WIP to update the full mixed domain and subsystem tests to do the same. When doing this I noticed that the only subsystem that had transformer tests referencing EAP_7_2_0_TEMP was modcluster. I knew messaging-activemq had some changes, which Emmanuel is looking at.
>
> I've run the model comparison tool against master/7.2.0: and see changes which might be significant:
>
> ====== Resource root address: ["subsystem" => "ejb3"] - Current version: 0.0.0; legacy version: 5.0.0 =======
> --- Problems for relative address to root ["passivation-store" => "*"]:
> Different 'access-type' for attribute 'bean-cache'. Current: "read-write"; legacy: "read-only"
> Different 'access-type' for attribute 'cache-container'. Current: "read-write"; legacy: "read-only"
>
> ====== Resource root address: ["subsystem" => "infinispan"] - Current version: 0.0.0; legacy version: 8.0.0 =======
> * --- Problems for relative address to root ["remote-cache-container" => "*"]:
> Different 'default' for attribute 'protocol-version'. Current: "2.9"; legacy: "2.8"

Here the default value is taken from Infinispan - which is how the
version update was overlooked during the upgrade from Infinispan 9.3.x
to 9.4.x.
I think what I'd like to do for this one is to always apply a default
value conversion - we don't need to keep incrementing the threshold
version for every upgrade.
We do, however, need to remember to bump model versions when this
protocol version changes.

> ====== Resource root address: ["subsystem" => "jca"] - Current version: 0.0.0; legacy version: 5.0.0 =======
> --- Problems for relative address to root ["distributed-workmanager" => "*","long-running-threads" => "*"]:
> * Missing attributes in current: [handoff-executor]; missing in legacy []
> * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy []
> --- Problems for relative address to root ["distributed-workmanager" => "*","short-running-threads" => "*"]:
> * Missing attributes in current: [handoff-executor]; missing in legacy []
> * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy []
> --- Problems for relative address to root ["workmanager" => "*","long-running-threads" => "*"]:
> * Missing attributes in current: [handoff-executor]; missing in legacy []
> * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy []
> --- Problems for relative address to root ["workmanager" => "*","short-running-threads" => "*"]:
> * Missing attributes in current: [handoff-executor]; missing in legacy []
> * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy []
> --- Problems for relative address to root ["workmanager" => "default","long-running-threads" => "*"]:
> * Missing attributes in current: [handoff-executor]; missing in legacy []
> * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy []
> --- Problems for relative address to root ["workmanager" => "default","short-running-threads" => "*"]:
> * Missing attributes in current: [handoff-executor]; missing in legacy []
> * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy []
>
>
> ====== Resource root address: ["subsystem" => "logging"] - Current version: 0.0.0; legacy version: 7.0.0 =======
> * --- Problems for relative address to root ["json-formatter" => "*"]:
> Different 'default' for attribute 'record-delimiter'. Current: "
> "; legacy: ""
> * --- Problems for relative address to root ["logging-profile" => "*","json-formatter" => "*"]:
> Different 'default' for attribute 'record-delimiter'. Current: "
> "; legacy: ""
> * --- Problems for relative address to root ["logging-profile" => "*","xml-formatter" => "*"]:
> Different 'default' for attribute 'record-delimiter'. Current: "
> "; legacy: ""
> * --- Problems for relative address to root ["xml-formatter" => "*"]:
> Different 'default' for attribute 'record-delimiter'. Current: "
> "; legacy: ""
>
>
> ====== Resource root address: ["subsystem" => "undertow"] - Current version: 0.0.0; legacy version: 7.0.0 =======
> --- Problems for relative address to root ["application-security-domain" => "*"]:
> * Missing attributes in current: []; missing in legacy [enable-jaspi, integrated-jaspi]
> * Missing parameters for operation 'add' in current: []; missing in legacy [enable-jaspi, integrated-jaspi]
>
> Although WF16 doesn't provide any domain mode guarantees for previous releases, this will one day end up as a product release and then it is important that we have these tests in place. It is easier to add them as we go along than to retrofit them when that time comes.
>
> Thanks,
>
> Kabir
>
>
>
> [1] https://github.com/wildfly/wildfly-core/pull/3664
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From wolfgang.knauf at gmx.de  Tue Mar 12 15:12:07 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Tue, 12 Mar 2019 20:12:07 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
Message-ID: <7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>

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.


Do you agree to this plan ;-)?


Wolfgang

> 
>> On 5 Mar 2019, at 22:00, Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:
>>
>> Hi Brian,
>>
>> Am 05.03.19 um 00:27 schrieb Brian Stansberry:
>>
>>> AIUI your b.2 means decoupling the archetype from the QS code and instead directly having the app code in the wildfly-archetypes codebase. The downside to that is now there's another example app to maintain. (More than one really, as there would be one per archetype.)
>>> I think the key thing is this would need to be low maintenance. The root QS depends on the wildfly-bom[1] so if there aren't a lot of version dependencies that would need to be in the archetype poms that will help. Is your impression that the archetype pom would be low maintenance?
>>> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
>>
>> yes, this sounds like a very good idea: edit and maintain the root pom of the archetype in the "archetype-resources" directory and sync only all other files. This mean a bit of work each time the archetype is updated for a new WildFly version, but less work than editing all files.
>>
>> The only downside: I think the "ArchetypeSyncMojo" must be modified and a "excludedFiles" property added, so that a sync will not overwrite the archetype pom with the quickstart file.
>>
>> I hope I can do this, if you think this sounds reasonable ;-).
>>
>> Who is responsible for the maven-qstools-plugin? Probably he/she should agree to those plans, too... And my change would have to be merged and a new release of 1.7.0 (or 1.7.1?) to maven central would have to be triggered. As this is my first step in WildFly coding, I am new to all this stuff.
>>
>> Best regards
>>
>> Wolfgang
> 
> 

From brian.stansberry at redhat.com  Tue Mar 12 21:55:56 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 12 Mar 2019 20:55:56 -0500
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
Message-ID: <CAPhbRDZ-0mx4yTD3Vi41rgxy4UW5snoBTuLjmLNP5mKrb-ixQw@mail.gmail.com>

On Tue, Mar 12, 2019 at 2:25 PM Wolfgang Knauf <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.
>
>
> Do you agree to this plan ;-)?
>

If you an Eduardo thinks it's better to have something simpler directly in
the archetype rather than syncing in the QS code, that is fine with me.

>
>
> Wolfgang
>
> >
> >> On 5 Mar 2019, at 22:00, Wolfgang Knauf <wolfgang.knauf at gmx.de> wrote:
> >>
> >> Hi Brian,
> >>
> >> Am 05.03.19 um 00:27 schrieb Brian Stansberry:
> >>
> >>> AIUI your b.2 means decoupling the archetype from the QS code and
> instead directly having the app code in the wildfly-archetypes codebase.
> The downside to that is now there's another example app to maintain. (More
> than one really, as there would be one per archetype.)
> >>> I think the key thing is this would need to be low maintenance. The
> root QS depends on the wildfly-bom[1] so if there aren't a lot of version
> dependencies that would need to be in the archetype poms that will help. Is
> your impression that the archetype pom would be low maintenance?
> >>> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
> >>
> >> yes, this sounds like a very good idea: edit and maintain the root pom
> of the archetype in the "archetype-resources" directory and sync only all
> other files. This mean a bit of work each time the archetype is updated for
> a new WildFly version, but less work than editing all files.
> >>
> >> The only downside: I think the "ArchetypeSyncMojo" must be modified and
> a "excludedFiles" property added, so that a sync will not overwrite the
> archetype pom with the quickstart file.
> >>
> >> I hope I can do this, if you think this sounds reasonable ;-).
> >>
> >> Who is responsible for the maven-qstools-plugin? Probably he/she should
> agree to those plans, too... And my change would have to be merged and a
> new release of 1.7.0 (or 1.7.1?) to maven central would have to be
> triggered. As this is my first step in WildFly coding, I am new to all this
> stuff.
> >>
> >> Best regards
> >>
> >> Wolfgang
> >
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190312/25bc1654/attachment.html 

From emartins at redhat.com  Wed Mar 13 13:25:17 2019
From: emartins at redhat.com (Eduardo Martins)
Date: Wed, 13 Mar 2019 17:25:17 +0000
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
Message-ID: <05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>


> On 12 Mar 2019, at 19:12, Wolfgang Knauf <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

From wolfgang.knauf at gmx.de  Wed Mar 13 15:14:05 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Wed, 13 Mar 2019 20:14:05 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
Message-ID: <928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>


Am 13.03.19 um 18:25 schrieb Eduardo Martins:
> 
>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <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

From emartins at redhat.com  Mon Mar 18 04:33:51 2019
From: emartins at redhat.com (Eduardo Martins)
Date: Mon, 18 Mar 2019 08:33:51 +0000
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
Message-ID: <28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>

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> 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> 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



From wolfgang.knauf at gmx.de  Mon Mar 18 17:03:23 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Mon, 18 Mar 2019 22:03:23 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
	<28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
Message-ID: <96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>

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> 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> 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
> 
> 

From emartins at redhat.com  Mon Mar 18 17:49:14 2019
From: emartins at redhat.com (Eduardo Martins)
Date: Mon, 18 Mar 2019 21:49:14 +0000
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
	<28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
	<96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>
Message-ID: <CALX1fhcOp7eu0AAc5CYhSzr+_GFTVnu9-MVv2wB4TFt=Vagicg@mail.gmail.com>

Webapp-ear sounds a bit weird, perhaps app-ear and app-web instead? :-)

On Mon, 18 Mar 2019 at 21:04, Wolfgang Knauf <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> 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>
> 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
> >
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190318/5dc2c252/attachment-0001.html 

From wolfgang.knauf at gmx.de  Tue Mar 19 07:09:10 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Tue, 19 Mar 2019 12:09:10 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <CALX1fhcOp7eu0AAc5CYhSzr+_GFTVnu9-MVv2wB4TFt=Vagicg@mail.gmail.com>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
	<28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
	<96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>
	<CALX1fhcOp7eu0AAc5CYhSzr+_GFTVnu9-MVv2wB4TFt=Vagicg@mail.gmail.com>
Message-ID: <5914b66f-e9d5-b703-3295-84012220d9e1@gmx.de>


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


From rory.odonnell at oracle.com  Wed Mar 20 04:15:52 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Wed, 20 Mar 2019 08:15:52 +0000
Subject: [wildfly-dev] Release Announcement: General Availability of Java 12
	/ JDK 12
Message-ID: <b9f5fd53-1c75-38d1-8aee-d3f31293cedc@oracle.com>

**
Hi David & Richard*,*
* *

*1) Release Announcement: General Availability of Java 12 / JDK 12 [1] *

  * JDK 12, the reference implementation of Java 12, is now Generally
    Available.
  * GPL-licensed OpenJDK builds from Oracle are available here:
    https://jdk.java.net/12

This release includes the following? eight features:

  * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
  * JEP 230: Microbenchmark Suite
  * JEP 334: JVM Constants API
  * JEP 340: One AArch64 Port, Not Two
  * JEP 341: Default CDS Archives
  * JEP 344: Abortable Mixed Collections for G1
  * JEP 346: Promptly Return Unused Committed Memory from G1

Thanks to everyone who contributed JDK 12, whether by creating features 
or enhancements, logging? bugs, or downloading and testing the 
early-access builds.

*2) JDK 13 EA build 12, under both the GPL and Oracle EA licenses, is 
now available at **http://jdk.java.net/13**.*

  * Proposed - Schedule for JDK 13 [2]
      o 2019/06/13 Rampdown Phase One
      o 2019/07/18 Rampdown Phase Two
      o 2019/08/08 Initial Release Candidate
      o 2019/08/22 Final Release Candidate
      o 2019/09/17 General Availability
  * Recent Bug fixes of Interest
      o Build 9:
          + 8214719: Deprecate -Xverify:none option
          + 8216360: Deprecate -XX:CompilationPolicyChoice
      o Build 10:
          + 8218995: Deprecate the -XX:FailOverToOldVerifier option
      o Build 12 : 8160247: Mark deprecated javax.security.cert APIs
        with forRemoval=true
          + 8220050: Deprecate -XX:-ThreadLocalHandshakes
          + Apache Lucene Reported - 8219448: split-if update_uses
            accesses stale idom data
  * Changes in this build [3]

Rgds,Rory

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002718.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002716.html
[3] Changes 
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B11%22%3A%3A%22jdk-13%2B12%22-%22jdk-13%2B11%22%29&revcount=1000> 
in this build


-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190320/62c346cb/attachment.html 

From cfang at redhat.com  Wed Mar 20 19:56:50 2019
From: cfang at redhat.com (Cheng Fang)
Date: Wed, 20 Mar 2019 19:56:50 -0400
Subject: [wildfly-dev] How to Select a Different Name Context in Management
	Request Thread
Message-ID: <CABM4dPS35xBiXcBuQZ2U1_Anz=CnTfpxQB3D6P26iZgVRX0TqQ@mail.gmail.com>

Hi,

I'm working on WFLY-11808 <https://issues.jboss.org/browse/WFLY-11808> (Unable
to do jndi lookup when starting batch job from web console), and would like
to get some help from team, especially naming and management experts.

The failure occurred when a batch job is started from management console or
CLI, and during the batch job execution it does some jndi lookup.  The
lookup failed with NameNotFoundException.

In batch subsystem, it assigns the name context for the job execution by
calling:

NamespaceContextSelector.getCurrentSelector();

For a management-started job execution, it selected the one associated with
the current thread which is an external management request thread, and
apparently has no knowledge of the deployment.

Is there a way to select the name context associated with the deployment
that contains the batch job?

Thanks,
Cheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190320/5222c30f/attachment.html 

From wolfgang.knauf at gmx.de  Thu Mar 21 07:47:38 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Thu, 21 Mar 2019 12:47:38 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <5914b66f-e9d5-b703-3295-84012220d9e1@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
	<28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
	<96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>
	<CALX1fhcOp7eu0AAc5CYhSzr+_GFTVnu9-MVv2wB4TFt=Vagicg@mail.gmail.com>
	<5914b66f-e9d5-b703-3295-84012220d9e1@gmx.de>
Message-ID: <42a971fe-fd23-df27-c31d-9fdc6148dca7@gmx.de>

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
>


From dvilkola at redhat.com  Mon Mar 25 14:36:53 2019
From: dvilkola at redhat.com (Diana Vilkolakova)
Date: Mon, 25 Mar 2019 19:36:53 +0100
Subject: [wildfly-dev] [WFLY-11868] Proposal for RESTEasy integration with
 Elytron on the client side
Message-ID: <CAHvwbVe-yHi_Wuje2Z7wZuLvXaRuPkaOdQinjscnPfgDGBQYzQ@mail.gmail.com>

Hello All,
I've created a proposal [1] for [WFLY-11868] RESTEasy integration with
Elytron on the client side. Any feedback is welcomed.

[1]: https://github.com/wildfly/wildfly-proposals/pull/189
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190325/00325d74/attachment.html 

From brian.stansberry at redhat.com  Tue Mar 26 14:01:52 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 26 Mar 2019 13:01:52 -0500
Subject: [wildfly-dev] How to Select a Different Name Context in
 Management Request Thread
In-Reply-To: <CABM4dPS35xBiXcBuQZ2U1_Anz=CnTfpxQB3D6P26iZgVRX0TqQ@mail.gmail.com>
References: <CABM4dPS35xBiXcBuQZ2U1_Anz=CnTfpxQB3D6P26iZgVRX0TqQ@mail.gmail.com>
Message-ID: <CAPhbRDat374cw9insBkirVQcpFpMf59DENZfwX-vEuLu58+ULA@mail.gmail.com>

On Wed, Mar 20, 2019 at 6:58 PM Cheng Fang <cfang at redhat.com> wrote:

> Hi,
>
> I'm working on WFLY-11808 <https://issues.jboss.org/browse/WFLY-11808> (Unable
> to do jndi lookup when starting batch job from web console), and would like
> to get some help from team, especially naming and management experts.
>
> The failure occurred when a batch job is started from management console
> or CLI, and during the batch job execution it does some jndi lookup.  The
> lookup failed with NameNotFoundException.
>
> In batch subsystem, it assigns the name context for the job execution by
> calling:
>
> NamespaceContextSelector.getCurrentSelector();
>
> For a management-started job execution, it selected the one associated
> with the current thread which is an external management request thread, and
> apparently has no knowledge of the deployment.
>
> Is there a way to select the name context associated with the deployment
> that contains the batch job?
>

Unfortunately, there isn't a NamespaceContextSelector for a deployment
overall. There's the default selector (which I assume is what
NamespaceContextSelector.getCurrentSelector()
is returning now for this case) and then there are per-EE-component
selectors (see NamespaceConfigurator.configure).

I don't know if what Eduardo Martins is doing on
https://issues.jboss.org/browse/WFLY-9529 may help somewhat, i.e. by making
some commonly requested bindings visible when the thread is handling a from
an EE component.


>
Thanks,
> Cheng
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190326/8c0f2df3/attachment.html 

From asoldano at redhat.com  Thu Mar 28 06:28:23 2019
From: asoldano at redhat.com (Alessio Soldano)
Date: Thu, 28 Mar 2019 11:28:23 +0100
Subject: [wildfly-dev] [WFLY-11868] Proposal for RESTEasy integration
 with Elytron on the client side
In-Reply-To: <CAHvwbVe-yHi_Wuje2Z7wZuLvXaRuPkaOdQinjscnPfgDGBQYzQ@mail.gmail.com>
References: <CAHvwbVe-yHi_Wuje2Z7wZuLvXaRuPkaOdQinjscnPfgDGBQYzQ@mail.gmail.com>
Message-ID: <CAKQecn8nm9o_6n7ENjMWMO8dpn6CXRpB=jjhC3OC9b6osW7uDw@mail.gmail.com>

Thanks Diana,
sorry for the late reply, I've just provided some feedback on the proposal.
Cheers

On Mon, Mar 25, 2019 at 7:44 PM Diana Vilkolakova <dvilkola at redhat.com>
wrote:

> Hello All,
> I've created a proposal [1] for [WFLY-11868] RESTEasy integration with
> Elytron on the client side. Any feedback is welcomed.
>
> [1]: https://github.com/wildfly/wildfly-proposals/pull/189
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 

Alessio Soldano

Associate Manager, Software Engineering

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190328/58cb1b8f/attachment.html 

From rory.odonnell at oracle.com  Fri Mar 29 06:42:27 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 29 Mar 2019 10:42:27 +0000
Subject: [wildfly-dev] JDK 13 - Early Access build 14 is available
Message-ID: <d6c9de4b-44eb-5907-2bb7-5ca86f794c57@oracle.com>

Hi David & Richard*,*

*OpenJDK builds *- JDK 13 - Early Access build 14 is available at 
http://jdk.java.net/13/

  * These early-access, open-source builds are provided under the GNU
    General Public License, version?2, with the Classpath Exception
    <http://openjdk.java.net/legal/gplv2+ce.html>.
  * Changes in this build
    <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B13%22%3A%3A%22jdk-13%2B14%22-%22jdk-13%2B13%22%29&revcount=1000>
  * Release notes [1]
  * JDK 13 Schedule proposal accepted [2]
      o 2019/06/13 Rampdown Phase One
      o 2019/07/18 Rampdown Phase Two
      o 2019/08/08 Initial Release Candidate
      o 2019/08/22 Final Release Candidate
      o 2019/09/17 General Availability

*jpackage EA *

  * This is an early access build of JEP 343: Packaging Tool
    <https://openjdk.java.net/jeps/343>, aimed at testing a prototype
    implementation of jpackage, which is a new tool for packaging
    self-contained Java applications along with a Java Runtime Environment.
  * Build 30 is now available http://jdk.java.net/jpackage/
  * Please send feedback via e-mail to core-libs-dev at openjdk.java.net
    <mailto:core-libs-dev at openjdk.java.net>

*Quality Outreach report for **March 2019*

  * The report for March 2019 is available here
    <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2019>
  * Thanks to all those contributed !

*Recent Blog:* A new (Japanese) era for Java! 
<https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java>

Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190329/ebfbe652/attachment.html 

From manovotn at redhat.com  Fri Mar 29 10:56:56 2019
From: manovotn at redhat.com (Matej Novotny)
Date: Fri, 29 Mar 2019 10:56:56 -0400 (EDT)
Subject: [wildfly-dev] Question about usage of jboss spec versions
In-Reply-To: <1148476998.16316094.1553870961423.JavaMail.zimbra@redhat.com>
Message-ID: <536985657.16317410.1553871416719.JavaMail.zimbra@redhat.com>

Hello,

This is probably stupid question but I was recently wondering, what's the actual reason why WFLY (and other RH technologies) use jboss versions of all the specs?
For instance https://github.com/jboss/jboss-annotations-api_spec instead of just picking up the javax.annotation artifact.

The contents are pretty much the same, so I think I have to be missing something trivial and obvious..
Is it historical reasons? Or perhaps a matter of licenses and productization?

Matej

From psakar at redhat.com  Fri Mar 29 15:36:10 2019
From: psakar at redhat.com (Petr Sakar)
Date: Fri, 29 Mar 2019 20:36:10 +0100
Subject: [wildfly-dev] Question about usage of jboss spec versions
In-Reply-To: <536985657.16317410.1553871416719.JavaMail.zimbra@redhat.com>
References: <536985657.16317410.1553871416719.JavaMail.zimbra@redhat.com>
Message-ID: <adb148b2-9f8a-2260-714a-4c76e2cf33a4@redhat.com>

Historical reason I'm aware of was that some "official" APIs contained implementations as well

Petr


On 3/29/19 3:56 PM, Matej Novotny wrote:
> Hello,
>
> This is probably stupid question but I was recently wondering, what's the actual reason why WFLY (and other RH technologies) use jboss versions of all the specs?
> For instance https://github.com/jboss/jboss-annotations-api_spec instead of just picking up the javax.annotation artifact.
>
> The contents are pretty much the same, so I think I have to be missing something trivial and obvious..
> Is it historical reasons? Or perhaps a matter of licenses and productization?
>
> Matej
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From tomaz.cerar at gmail.com  Sun Mar 31 14:00:54 2019
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Sun, 31 Mar 2019 20:00:54 +0200
Subject: [wildfly-dev] Question about usage of jboss spec versions
In-Reply-To: <536985657.16317410.1553871416719.JavaMail.zimbra@redhat.com>
References: <1148476998.16316094.1553870961423.JavaMail.zimbra@redhat.com>
	<536985657.16317410.1553871416719.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP7eSK7mqAFPBZhHPN_81C5ttHk1tGJJ-o16Ujp=PH2QvQ@mail.gmail.com>

For the longest time java ee related spec apis ware not officially
available in any maven repository.

Only lately with latest version of Java/Jakarta EE spec apis are starting
to appear properly in maven central.

Another reason is as Petr said, some service loader configs (w)are
different and in some cases even some impl classes (w)are added.

--
tomaz

On Fri, Mar 29, 2019 at 4:08 PM Matej Novotny <manovotn at redhat.com> wrote:

> Hello,
>
> This is probably stupid question but I was recently wondering, what's the
> actual reason why WFLY (and other RH technologies) use jboss versions of
> all the specs?
> For instance https://github.com/jboss/jboss-annotations-api_spec instead
> of just picking up the javax.annotation artifact.
>
> The contents are pretty much the same, so I think I have to be missing
> something trivial and obvious..
> Is it historical reasons? Or perhaps a matter of licenses and
> productization?
>
> Matej
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190331/a391dfca/attachment.html 

From wolfgang.knauf at gmx.de  Sun Mar 31 14:40:04 2019
From: wolfgang.knauf at gmx.de (Wolfgang Knauf)
Date: Sun, 31 Mar 2019 20:40:04 +0200
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <42a971fe-fd23-df27-c31d-9fdc6148dca7@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
	<28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
	<96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>
	<CALX1fhcOp7eu0AAc5CYhSzr+_GFTVnu9-MVv2wB4TFt=Vagicg@mail.gmail.com>
	<5914b66f-e9d5-b703-3295-84012220d9e1@gmx.de>
	<42a971fe-fd23-df27-c31d-9fdc6148dca7@gmx.de>
Message-ID: <3a70866d-4621-514e-b329-0fa117219c45@gmx.de>

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 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
>>


From emartins at redhat.com  Sun Mar 31 15:34:41 2019
From: emartins at redhat.com (Eduardo Martins)
Date: Sun, 31 Mar 2019 20:34:41 +0100
Subject: [wildfly-dev] Updating the WildFly archetypes
In-Reply-To: <3a70866d-4621-514e-b329-0fa117219c45@gmx.de>
References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de>
	<582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de>
	<CAPhbRDYS84hisLYa3DC20BWjBg_v5iL=Fk4fWhGXd3foMugOSw@mail.gmail.com>
	<b213ce6a-7b08-7c2a-64dc-f3186def802f@gmx.de>
	<de7cd83d-9076-7af5-27df-5b468aac5f39@gmx.de>
	<e9897b9a-8aca-1534-4aa8-04eac62e501f@gmx.de>
	<CAPhbRDZZ6H3N=_=wxR0tmMo7uYhbwHFEarNZEHVpgg+_bq3G1Q@mail.gmail.com>
	<1456ba90-89d2-2a6c-21bd-de109033551e@gmx.de>
	<0DC3C23D-3681-4941-B355-E2C33F5B2026@redhat.com>
	<7035b0b9-07fe-c241-8186-24a541a3fae0@gmx.de>
	<05A98C47-1EAE-41C2-8835-CD975326A3D3@redhat.com>
	<928b27fe-eaaf-1b43-1b55-6635fccc4171@gmx.de>
	<28D77BA0-E00F-4144-BF31-62CF8385EA47@redhat.com>
	<96e133b0-bf15-3b3d-9975-02cf6e3dec1e@gmx.de>
	<CALX1fhcOp7eu0AAc5CYhSzr+_GFTVnu9-MVv2wB4TFt=Vagicg@mail.gmail.com>
	<5914b66f-e9d5-b703-3295-84012220d9e1@gmx.de>
	<42a971fe-fd23-df27-c31d-9fdc6148dca7@gmx.de>
	<3a70866d-4621-514e-b329-0fa117219c45@gmx.de>
Message-ID: <EE0424D8-D48B-4000-AD26-FF3419A0DEF2@redhat.com>

I will review it, soon hopefully.

?E

> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf at 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 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
>>> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev