3:12 p.m.
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
3:04 p.m.
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...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:05 p.m.
On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf <wolfgang.knauf(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
3:26 p.m.
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...)
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/ed12afad407a2946b85db37bfeec1d...
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/m...
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(a)gmx.de
<mailto:wolfgang.knauf@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
2:02 p.m.
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...)
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/ed12afad407a2946b85db37bfeec1d...
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/m...
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(a)gmx.de
> <mailto:wolfgang.knauf@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
5:55 a.m.
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...)
>
> 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/ed12afad407a2946b85db37bfeec1d...
>
>
>
> 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/m...
>
>
>
> 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(a)gmx.de
>> <mailto:wolfgang.knauf@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
5:27 p.m.
On Sat, Mar 2, 2019 at 5:58 AM Wolfgang Knauf <wolfgang.knauf(a)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...)
>>
>> 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/ed12afad407a2946b85db37bfeec1d...
>>
>>
>>
>> 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/m...
>>
>>
>>
>> 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(a)gmx.de
>>> <mailto:wolfgang.knauf@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org
>
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
4 p.m.
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
2:36 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:27 p.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
3:25 p.m.
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(a)gmx.de
<mailto:wolfgang.knauf@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
3:29 p.m.
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
2:58 a.m.
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(a)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
2:12 p.m.
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(a)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
8:55 p.m.
On Tue, Mar 12, 2019 at 2:25 PM Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
Hi Eduardo,
Am 12.03.19 um 08:58 schrieb Eduardo Martins:
> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom
(dependency management, plugins, etc.), which means that if we replace it
with a “local” parent pom then, for each release, we need to sync manually
such parents poms content… I don’t see any issue with using QS parent pom,
it seems that those archetypes were designed to generate clones of specific
quickstarts with just different Maven GAVs. Have you tried to install the
SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use
a tag such as 16.0.0.Final, which parent was released to Maven, instead of
pointing to QS master branch ?
>
> Honestly I’m not sure this kind of app archetype is of much interest as
it is, mostly due to the app's complexity, probably would be more helpful
almost “empty” apps, but if the idea is to have a QS clone tool then
perhaps a single generic archetype for that would make more sense. I’m open
to QS source changes needed to be friendly with such archetype :-)
>
> —E
I agree that the "wildfly-javaee7-webapp-ear-archetype" archetype is not
really useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which
consists of all necessary pom.xml files and some deployment descriptor
stubs. And *this* archetype is the reason why I started working on it:
it is a good starting point for a new JavaEE application which already
defines all necessary components.
I am willing to maintain this archetype for the next few years and
trying to release a version for each major WildFly version. As suggested
I would add a static root pom.xml to the archetype github project which
is independent of the quickstart files, as they are not "standalone".
This main pom.xml has to be updated for each WildFly version, but all
the other files still can be pulled from the "KitchensinkEar" quickstart.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
12:25 p.m.
On 12 Mar 2019, at 19:12, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
Hi Eduardo,
Am 12.03.19 um 08:58 schrieb Eduardo Martins:
> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom (dependency
management, plugins, etc.), which means that if we replace it with a “local” parent pom
then, for each release, we need to sync manually such parents poms content… I don’t see
any issue with using QS parent pom, it seems that those archetypes were designed to
generate clones of specific quickstarts with just different Maven GAVs. Have you tried to
install the SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use a
tag such as 16.0.0.Final, which parent was released to Maven, instead of pointing to QS
master branch ?
> Honestly I’m not sure this kind of app archetype is of much interest as it is, mostly
due to the app's complexity, probably would be more helpful almost “empty” apps, but
if the idea is to have a QS clone tool then perhaps a single generic archetype for that
would make more sense. I’m open to QS source changes needed to be friendly with such
archetype :-)
> —E
I agree that the "wildfly-javaee7-webapp-ear-archetype" archetype is not really
useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which consists of all
necessary pom.xml files and some deployment descriptor stubs. And *this* archetype is the
reason why I started working on it: it is a good starting point for a new JavaEE
application which already defines all necessary components.
I am willing to maintain this archetype for the next few years and trying to release a
version for each major WildFly version. As suggested I would add a static root pom.xml to
the archetype github project which is independent of the quickstart files, as they are not
"standalone". This main pom.xml has to be updated for each WildFly version, but
all the other files still can be pulled from the "KitchensinkEar" quickstart.
Then why get any sources from QS repo, having a proper do-nothing app project all locally
sounds better to me, probably less effort needed on every release too.
—E
2:14 p.m.
Am 13.03.19 um 18:25 schrieb Eduardo Martins:
> On 12 Mar 2019, at 19:12, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>
> Hi Eduardo,
>
> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom (dependency
management, plugins, etc.), which means that if we replace it with a “local” parent pom
then, for each release, we need to sync manually such parents poms content… I don’t see
any issue with using QS parent pom, it seems that those archetypes were designed to
generate clones of specific quickstarts with just different Maven GAVs. Have you tried to
install the SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use a
tag such as 16.0.0.Final, which parent was released to Maven, instead of pointing to QS
master branch ?
>> Honestly I’m not sure this kind of app archetype is of much interest as it is,
mostly due to the app's complexity, probably would be more helpful almost “empty”
apps, but if the idea is to have a QS clone tool then perhaps a single generic archetype
for that would make more sense. I’m open to QS source changes needed to be friendly with
such archetype :-)
>> —E
>
>
> I agree that the "wildfly-javaee7-webapp-ear-archetype" archetype is not
really useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which consists of all
necessary pom.xml files and some deployment descriptor stubs. And *this* archetype is the
reason why I started working on it: it is a good starting point for a new JavaEE
application which already defines all necessary components.
>
> I am willing to maintain this archetype for the next few years and trying to release
a version for each major WildFly version. As suggested I would add a static root pom.xml
to the archetype github project which is independent of the quickstart files, as they are
not "standalone". This main pom.xml has to be updated for each WildFly version,
but all the other files still can be pulled from the "KitchensinkEar"
quickstart.
>
Then why get any sources from QS repo, having a proper do-nothing app project all locally
sounds better to me, probably less effort needed on every release too.
—E
So you prefer to create a blank archetype which has no build
dependencies, just containing the relevant pom.xml files and maybe some
required files (don't know if there are any)? And this archetype is
updated by someone (e.g. me) each time a new major release is done?
Same applies to the other archetype, "wildfly-javaee7-webapp-archetype".
The wildfly-archetypes project contains two more archetypes
("wildfly-html5-mobile-archetype", "wildfly-subsystem-archetype"), but
I
did not even take a look at those.
Personally, I prefer the standalone approach, too. It means more work to
maintain it, but it is simpler ;-)
Please vote for any of those solutions ;-):
a) continue pulling from KitchensinkEAR quickstart ("blank" archetype
and archetype with a basic project)...
b) create standalone archetype (only "blank" archetype).
Best regards
Wolfgang
3:33 a.m.
The archetype sources should actually be simpler to maintain, no need to “fix” the
imported QS sources... I guess for most releases it would be to simply the effort to sync
some dependency management versions for the generated parent pom, e.g. WildFly BOMs
version.
Wrt the html5-mobile archetype, I believe it is similar to the ones you were looking at,
but pointing to an old QS that was removed at some point.
—E
On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>
>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>>
>> Hi Eduardo,
>>
>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom
(dependency management, plugins, etc.), which means that if we replace it with a “local”
parent pom then, for each release, we need to sync manually such parents poms content… I
don’t see any issue with using QS parent pom, it seems that those archetypes were designed
to generate clones of specific quickstarts with just different Maven GAVs. Have you tried
to install the SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use
a tag such as 16.0.0.Final, which parent was released to Maven, instead of pointing to QS
master branch ?
>>> Honestly I’m not sure this kind of app archetype is of much interest as it
is, mostly due to the app's complexity, probably would be more helpful almost “empty”
apps, but if the idea is to have a QS clone tool then perhaps a single generic archetype
for that would make more sense. I’m open to QS source changes needed to be friendly with
such archetype :-)
>>> —E
>>
>>
>> I agree that the "wildfly-javaee7-webapp-ear-archetype" archetype is
not really useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which consists of all
necessary pom.xml files and some deployment descriptor stubs. And *this* archetype is the
reason why I started working on it: it is a good starting point for a new JavaEE
application which already defines all necessary components.
>>
>> I am willing to maintain this archetype for the next few years and trying to
release a version for each major WildFly version. As suggested I would add a static root
pom.xml to the archetype github project which is independent of the quickstart files, as
they are not "standalone". This main pom.xml has to be updated for each WildFly
version, but all the other files still can be pulled from the "KitchensinkEar"
quickstart.
>>
>
> Then why get any sources from QS repo, having a proper do-nothing app project all
locally sounds better to me, probably less effort needed on every release too.
>
> —E
>
So you prefer to create a blank archetype which has no build
dependencies, just containing the relevant pom.xml files and maybe some
required files (don't know if there are any)? And this archetype is
updated by someone (e.g. me) each time a new major release is done?
Same applies to the other archetype, "wildfly-javaee7-webapp-archetype”.
The wildfly-archetypes project contains two more archetypes
("wildfly-html5-mobile-archetype", "wildfly-subsystem-archetype"),
but I
did not even take a look at those.
Personally, I prefer the standalone approach, too. It means more work to
maintain it, but it is simpler ;-)
Please vote for any of those solutions ;-):
a) continue pulling from KitchensinkEAR quickstart ("blank" archetype
and archetype with a basic project)...
b) create standalone archetype (only "blank" archetype).
Best regards
Wolfgang
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:03 p.m.
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(a)gmx.de> wrote:
>
>
> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>
>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
>>>
>>> Hi Eduardo,
>>>
>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom
(dependency management, plugins, etc.), which means that if we replace it with a “local”
parent pom then, for each release, we need to sync manually such parents poms content… I
don’t see any issue with using QS parent pom, it seems that those archetypes were designed
to generate clones of specific quickstarts with just different Maven GAVs. Have you tried
to install the SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use
a tag such as 16.0.0.Final, which parent was released to Maven, instead of pointing to QS
master branch ?
>>>> Honestly I’m not sure this kind of app archetype is of much interest as
it is, mostly due to the app's complexity, probably would be more helpful almost
“empty” apps, but if the idea is to have a QS clone tool then perhaps a single generic
archetype for that would make more sense. I’m open to QS source changes needed to be
friendly with such archetype :-)
>>>> —E
>>>
>>>
>>> I agree that the "wildfly-javaee7-webapp-ear-archetype" archetype
is not really useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which consists of all
necessary pom.xml files and some deployment descriptor stubs. And *this* archetype is the
reason why I started working on it: it is a good starting point for a new JavaEE
application which already defines all necessary components.
>>>
>>> I am willing to maintain this archetype for the next few years and trying to
release a version for each major WildFly version. As suggested I would add a static root
pom.xml to the archetype github project which is independent of the quickstart files, as
they are not "standalone". This main pom.xml has to be updated for each WildFly
version, but all the other files still can be pulled from the "KitchensinkEar"
quickstart.
>>>
>>
>> Then why get any sources from QS repo, having a proper do-nothing app project all
locally sounds better to me, probably less effort needed on every release too.
>>
>> —E
>>
>
> So you prefer to create a blank archetype which has no build
> dependencies, just containing the relevant pom.xml files and maybe some
> required files (don't know if there are any)? And this archetype is
> updated by someone (e.g. me) each time a new major release is done?
>
> Same applies to the other archetype, "wildfly-javaee7-webapp-archetype”.
> The wildfly-archetypes project contains two more archetypes
> ("wildfly-html5-mobile-archetype",
"wildfly-subsystem-archetype"), but I
> did not even take a look at those.
>
> Personally, I prefer the standalone approach, too. It means more work to
> maintain it, but it is simpler ;-)
>
> Please vote for any of those solutions ;-):
> a) continue pulling from KitchensinkEAR quickstart ("blank" archetype
> and archetype with a basic project)...
> b) create standalone archetype (only "blank" archetype).
>
>
> Best regards
>
> Wolfgang
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:49 p.m.
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(a)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(a)gmx.de> wrote:
>>
>>
>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>
>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
>>>>
>>>> Hi Eduardo,
>>>>
>>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>>> Hi Wolfgang, the kitchensink QS truly depends on the QS parent pom
(dependency management, plugins, etc.), which means that if we replace it
with a “local” parent pom then, for each release, we need to sync manually
such parents poms content… I don’t see any issue with using QS parent pom,
it seems that those archetypes were designed to generate clones of specific
quickstarts with just different Maven GAVs. Have you tried to install the
SNAPSHOT versioned QS parent first (mvn install -N at QS repo root), or use
a tag such as 16.0.0.Final, which parent was released to Maven, instead of
pointing to QS master branch ?
>>>>> Honestly I’m not sure this kind of app archetype is of much
interest
as it is, mostly due to the app's complexity, probably would be more
helpful almost “empty” apps, but if the idea is to have a QS clone tool
then perhaps a single generic archetype for that would make more sense. I’m
open to QS source changes needed to be friendly with such archetype :-)
>>>>> —E
>>>>
>>>>
>>>> I agree that the "wildfly-javaee7-webapp-ear-archetype"
archetype is
not really useful. But based on this archetype, an empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is generated, which consists
of all necessary pom.xml files and some deployment descriptor stubs. And
*this* archetype is the reason why I started working on it: it is a good
starting point for a new JavaEE application which already defines all
necessary components.
>>>>
>>>> I am willing to maintain this archetype for the next few years and
trying to release a version for each major WildFly version. As suggested I
would add a static root pom.xml to the archetype github project which is
independent of the quickstart files, as they are not "standalone". This
main pom.xml has to be updated for each WildFly version, but all the other
files still can be pulled from the "KitchensinkEar" quickstart.
>>>>
>>>
>>> Then why get any sources from QS repo, having a proper do-nothing app
project all locally sounds better to me, probably less effort needed on
every release too.
>>>
>>> —E
>>>
>>
>> So you prefer to create a blank archetype which has no build
>> dependencies, just containing the relevant pom.xml files and maybe some
>> required files (don't know if there are any)? And this archetype is
>> updated by someone (e.g. me) each time a new major release is done?
>>
>> Same applies to the other archetype, "wildfly-javaee7-webapp-archetype”.
>> The wildfly-archetypes project contains two more archetypes
>> ("wildfly-html5-mobile-archetype",
"wildfly-subsystem-archetype"), but I
>> did not even take a look at those.
>>
>> Personally, I prefer the standalone approach, too. It means more work to
>> maintain it, but it is simpler ;-)
>>
>> Please vote for any of those solutions ;-):
>> a) continue pulling from KitchensinkEAR quickstart ("blank" archetype
>> and archetype with a basic project)...
>> b) create standalone archetype (only "blank" archetype).
>>
>>
>> Best regards
>>
>> Wolfgang
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
6:09 a.m.
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(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
OK, so there are two votes (mine and Eduardo's) for "create a blank
archetype from scratch - no demo source included" and no vote for
"continue using the quickstart" approach.
Currently, I struggle with the archetype and will send a pull
request in
the next few days.
Any objections against the name "wildfly-javaee-webapp-ear-archetype"
(which means: a new subdirectory in git)?
If this is done, the next step would be to create a
"wildfly-javaee-webapp-archetype". And then someone could clean up the
old archetypes.
I think about adding a small integration test to the web project which
shows how to create the @Deployment using ShrinkWrap? The test itself
might have only dummy code, just the creation of the EAR file is
relevant. This might be helpful to users.
Best regards
Wolfgang
Am 18.03.19 um 09:33 schrieb Eduardo Martins:
> The archetype sources should actually be simpler to maintain, no
need to “fix” the imported QS sources... I guess for most releases
it would be to simply the effort to sync some dependency management
versions for the generated parent pom, e.g. WildFly BOMs version.
>
> Wrt the html5-mobile archetype, I believe it is similar to the
ones you were looking at, but pointing to an old QS that was removed
at some point.
>
> —E
>
>> On 13 Mar 2019, at 19:14, Wolfgang Knauf <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>
>>
>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>
>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>
>>>> Hi Eduardo,
>>>>
>>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>>> Hi Wolfgang, the kitchensink QS truly depends on the QS
parent pom (dependency management, plugins, etc.), which means that
if we replace it with a “local” parent pom then, for each release,
we need to sync manually such parents poms content… I don’t see any
issue with using QS parent pom, it seems that those archetypes were
designed to generate clones of specific quickstarts with just
different Maven GAVs. Have you tried to install the SNAPSHOT
versioned QS parent first (mvn install -N at QS repo root), or use a
tag such as 16.0.0.Final, which parent was released to Maven,
instead of pointing to QS master branch ?
>>>>> Honestly I’m not sure this kind of app archetype is of much
interest as it is, mostly due to the app's complexity, probably
would be more helpful almost “empty” apps, but if the idea is to
have a QS clone tool then perhaps a single generic archetype for
that would make more sense. I’m open to QS source changes needed to
be friendly with such archetype :-)
>>>>> —E
>>>>
>>>>
>>>> I agree that the "wildfly-javaee7-webapp-ear-archetype"
archetype is not really useful. But based on this archetype, an
empty archetype "wildfly-javaee7-webapp-ear-blank-archetype" is
generated, which consists of all necessary pom.xml files and some
deployment descriptor stubs. And *this* archetype is the reason why
I started working on it: it is a good starting point for a new
JavaEE application which already defines all necessary components.
>>>>
>>>> I am willing to maintain this archetype for the next few years
and trying to release a version for each major WildFly version. As
suggested I would add a static root pom.xml to the archetype github
project which is independent of the quickstart files, as they are
not "standalone". This main pom.xml has to be updated for each
WildFly version, but all the other files still can be pulled from
the "KitchensinkEar" quickstart.
>>>>
>>>
>>> Then why get any sources from QS repo, having a proper
do-nothing app project all locally sounds better to me, probably
less effort needed on every release too.
>>>
>>> —E
>>>
>>
>> So you prefer to create a blank archetype which has no build
>> dependencies, just containing the relevant pom.xml files and
maybe some
>> required files (don't know if there are any)? And this archetype is
>> updated by someone (e.g. me) each time a new major release is done?
>>
>> Same applies to the other archetype,
"wildfly-javaee7-webapp-archetype”.
>> The wildfly-archetypes project contains two more archetypes
>> ("wildfly-html5-mobile-archetype",
"wildfly-subsystem-archetype"), but I
>> did not even take a look at those.
>>
>> Personally, I prefer the standalone approach, too. It means more
work to
>> maintain it, but it is simpler ;-)
>>
>> Please vote for any of those solutions ;-):
>> a) continue pulling from KitchensinkEAR quickstart ("blank"
archetype
>> and archetype with a basic project)...
>> b) create standalone archetype (only "blank" archetype).
>>
>>
>> Best regards
>>
>> Wolfgang
6:47 a.m.
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(a)gmx.de
> <mailto:wolfgang.knauf@gmx.de>> wrote:
>
> OK, so there are two votes (mine and Eduardo's) for "create a blank
> archetype from scratch - no demo source included" and no vote for
> "continue using the quickstart" approach.
>
> Currently, I struggle with the archetype and will send a pull
> request in
> the next few days.
>
> Any objections against the name "wildfly-javaee-webapp-ear-archetype"
> (which means: a new subdirectory in git)?
>
> If this is done, the next step would be to create a
> "wildfly-javaee-webapp-archetype". And then someone could clean up
the
> old archetypes.
>
> I think about adding a small integration test to the web project which
> shows how to create the @Deployment using ShrinkWrap? The test itself
> might have only dummy code, just the creation of the EAR file is
> relevant. This might be helpful to users.
>
> Best regards
>
> Wolfgang
>
> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
> > The archetype sources should actually be simpler to maintain, no
> need to “fix” the imported QS sources... I guess for most releases
> it would be to simply the effort to sync some dependency management
> versions for the generated parent pom, e.g. WildFly BOMs version.
> >
> > Wrt the html5-mobile archetype, I believe it is similar to the
> ones you were looking at, but pointing to an old QS that was removed
> at some point.
> >
> > —E
> >
> >> On 13 Mar 2019, at 19:14, Wolfgang Knauf <wolfgang.knauf(a)gmx.de
> <mailto:wolfgang.knauf@gmx.de>> wrote:
> >>
> >>
> >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
> >>>
> >>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>> wrote:
> >>>>
> >>>> Hi Eduardo,
> >>>>
> >>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
> >>>>> Hi Wolfgang, the kitchensink QS truly depends on the QS
> parent pom (dependency management, plugins, etc.), which means that
> if we replace it with a “local” parent pom then, for each release,
> we need to sync manually such parents poms content… I don’t see any
> issue with using QS parent pom, it seems that those archetypes were
> designed to generate clones of specific quickstarts with just
> different Maven GAVs. Have you tried to install the SNAPSHOT
> versioned QS parent first (mvn install -N at QS repo root), or use a
> tag such as 16.0.0.Final, which parent was released to Maven,
> instead of pointing to QS master branch ?
> >>>>> Honestly I’m not sure this kind of app archetype is of
much
> interest as it is, mostly due to the app's complexity, probably
> would be more helpful almost “empty” apps, but if the idea is to
> have a QS clone tool then perhaps a single generic archetype for
> that would make more sense. I’m open to QS source changes needed to
> be friendly with such archetype :-)
> >>>>> —E
> >>>>
> >>>>
> >>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
> archetype is not really useful. But based on this archetype, an
> empty archetype "wildfly-javaee7-webapp-ear-blank-archetype" is
> generated, which consists of all necessary pom.xml files and some
> deployment descriptor stubs. And *this* archetype is the reason why
> I started working on it: it is a good starting point for a new
> JavaEE application which already defines all necessary components.
> >>>>
> >>>> I am willing to maintain this archetype for the next few
years
> and trying to release a version for each major WildFly version. As
> suggested I would add a static root pom.xml to the archetype github
> project which is independent of the quickstart files, as they are
> not "standalone". This main pom.xml has to be updated for each
> WildFly version, but all the other files still can be pulled from
> the "KitchensinkEar" quickstart.
> >>>>
> >>>
> >>> Then why get any sources from QS repo, having a proper
> do-nothing app project all locally sounds better to me, probably
> less effort needed on every release too.
> >>>
> >>> —E
> >>>
> >>
> >> So you prefer to create a blank archetype which has no build
> >> dependencies, just containing the relevant pom.xml files and
> maybe some
> >> required files (don't know if there are any)? And this archetype
is
> >> updated by someone (e.g. me) each time a new major release is done?
> >>
> >> Same applies to the other archetype,
> "wildfly-javaee7-webapp-archetype”.
> >> The wildfly-archetypes project contains two more archetypes
> >> ("wildfly-html5-mobile-archetype",
> "wildfly-subsystem-archetype"), but I
> >> did not even take a look at those.
> >>
> >> Personally, I prefer the standalone approach, too. It means more
> work to
> >> maintain it, but it is simpler ;-)
> >>
> >> Please vote for any of those solutions ;-):
> >> a) continue pulling from KitchensinkEAR quickstart ("blank"
> archetype
> >> and archetype with a basic project)...
> >> b) create standalone archetype (only "blank" archetype).
> >>
> >>
> >> Best regards
> >>
> >> Wolfgang
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:40 p.m.
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(a)gmx.de
>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>
>> OK, so there are two votes (mine and Eduardo's) for "create a
blank
>> archetype from scratch - no demo source included" and no vote for
>> "continue using the quickstart" approach.
>>
>> Currently, I struggle with the archetype and will send a pull
>> request in
>> the next few days.
>>
>> Any objections against the name
>> "wildfly-javaee-webapp-ear-archetype"
>> (which means: a new subdirectory in git)?
>>
>> If this is done, the next step would be to create a
>> "wildfly-javaee-webapp-archetype". And then someone could clean
>> up the
>> old archetypes.
>>
>> I think about adding a small integration test to the web project
>> which
>> shows how to create the @Deployment using ShrinkWrap? The test
>> itself
>> might have only dummy code, just the creation of the EAR file is
>> relevant. This might be helpful to users.
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>> > The archetype sources should actually be simpler to maintain, no
>> need to “fix” the imported QS sources... I guess for most releases
>> it would be to simply the effort to sync some dependency management
>> versions for the generated parent pom, e.g. WildFly BOMs version.
>> >
>> > Wrt the html5-mobile archetype, I believe it is similar to the
>> ones you were looking at, but pointing to an old QS that was
>> removed
>> at some point.
>> >
>> > —E
>> >
>> >> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>> >>
>> >>
>> >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>> >>>
>> >>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>> wrote:
>> >>>>
>> >>>> Hi Eduardo,
>> >>>>
>> >>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>> >>>>> Hi Wolfgang, the kitchensink QS truly depends on the
QS
>> parent pom (dependency management, plugins, etc.), which means that
>> if we replace it with a “local” parent pom then, for each release,
>> we need to sync manually such parents poms content… I don’t see any
>> issue with using QS parent pom, it seems that those archetypes were
>> designed to generate clones of specific quickstarts with just
>> different Maven GAVs. Have you tried to install the SNAPSHOT
>> versioned QS parent first (mvn install -N at QS repo root), or
>> use a
>> tag such as 16.0.0.Final, which parent was released to Maven,
>> instead of pointing to QS master branch ?
>> >>>>> Honestly I’m not sure this kind of app archetype is of
much
>> interest as it is, mostly due to the app's complexity, probably
>> would be more helpful almost “empty” apps, but if the idea is to
>> have a QS clone tool then perhaps a single generic archetype for
>> that would make more sense. I’m open to QS source changes needed to
>> be friendly with such archetype :-)
>> >>>>> —E
>> >>>>
>> >>>>
>> >>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>> archetype is not really useful. But based on this archetype, an
>> empty archetype "wildfly-javaee7-webapp-ear-blank-archetype" is
>> generated, which consists of all necessary pom.xml files and some
>> deployment descriptor stubs. And *this* archetype is the reason why
>> I started working on it: it is a good starting point for a new
>> JavaEE application which already defines all necessary components.
>> >>>>
>> >>>> I am willing to maintain this archetype for the next few
>> years
>> and trying to release a version for each major WildFly version. As
>> suggested I would add a static root pom.xml to the archetype github
>> project which is independent of the quickstart files, as they are
>> not "standalone". This main pom.xml has to be updated for each
>> WildFly version, but all the other files still can be pulled from
>> the "KitchensinkEar" quickstart.
>> >>>>
>> >>>
>> >>> Then why get any sources from QS repo, having a proper
>> do-nothing app project all locally sounds better to me, probably
>> less effort needed on every release too.
>> >>>
>> >>> —E
>> >>>
>> >>
>> >> So you prefer to create a blank archetype which has no build
>> >> dependencies, just containing the relevant pom.xml files and
>> maybe some
>> >> required files (don't know if there are any)? And this
>> archetype is
>> >> updated by someone (e.g. me) each time a new major release
>> is done?
>> >>
>> >> Same applies to the other archetype,
>> "wildfly-javaee7-webapp-archetype”.
>> >> The wildfly-archetypes project contains two more archetypes
>> >> ("wildfly-html5-mobile-archetype",
>> "wildfly-subsystem-archetype"), but I
>> >> did not even take a look at those.
>> >>
>> >> Personally, I prefer the standalone approach, too. It means
>> more
>> work to
>> >> maintain it, but it is simpler ;-)
>> >>
>> >> Please vote for any of those solutions ;-):
>> >> a) continue pulling from KitchensinkEAR quickstart
("blank"
>> archetype
>> >> and archetype with a basic project)...
>> >> b) create standalone archetype (only "blank"
archetype).
>> >>
>> >>
>> >> Best regards
>> >>
>> >> Wolfgang
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
2:34 p.m.
I will review it, soon hopefully.
—E
On 31 Mar 2019, at 19:40, Wolfgang Knauf
<wolfgang.knauf(a)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(a)gmx.de
>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>
>>> OK, so there are two votes (mine and Eduardo's) for "create a
blank
>>> archetype from scratch - no demo source included" and no vote for
>>> "continue using the quickstart" approach.
>>>
>>> Currently, I struggle with the archetype and will send a pull
>>> request in
>>> the next few days.
>>>
>>> Any objections against the name
>>> "wildfly-javaee-webapp-ear-archetype"
>>> (which means: a new subdirectory in git)?
>>>
>>> If this is done, the next step would be to create a
>>> "wildfly-javaee-webapp-archetype". And then someone could
clean
>>> up the
>>> old archetypes.
>>>
>>> I think about adding a small integration test to the web project
>>> which
>>> shows how to create the @Deployment using ShrinkWrap? The test
>>> itself
>>> might have only dummy code, just the creation of the EAR file is
>>> relevant. This might be helpful to users.
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>> > The archetype sources should actually be simpler to maintain, no
>>> need to “fix” the imported QS sources... I guess for most releases
>>> it would be to simply the effort to sync some dependency management
>>> versions for the generated parent pom, e.g. WildFly BOMs version.
>>> >
>>> > Wrt the html5-mobile archetype, I believe it is similar to the
>>> ones you were looking at, but pointing to an old QS that was
>>> removed
>>> at some point.
>>> >
>>> > —E
>>> >
>>> >> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>> >>
>>> >>
>>> >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>> >>>
>>> >>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>>
wrote:
>>> >>>>
>>> >>>> Hi Eduardo,
>>> >>>>
>>> >>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>> >>>>> Hi Wolfgang, the kitchensink QS truly depends on
the QS
>>> parent pom (dependency management, plugins, etc.), which means that
>>> if we replace it with a “local” parent pom then, for each release,
>>> we need to sync manually such parents poms content… I don’t see any
>>> issue with using QS parent pom, it seems that those archetypes were
>>> designed to generate clones of specific quickstarts with just
>>> different Maven GAVs. Have you tried to install the SNAPSHOT
>>> versioned QS parent first (mvn install -N at QS repo root), or
>>> use a
>>> tag such as 16.0.0.Final, which parent was released to Maven,
>>> instead of pointing to QS master branch ?
>>> >>>>> Honestly I’m not sure this kind of app archetype
is of much
>>> interest as it is, mostly due to the app's complexity, probably
>>> would be more helpful almost “empty” apps, but if the idea is to
>>> have a QS clone tool then perhaps a single generic archetype for
>>> that would make more sense. I’m open to QS source changes needed to
>>> be friendly with such archetype :-)
>>> >>>>> —E
>>> >>>>
>>> >>>>
>>> >>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>> archetype is not really useful. But based on this archetype, an
>>> empty archetype "wildfly-javaee7-webapp-ear-blank-archetype"
is
>>> generated, which consists of all necessary pom.xml files and some
>>> deployment descriptor stubs. And *this* archetype is the reason why
>>> I started working on it: it is a good starting point for a new
>>> JavaEE application which already defines all necessary components.
>>> >>>>
>>> >>>> I am willing to maintain this archetype for the next
few
>>> years
>>> and trying to release a version for each major WildFly version. As
>>> suggested I would add a static root pom.xml to the archetype github
>>> project which is independent of the quickstart files, as they are
>>> not "standalone". This main pom.xml has to be updated for
each
>>> WildFly version, but all the other files still can be pulled from
>>> the "KitchensinkEar" quickstart.
>>> >>>>
>>> >>>
>>> >>> Then why get any sources from QS repo, having a proper
>>> do-nothing app project all locally sounds better to me, probably
>>> less effort needed on every release too.
>>> >>>
>>> >>> —E
>>> >>>
>>> >>
>>> >> So you prefer to create a blank archetype which has no build
>>> >> dependencies, just containing the relevant pom.xml files and
>>> maybe some
>>> >> required files (don't know if there are any)? And this
>>> archetype is
>>> >> updated by someone (e.g. me) each time a new major release
>>> is done?
>>> >>
>>> >> Same applies to the other archetype,
>>> "wildfly-javaee7-webapp-archetype”.
>>> >> The wildfly-archetypes project contains two more archetypes
>>> >> ("wildfly-html5-mobile-archetype",
>>> "wildfly-subsystem-archetype"), but I
>>> >> did not even take a look at those.
>>> >>
>>> >> Personally, I prefer the standalone approach, too. It means
>>> more
>>> work to
>>> >> maintain it, but it is simpler ;-)
>>> >>
>>> >> Please vote for any of those solutions ;-):
>>> >> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>> archetype
>>> >> and archetype with a basic project)...
>>> >> b) create standalone archetype (only "blank"
archetype).
>>> >>
>>> >>
>>> >> Best regards
>>> >>
>>> >> Wolfgang
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:50 p.m.
Hi,
just want to ask for an update ;-)
Best regards
Wolfgang
Am 31.03.19 um 21:34 schrieb Eduardo Martins:
I will review it, soon hopefully.
—E
> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)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(a)gmx.de
>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>
>>>> OK, so there are two votes (mine and Eduardo's) for
"create a blank
>>>> archetype from scratch - no demo source included" and no vote
for
>>>> "continue using the quickstart" approach.
>>>>
>>>> Currently, I struggle with the archetype and will send a pull
>>>> request in
>>>> the next few days.
>>>>
>>>> Any objections against the name
>>>> "wildfly-javaee-webapp-ear-archetype"
>>>> (which means: a new subdirectory in git)?
>>>>
>>>> If this is done, the next step would be to create a
>>>> "wildfly-javaee-webapp-archetype". And then someone could
clean
>>>> up the
>>>> old archetypes.
>>>>
>>>> I think about adding a small integration test to the web project
>>>> which
>>>> shows how to create the @Deployment using ShrinkWrap? The test
>>>> itself
>>>> might have only dummy code, just the creation of the EAR file is
>>>> relevant. This might be helpful to users.
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>>> > The archetype sources should actually be simpler to maintain,
no
>>>> need to “fix” the imported QS sources... I guess for most releases
>>>> it would be to simply the effort to sync some dependency
management
>>>> versions for the generated parent pom, e.g. WildFly BOMs version.
>>>> >
>>>> > Wrt the html5-mobile archetype, I believe it is similar to
the
>>>> ones you were looking at, but pointing to an old QS that was
>>>> removed
>>>> at some point.
>>>> >
>>>> > —E
>>>> >
>>>> >> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>> >>
>>>> >>
>>>> >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>> >>>
>>>> >>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>>
wrote:
>>>> >>>>
>>>> >>>> Hi Eduardo,
>>>> >>>>
>>>> >>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>> >>>>> Hi Wolfgang, the kitchensink QS truly depends
on the QS
>>>> parent pom (dependency management, plugins, etc.), which means
that
>>>> if we replace it with a “local” parent pom then, for each release,
>>>> we need to sync manually such parents poms content… I don’t see
any
>>>> issue with using QS parent pom, it seems that those archetypes
were
>>>> designed to generate clones of specific quickstarts with just
>>>> different Maven GAVs. Have you tried to install the SNAPSHOT
>>>> versioned QS parent first (mvn install -N at QS repo root), or
>>>> use a
>>>> tag such as 16.0.0.Final, which parent was released to Maven,
>>>> instead of pointing to QS master branch ?
>>>> >>>>> Honestly I’m not sure this kind of app
archetype is of much
>>>> interest as it is, mostly due to the app's complexity,
probably
>>>> would be more helpful almost “empty” apps, but if the idea is to
>>>> have a QS clone tool then perhaps a single generic archetype for
>>>> that would make more sense. I’m open to QS source changes needed
to
>>>> be friendly with such archetype :-)
>>>> >>>>> —E
>>>> >>>>
>>>> >>>>
>>>> >>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>>> archetype is not really useful. But based on this archetype, an
>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
>>>> generated, which consists of all necessary pom.xml files and some
>>>> deployment descriptor stubs. And *this* archetype is the reason
why
>>>> I started working on it: it is a good starting point for a new
>>>> JavaEE application which already defines all necessary components.
>>>> >>>>
>>>> >>>> I am willing to maintain this archetype for the
next few
>>>> years
>>>> and trying to release a version for each major WildFly version. As
>>>> suggested I would add a static root pom.xml to the archetype
github
>>>> project which is independent of the quickstart files, as they are
>>>> not "standalone". This main pom.xml has to be updated for
each
>>>> WildFly version, but all the other files still can be pulled from
>>>> the "KitchensinkEar" quickstart.
>>>> >>>>
>>>> >>>
>>>> >>> Then why get any sources from QS repo, having a
proper
>>>> do-nothing app project all locally sounds better to me, probably
>>>> less effort needed on every release too.
>>>> >>>
>>>> >>> —E
>>>> >>>
>>>> >>
>>>> >> So you prefer to create a blank archetype which has no
build
>>>> >> dependencies, just containing the relevant pom.xml files
and
>>>> maybe some
>>>> >> required files (don't know if there are any)? And
this
>>>> archetype is
>>>> >> updated by someone (e.g. me) each time a new major
release
>>>> is done?
>>>> >>
>>>> >> Same applies to the other archetype,
>>>> "wildfly-javaee7-webapp-archetype”.
>>>> >> The wildfly-archetypes project contains two more
archetypes
>>>> >> ("wildfly-html5-mobile-archetype",
>>>> "wildfly-subsystem-archetype"), but I
>>>> >> did not even take a look at those.
>>>> >>
>>>> >> Personally, I prefer the standalone approach, too. It
means
>>>> more
>>>> work to
>>>> >> maintain it, but it is simpler ;-)
>>>> >>
>>>> >> Please vote for any of those solutions ;-):
>>>> >> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>>> archetype
>>>> >> and archetype with a basic project)...
>>>> >> b) create standalone archetype (only "blank"
archetype).
>>>> >>
>>>> >>
>>>> >> Best regards
>>>> >>
>>>> >> Wolfgang
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:18 a.m.
Hi Wolfgang, I actually did start reviewing it, but unfortunately had to put it on hold
due to unexpected blocker kind of priority tasks/issues needed to be solved asap. If
nothing urgent comes I should be able to finish the review the next couple of days.
—E
On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
Hi,
just want to ask for an update ;-)
Best regards
Wolfgang
Am 31.03.19 um 21:34 schrieb Eduardo Martins:
> I will review it, soon hopefully.
>
> —E
>
>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)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(a)gmx.de
>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>
>>>>> OK, so there are two votes (mine and Eduardo's) for
"create a blank
>>>>> archetype from scratch - no demo source included" and no
vote for
>>>>> "continue using the quickstart" approach.
>>>>>
>>>>> Currently, I struggle with the archetype and will send a pull
>>>>> request in
>>>>> the next few days.
>>>>>
>>>>> Any objections against the name
>>>>> "wildfly-javaee-webapp-ear-archetype"
>>>>> (which means: a new subdirectory in git)?
>>>>>
>>>>> If this is done, the next step would be to create a
>>>>> "wildfly-javaee-webapp-archetype". And then someone
could clean
>>>>> up the
>>>>> old archetypes.
>>>>>
>>>>> I think about adding a small integration test to the web
project
>>>>> which
>>>>> shows how to create the @Deployment using ShrinkWrap? The test
>>>>> itself
>>>>> might have only dummy code, just the creation of the EAR file
is
>>>>> relevant. This might be helpful to users.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Wolfgang
>>>>>
>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>>>>> The archetype sources should actually be simpler to maintain, no
>>>>> need to “fix” the imported QS sources... I guess for most
releases
>>>>> it would be to simply the effort to sync some dependency
management
>>>>> versions for the generated parent pom, e.g. WildFly BOMs
version.
>>>>>>
>>>>>> Wrt the html5-mobile archetype, I believe it is similar to the
>>>>> ones you were looking at, but pointing to an old QS that was
>>>>> removed
>>>>> at some point.
>>>>>>
>>>>>> —E
>>>>>>
>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>>>>>>
>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Eduardo,
>>>>>>>>>
>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>>>>>>>> Hi Wolfgang, the kitchensink QS truly depends on
the QS
>>>>> parent pom (dependency management, plugins, etc.), which means
that
>>>>> if we replace it with a “local” parent pom then, for each
release,
>>>>> we need to sync manually such parents poms content… I don’t see
any
>>>>> issue with using QS parent pom, it seems that those archetypes
were
>>>>> designed to generate clones of specific quickstarts with just
>>>>> different Maven GAVs. Have you tried to install the SNAPSHOT
>>>>> versioned QS parent first (mvn install -N at QS repo root), or
>>>>> use a
>>>>> tag such as 16.0.0.Final, which parent was released to Maven,
>>>>> instead of pointing to QS master branch ?
>>>>>>>>>> Honestly I’m not sure this kind of app archetype
is of much
>>>>> interest as it is, mostly due to the app's complexity,
probably
>>>>> would be more helpful almost “empty” apps, but if the idea is
to
>>>>> have a QS clone tool then perhaps a single generic archetype
for
>>>>> that would make more sense. I’m open to QS source changes needed
to
>>>>> be friendly with such archetype :-)
>>>>>>>>>> —E
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>>>> archetype is not really useful. But based on this archetype, an
>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
>>>>> generated, which consists of all necessary pom.xml files and
some
>>>>> deployment descriptor stubs. And *this* archetype is the reason
why
>>>>> I started working on it: it is a good starting point for a new
>>>>> JavaEE application which already defines all necessary
components.
>>>>>>>>>
>>>>>>>>> I am willing to maintain this archetype for the next
few
>>>>> years
>>>>> and trying to release a version for each major WildFly version.
As
>>>>> suggested I would add a static root pom.xml to the archetype
github
>>>>> project which is independent of the quickstart files, as they
are
>>>>> not "standalone". This main pom.xml has to be updated
for each
>>>>> WildFly version, but all the other files still can be pulled
from
>>>>> the "KitchensinkEar" quickstart.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then why get any sources from QS repo, having a proper
>>>>> do-nothing app project all locally sounds better to me,
probably
>>>>> less effort needed on every release too.
>>>>>>>>
>>>>>>>> —E
>>>>>>>>
>>>>>>>
>>>>>>> So you prefer to create a blank archetype which has no build
>>>>>>> dependencies, just containing the relevant pom.xml files and
>>>>> maybe some
>>>>>>> required files (don't know if there are any)? And this
>>>>> archetype is
>>>>>>> updated by someone (e.g. me) each time a new major release
>>>>> is done?
>>>>>>>
>>>>>>> Same applies to the other archetype,
>>>>> "wildfly-javaee7-webapp-archetype”.
>>>>>>> The wildfly-archetypes project contains two more archetypes
>>>>>>> ("wildfly-html5-mobile-archetype",
>>>>> "wildfly-subsystem-archetype"), but I
>>>>>>> did not even take a look at those.
>>>>>>>
>>>>>>> Personally, I prefer the standalone approach, too. It means
>>>>> more
>>>>> work to
>>>>>>> maintain it, but it is simpler ;-)
>>>>>>>
>>>>>>> Please vote for any of those solutions ;-):
>>>>>>> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>>>> archetype
>>>>>>> and archetype with a basic project)...
>>>>>>> b) create standalone archetype (only "blank"
archetype).
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Wolfgang
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:07 p.m.
Hi Wolfgang, generally it looks good, just a few minor changes requested on your GitHub PR
review, let’s continue over there please.
—E
On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com>
wrote:
Hi Wolfgang, I actually did start reviewing it, but unfortunately had to put it on hold
due to unexpected blocker kind of priority tasks/issues needed to be solved asap. If
nothing urgent comes I should be able to finish the review the next couple of days.
—E
> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>
> Hi,
>
> just want to ask for an update ;-)
>
> Best regards
>
> Wolfgang
>
> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
>> I will review it, soon hopefully.
>>
>> —E
>>
>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)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(a)gmx.de
>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>
>>>>>> OK, so there are two votes (mine and Eduardo's) for
"create a blank
>>>>>> archetype from scratch - no demo source included" and no
vote for
>>>>>> "continue using the quickstart" approach.
>>>>>>
>>>>>> Currently, I struggle with the archetype and will send a
pull
>>>>>> request in
>>>>>> the next few days.
>>>>>>
>>>>>> Any objections against the name
>>>>>> "wildfly-javaee-webapp-ear-archetype"
>>>>>> (which means: a new subdirectory in git)?
>>>>>>
>>>>>> If this is done, the next step would be to create a
>>>>>> "wildfly-javaee-webapp-archetype". And then someone
could clean
>>>>>> up the
>>>>>> old archetypes.
>>>>>>
>>>>>> I think about adding a small integration test to the web
project
>>>>>> which
>>>>>> shows how to create the @Deployment using ShrinkWrap? The
test
>>>>>> itself
>>>>>> might have only dummy code, just the creation of the EAR file
is
>>>>>> relevant. This might be helpful to users.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>>>>>> The archetype sources should actually be simpler to maintain,
no
>>>>>> need to “fix” the imported QS sources... I guess for most
releases
>>>>>> it would be to simply the effort to sync some dependency
management
>>>>>> versions for the generated parent pom, e.g. WildFly BOMs
version.
>>>>>>>
>>>>>>> Wrt the html5-mobile archetype, I believe it is similar to
the
>>>>>> ones you were looking at, but pointing to an old QS that was
>>>>>> removed
>>>>>> at some point.
>>>>>>>
>>>>>>> —E
>>>>>>>
>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>>>>>>>
>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Eduardo,
>>>>>>>>>>
>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>>>>>>>>> Hi Wolfgang, the kitchensink QS truly depends
on the QS
>>>>>> parent pom (dependency management, plugins, etc.), which
means that
>>>>>> if we replace it with a “local” parent pom then, for each
release,
>>>>>> we need to sync manually such parents poms content… I don’t
see any
>>>>>> issue with using QS parent pom, it seems that those
archetypes were
>>>>>> designed to generate clones of specific quickstarts with
just
>>>>>> different Maven GAVs. Have you tried to install the SNAPSHOT
>>>>>> versioned QS parent first (mvn install -N at QS repo root),
or
>>>>>> use a
>>>>>> tag such as 16.0.0.Final, which parent was released to
Maven,
>>>>>> instead of pointing to QS master branch ?
>>>>>>>>>>> Honestly I’m not sure this kind of app
archetype is of much
>>>>>> interest as it is, mostly due to the app's complexity,
probably
>>>>>> would be more helpful almost “empty” apps, but if the idea is
to
>>>>>> have a QS clone tool then perhaps a single generic archetype
for
>>>>>> that would make more sense. I’m open to QS source changes
needed to
>>>>>> be friendly with such archetype :-)
>>>>>>>>>>> —E
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>>>>> archetype is not really useful. But based on this archetype,
an
>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
>>>>>> generated, which consists of all necessary pom.xml files and
some
>>>>>> deployment descriptor stubs. And *this* archetype is the
reason why
>>>>>> I started working on it: it is a good starting point for a
new
>>>>>> JavaEE application which already defines all necessary
components.
>>>>>>>>>>
>>>>>>>>>> I am willing to maintain this archetype for the
next few
>>>>>> years
>>>>>> and trying to release a version for each major WildFly
version. As
>>>>>> suggested I would add a static root pom.xml to the archetype
github
>>>>>> project which is independent of the quickstart files, as they
are
>>>>>> not "standalone". This main pom.xml has to be
updated for each
>>>>>> WildFly version, but all the other files still can be pulled
from
>>>>>> the "KitchensinkEar" quickstart.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then why get any sources from QS repo, having a
proper
>>>>>> do-nothing app project all locally sounds better to me,
probably
>>>>>> less effort needed on every release too.
>>>>>>>>>
>>>>>>>>> —E
>>>>>>>>>
>>>>>>>>
>>>>>>>> So you prefer to create a blank archetype which has no
build
>>>>>>>> dependencies, just containing the relevant pom.xml files
and
>>>>>> maybe some
>>>>>>>> required files (don't know if there are any)? And
this
>>>>>> archetype is
>>>>>>>> updated by someone (e.g. me) each time a new major
release
>>>>>> is done?
>>>>>>>>
>>>>>>>> Same applies to the other archetype,
>>>>>> "wildfly-javaee7-webapp-archetype”.
>>>>>>>> The wildfly-archetypes project contains two more
archetypes
>>>>>>>> ("wildfly-html5-mobile-archetype",
>>>>>> "wildfly-subsystem-archetype"), but I
>>>>>>>> did not even take a look at those.
>>>>>>>>
>>>>>>>> Personally, I prefer the standalone approach, too. It
means
>>>>>> more
>>>>>> work to
>>>>>>>> maintain it, but it is simpler ;-)
>>>>>>>>
>>>>>>>> Please vote for any of those solutions ;-):
>>>>>>>> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>>>>> archetype
>>>>>>>> and archetype with a basic project)...
>>>>>>>> b) create standalone archetype (only "blank"
archetype).
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Wolfgang
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:10 p.m.
Brian, any idea what to do wrt the subsystem archetypes? ATM even build fails and most
likely there is someone else better than me to look into that…
—E
On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com>
wrote:
Hi Wolfgang, I actually did start reviewing it, but unfortunately had to put it on hold
due to unexpected blocker kind of priority tasks/issues needed to be solved asap. If
nothing urgent comes I should be able to finish the review the next couple of days.
—E
> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>
> Hi,
>
> just want to ask for an update ;-)
>
> Best regards
>
> Wolfgang
>
> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
>> I will review it, soon hopefully.
>>
>> —E
>>
>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)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(a)gmx.de
>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>
>>>>>> OK, so there are two votes (mine and Eduardo's) for
"create a blank
>>>>>> archetype from scratch - no demo source included" and no
vote for
>>>>>> "continue using the quickstart" approach.
>>>>>>
>>>>>> Currently, I struggle with the archetype and will send a
pull
>>>>>> request in
>>>>>> the next few days.
>>>>>>
>>>>>> Any objections against the name
>>>>>> "wildfly-javaee-webapp-ear-archetype"
>>>>>> (which means: a new subdirectory in git)?
>>>>>>
>>>>>> If this is done, the next step would be to create a
>>>>>> "wildfly-javaee-webapp-archetype". And then someone
could clean
>>>>>> up the
>>>>>> old archetypes.
>>>>>>
>>>>>> I think about adding a small integration test to the web
project
>>>>>> which
>>>>>> shows how to create the @Deployment using ShrinkWrap? The
test
>>>>>> itself
>>>>>> might have only dummy code, just the creation of the EAR file
is
>>>>>> relevant. This might be helpful to users.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>>>>>> The archetype sources should actually be simpler to maintain,
no
>>>>>> need to “fix” the imported QS sources... I guess for most
releases
>>>>>> it would be to simply the effort to sync some dependency
management
>>>>>> versions for the generated parent pom, e.g. WildFly BOMs
version.
>>>>>>>
>>>>>>> Wrt the html5-mobile archetype, I believe it is similar to
the
>>>>>> ones you were looking at, but pointing to an old QS that was
>>>>>> removed
>>>>>> at some point.
>>>>>>>
>>>>>>> —E
>>>>>>>
>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>>>>>>>
>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Eduardo,
>>>>>>>>>>
>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo Martins:
>>>>>>>>>>> Hi Wolfgang, the kitchensink QS truly depends
on the QS
>>>>>> parent pom (dependency management, plugins, etc.), which
means that
>>>>>> if we replace it with a “local” parent pom then, for each
release,
>>>>>> we need to sync manually such parents poms content… I don’t
see any
>>>>>> issue with using QS parent pom, it seems that those
archetypes were
>>>>>> designed to generate clones of specific quickstarts with
just
>>>>>> different Maven GAVs. Have you tried to install the SNAPSHOT
>>>>>> versioned QS parent first (mvn install -N at QS repo root),
or
>>>>>> use a
>>>>>> tag such as 16.0.0.Final, which parent was released to
Maven,
>>>>>> instead of pointing to QS master branch ?
>>>>>>>>>>> Honestly I’m not sure this kind of app
archetype is of much
>>>>>> interest as it is, mostly due to the app's complexity,
probably
>>>>>> would be more helpful almost “empty” apps, but if the idea is
to
>>>>>> have a QS clone tool then perhaps a single generic archetype
for
>>>>>> that would make more sense. I’m open to QS source changes
needed to
>>>>>> be friendly with such archetype :-)
>>>>>>>>>>> —E
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>>>>> archetype is not really useful. But based on this archetype,
an
>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
>>>>>> generated, which consists of all necessary pom.xml files and
some
>>>>>> deployment descriptor stubs. And *this* archetype is the
reason why
>>>>>> I started working on it: it is a good starting point for a
new
>>>>>> JavaEE application which already defines all necessary
components.
>>>>>>>>>>
>>>>>>>>>> I am willing to maintain this archetype for the
next few
>>>>>> years
>>>>>> and trying to release a version for each major WildFly
version. As
>>>>>> suggested I would add a static root pom.xml to the archetype
github
>>>>>> project which is independent of the quickstart files, as they
are
>>>>>> not "standalone". This main pom.xml has to be
updated for each
>>>>>> WildFly version, but all the other files still can be pulled
from
>>>>>> the "KitchensinkEar" quickstart.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then why get any sources from QS repo, having a
proper
>>>>>> do-nothing app project all locally sounds better to me,
probably
>>>>>> less effort needed on every release too.
>>>>>>>>>
>>>>>>>>> —E
>>>>>>>>>
>>>>>>>>
>>>>>>>> So you prefer to create a blank archetype which has no
build
>>>>>>>> dependencies, just containing the relevant pom.xml files
and
>>>>>> maybe some
>>>>>>>> required files (don't know if there are any)? And
this
>>>>>> archetype is
>>>>>>>> updated by someone (e.g. me) each time a new major
release
>>>>>> is done?
>>>>>>>>
>>>>>>>> Same applies to the other archetype,
>>>>>> "wildfly-javaee7-webapp-archetype”.
>>>>>>>> The wildfly-archetypes project contains two more
archetypes
>>>>>>>> ("wildfly-html5-mobile-archetype",
>>>>>> "wildfly-subsystem-archetype"), but I
>>>>>>>> did not even take a look at those.
>>>>>>>>
>>>>>>>> Personally, I prefer the standalone approach, too. It
means
>>>>>> more
>>>>>> work to
>>>>>>>> maintain it, but it is simpler ;-)
>>>>>>>>
>>>>>>>> Please vote for any of those solutions ;-):
>>>>>>>> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>>>>> archetype
>>>>>>>> and archetype with a basic project)...
>>>>>>>> b) create standalone archetype (only "blank"
archetype).
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Wolfgang
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:46 p.m.
Is that blocking this Eduardo?
If not, updating those is a pretty big task and right now I don't see it
happening anytime soon.
On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins(a)redhat.com> wrote:
Brian, any idea what to do wrt the subsystem archetypes? ATM even
build
fails and most likely there is someone else better than me to look into
that…
—E
> On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com> wrote:
>
> Hi Wolfgang, I actually did start reviewing it, but unfortunately had to
put it on hold due to unexpected blocker kind of priority tasks/issues
needed to be solved asap. If nothing urgent comes I should be able to
finish the review the next couple of days.
>
> —E
>
>> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>>
>> Hi,
>>
>> just want to ask for an update ;-)
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
>>> I will review it, soon hopefully.
>>>
>>> —E
>>>
>>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)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(a)gmx.de
>>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>
>>>>>>> OK, so there are two votes (mine and Eduardo's) for
"create a
blank
>>>>>>> archetype from scratch - no demo source included"
and no vote
for
>>>>>>> "continue using the quickstart" approach.
>>>>>>>
>>>>>>> Currently, I struggle with the archetype and will send a
pull
>>>>>>> request in
>>>>>>> the next few days.
>>>>>>>
>>>>>>> Any objections against the name
>>>>>>> "wildfly-javaee-webapp-ear-archetype"
>>>>>>> (which means: a new subdirectory in git)?
>>>>>>>
>>>>>>> If this is done, the next step would be to create a
>>>>>>> "wildfly-javaee-webapp-archetype". And then
someone could clean
>>>>>>> up the
>>>>>>> old archetypes.
>>>>>>>
>>>>>>> I think about adding a small integration test to the
web
project
>>>>>>> which
>>>>>>> shows how to create the @Deployment using ShrinkWrap?
The test
>>>>>>> itself
>>>>>>> might have only dummy code, just the creation of the EAR
file
is
>>>>>>> relevant. This might be helpful to users.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Wolfgang
>>>>>>>
>>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>>>>>>> The archetype sources should actually be simpler to
maintain, no
>>>>>>> need to “fix” the imported QS sources... I guess for
most
releases
>>>>>>> it would be to simply the effort to sync some
dependency
management
>>>>>>> versions for the generated parent pom, e.g. WildFly
BOMs
version.
>>>>>>>>
>>>>>>>> Wrt the html5-mobile archetype, I believe it is similar
to the
>>>>>>> ones you were looking at, but pointing to an old QS that
was
>>>>>>> removed
>>>>>>> at some point.
>>>>>>>>
>>>>>>>> —E
>>>>>>>>
>>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
>>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>>>>>>>>
>>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Eduardo,
>>>>>>>>>>>
>>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo
Martins:
>>>>>>>>>>>> Hi Wolfgang, the kitchensink QS truly
depends on the QS
>>>>>>> parent pom (dependency management, plugins, etc.), which
means
that
>>>>>>> if we replace it with a “local” parent pom then, for
each
release,
>>>>>>> we need to sync manually such parents poms content… I
don’t
see any
>>>>>>> issue with using QS parent pom, it seems that those
archetypes
were
>>>>>>> designed to generate clones of specific quickstarts with
just
>>>>>>> different Maven GAVs. Have you tried to install the
SNAPSHOT
>>>>>>> versioned QS parent first (mvn install -N at QS repo
root), or
>>>>>>> use a
>>>>>>> tag such as 16.0.0.Final, which parent was released to
Maven,
>>>>>>> instead of pointing to QS master branch ?
>>>>>>>>>>>> Honestly I’m not sure this kind of app
archetype is of much
>>>>>>> interest as it is, mostly due to the app's
complexity, probably
>>>>>>> would be more helpful almost “empty” apps, but if the
idea is
to
>>>>>>> have a QS clone tool then perhaps a single generic
archetype
for
>>>>>>> that would make more sense. I’m open to QS source
changes
needed to
>>>>>>> be friendly with such archetype :-)
>>>>>>>>>>>> —E
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>>>>>> archetype is not really useful. But based on this
archetype, an
>>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
>>>>>>> generated, which consists of all necessary pom.xml files
and
some
>>>>>>> deployment descriptor stubs. And *this* archetype is
the
reason why
>>>>>>> I started working on it: it is a good starting point for
a new
>>>>>>> JavaEE application which already defines all necessary
components.
>>>>>>>>>>>
>>>>>>>>>>> I am willing to maintain this archetype for
the next few
>>>>>>> years
>>>>>>> and trying to release a version for each major WildFly
version. As
>>>>>>> suggested I would add a static root pom.xml to the
archetype
github
>>>>>>> project which is independent of the quickstart files, as
they
are
>>>>>>> not "standalone". This main pom.xml has to be
updated for each
>>>>>>> WildFly version, but all the other files still can be
pulled
from
>>>>>>> the "KitchensinkEar" quickstart.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then why get any sources from QS repo, having a
proper
>>>>>>> do-nothing app project all locally sounds better to me,
probably
>>>>>>> less effort needed on every release too.
>>>>>>>>>>
>>>>>>>>>> —E
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So you prefer to create a blank archetype which has
no build
>>>>>>>>> dependencies, just containing the relevant pom.xml
files and
>>>>>>> maybe some
>>>>>>>>> required files (don't know if there are any)?
And this
>>>>>>> archetype is
>>>>>>>>> updated by someone (e.g. me) each time a new major
release
>>>>>>> is done?
>>>>>>>>>
>>>>>>>>> Same applies to the other archetype,
>>>>>>> "wildfly-javaee7-webapp-archetype”.
>>>>>>>>> The wildfly-archetypes project contains two more
archetypes
>>>>>>>>> ("wildfly-html5-mobile-archetype",
>>>>>>> "wildfly-subsystem-archetype"), but I
>>>>>>>>> did not even take a look at those.
>>>>>>>>>
>>>>>>>>> Personally, I prefer the standalone approach, too.
It means
>>>>>>> more
>>>>>>> work to
>>>>>>>>> maintain it, but it is simpler ;-)
>>>>>>>>>
>>>>>>>>> Please vote for any of those solutions ;-):
>>>>>>>>> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>>>>>> archetype
>>>>>>>>> and archetype with a basic project)...
>>>>>>>>> b) create standalone archetype (only
"blank" archetype).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Wolfgang
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
6:34 p.m.
If you think it’s not a small effort task then certainly agree that’s not a
blocker, I look at the archetypes same way as the quickstarts, an
aggregation project, so we may take outdated/faulty ones out of build and
release the working+actual ones. We may give it a thought later if it makes
sense effort wise to update or drop the subsystem ones, no worries.
—E
On Fri, 10 May 2019 at 21:46, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
Is that blocking this Eduardo?
If not, updating those is a pretty big task and right now I don't see it
happening anytime soon.
On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins(a)redhat.com>
wrote:
> Brian, any idea what to do wrt the subsystem archetypes? ATM even build
> fails and most likely there is someone else better than me to look into
> that…
>
> —E
>
> > On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com> wrote:
> >
> > Hi Wolfgang, I actually did start reviewing it, but unfortunately had
> to put it on hold due to unexpected blocker kind of priority tasks/issues
> needed to be solved asap. If nothing urgent comes I should be able to
> finish the review the next couple of days.
> >
> > —E
> >
> >> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
> >>
> >> Hi,
> >>
> >> just want to ask for an update ;-)
> >>
> >> Best regards
> >>
> >> Wolfgang
> >>
> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
> >>> I will review it, soon hopefully.
> >>>
> >>> —E
> >>>
> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf
<wolfgang.knauf(a)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(a)gmx.de
> >>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
> >>>>>>>
> >>>>>>> OK, so there are two votes (mine and Eduardo's)
for "create a
> blank
> >>>>>>> archetype from scratch - no demo source
included" and no vote
> for
> >>>>>>> "continue using the quickstart" approach.
> >>>>>>>
> >>>>>>> Currently, I struggle with the archetype and will
send a pull
> >>>>>>> request in
> >>>>>>> the next few days.
> >>>>>>>
> >>>>>>> Any objections against the name
> >>>>>>> "wildfly-javaee-webapp-ear-archetype"
> >>>>>>> (which means: a new subdirectory in git)?
> >>>>>>>
> >>>>>>> If this is done, the next step would be to create a
> >>>>>>> "wildfly-javaee-webapp-archetype". And
then someone could
> clean
> >>>>>>> up the
> >>>>>>> old archetypes.
> >>>>>>>
> >>>>>>> I think about adding a small integration test to the
web
> project
> >>>>>>> which
> >>>>>>> shows how to create the @Deployment using
ShrinkWrap? The test
> >>>>>>> itself
> >>>>>>> might have only dummy code, just the creation of the
EAR file
> is
> >>>>>>> relevant. This might be helpful to users.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>>
> >>>>>>> Wolfgang
> >>>>>>>
> >>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
> >>>>>>>> The archetype sources should actually be simpler to
maintain, no
> >>>>>>> need to “fix” the imported QS sources... I guess for
most
> releases
> >>>>>>> it would be to simply the effort to sync some
dependency
> management
> >>>>>>> versions for the generated parent pom, e.g. WildFly
BOMs
> version.
> >>>>>>>>
> >>>>>>>> Wrt the html5-mobile archetype, I believe it is
similar to the
> >>>>>>> ones you were looking at, but pointing to an old QS
that was
> >>>>>>> removed
> >>>>>>> at some point.
> >>>>>>>>
> >>>>>>>> —E
> >>>>>>>>
> >>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de
> >>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
> >>>>>>>>>>
> >>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang
Knauf
> >>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Eduardo,
> >>>>>>>>>>>
> >>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo
Martins:
> >>>>>>>>>>>> Hi Wolfgang, the kitchensink QS
truly depends on the QS
> >>>>>>> parent pom (dependency management, plugins, etc.),
which
> means that
> >>>>>>> if we replace it with a “local” parent pom then, for
each
> release,
> >>>>>>> we need to sync manually such parents poms content…
I don’t
> see any
> >>>>>>> issue with using QS parent pom, it seems that those
> archetypes were
> >>>>>>> designed to generate clones of specific quickstarts
with just
> >>>>>>> different Maven GAVs. Have you tried to install the
SNAPSHOT
> >>>>>>> versioned QS parent first (mvn install -N at QS repo
root), or
> >>>>>>> use a
> >>>>>>> tag such as 16.0.0.Final, which parent was released
to Maven,
> >>>>>>> instead of pointing to QS master branch ?
> >>>>>>>>>>>> Honestly I’m not sure this kind of
app archetype is of much
> >>>>>>> interest as it is, mostly due to the app's
complexity,
> probably
> >>>>>>> would be more helpful almost “empty” apps, but if
the idea is
> to
> >>>>>>> have a QS clone tool then perhaps a single generic
archetype
> for
> >>>>>>> that would make more sense. I’m open to QS source
changes
> needed to
> >>>>>>> be friendly with such archetype :-)
> >>>>>>>>>>>> —E
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
> >>>>>>> archetype is not really useful. But based on this
archetype,
> an
> >>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype"
> is
> >>>>>>> generated, which consists of all necessary pom.xml
files and
> some
> >>>>>>> deployment descriptor stubs. And *this* archetype is
the
> reason why
> >>>>>>> I started working on it: it is a good starting point
for a new
> >>>>>>> JavaEE application which already defines all
necessary
> components.
> >>>>>>>>>>>
> >>>>>>>>>>> I am willing to maintain this archetype
for the next few
> >>>>>>> years
> >>>>>>> and trying to release a version for each major
WildFly
> version. As
> >>>>>>> suggested I would add a static root pom.xml to the
archetype
> github
> >>>>>>> project which is independent of the quickstart
files, as they
> are
> >>>>>>> not "standalone". This main pom.xml has to
be updated for each
> >>>>>>> WildFly version, but all the other files still can
be pulled
> from
> >>>>>>> the "KitchensinkEar" quickstart.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Then why get any sources from QS repo,
having a proper
> >>>>>>> do-nothing app project all locally sounds better to
me,
> probably
> >>>>>>> less effort needed on every release too.
> >>>>>>>>>>
> >>>>>>>>>> —E
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So you prefer to create a blank archetype which
has no build
> >>>>>>>>> dependencies, just containing the relevant
pom.xml files and
> >>>>>>> maybe some
> >>>>>>>>> required files (don't know if there are
any)? And this
> >>>>>>> archetype is
> >>>>>>>>> updated by someone (e.g. me) each time a new
major release
> >>>>>>> is done?
> >>>>>>>>>
> >>>>>>>>> Same applies to the other archetype,
> >>>>>>> "wildfly-javaee7-webapp-archetype”.
> >>>>>>>>> The wildfly-archetypes project contains two more
archetypes
> >>>>>>>>> ("wildfly-html5-mobile-archetype",
> >>>>>>> "wildfly-subsystem-archetype"), but I
> >>>>>>>>> did not even take a look at those.
> >>>>>>>>>
> >>>>>>>>> Personally, I prefer the standalone approach,
too. It means
> >>>>>>> more
> >>>>>>> work to
> >>>>>>>>> maintain it, but it is simpler ;-)
> >>>>>>>>>
> >>>>>>>>> Please vote for any of those solutions ;-):
> >>>>>>>>> a) continue pulling from KitchensinkEAR
quickstart ("blank"
> >>>>>>> archetype
> >>>>>>>>> and archetype with a basic project)...
> >>>>>>>>> b) create standalone archetype (only
"blank" archetype).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>>
> >>>>>>>>> Wolfgang
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> wildfly-dev mailing list
> >>>>>> wildfly-dev(a)lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
8:25 p.m.
These build for me.
They're not as out of date as I'd thought either.
On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins(a)redhat.com> wrote:
If you think it’s not a small effort task then certainly agree that’s
not
a blocker, I look at the archetypes same way as the quickstarts, an
aggregation project, so we may take outdated/faulty ones out of build and
release the working+actual ones. We may give it a thought later if it makes
sense effort wise to update or drop the subsystem ones, no worries.
—E
On Fri, 10 May 2019 at 21:46, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> Is that blocking this Eduardo?
>
> If not, updating those is a pretty big task and right now I don't see it
> happening anytime soon.
>
> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins(a)redhat.com>
> wrote:
>
>> Brian, any idea what to do wrt the subsystem archetypes? ATM even build
>> fails and most likely there is someone else better than me to look into
>> that…
>>
>> —E
>>
>> > On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com> wrote:
>> >
>> > Hi Wolfgang, I actually did start reviewing it, but unfortunately had
>> to put it on hold due to unexpected blocker kind of priority tasks/issues
>> needed to be solved asap. If nothing urgent comes I should be able to
>> finish the review the next couple of days.
>> >
>> > —E
>> >
>> >> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> just want to ask for an update ;-)
>> >>
>> >> Best regards
>> >>
>> >> Wolfgang
>> >>
>> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
>> >>> I will review it, soon hopefully.
>> >>>
>> >>> —E
>> >>>
>> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf
<wolfgang.knauf(a)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(a)gmx.de
>> >>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>> >>>>>>>
>> >>>>>>> OK, so there are two votes (mine and
Eduardo's) for "create
>> a blank
>> >>>>>>> archetype from scratch - no demo source
included" and no
>> vote for
>> >>>>>>> "continue using the quickstart"
approach.
>> >>>>>>>
>> >>>>>>> Currently, I struggle with the archetype and
will send a pull
>> >>>>>>> request in
>> >>>>>>> the next few days.
>> >>>>>>>
>> >>>>>>> Any objections against the name
>> >>>>>>> "wildfly-javaee-webapp-ear-archetype"
>> >>>>>>> (which means: a new subdirectory in git)?
>> >>>>>>>
>> >>>>>>> If this is done, the next step would be to
create a
>> >>>>>>> "wildfly-javaee-webapp-archetype". And
then someone could
>> clean
>> >>>>>>> up the
>> >>>>>>> old archetypes.
>> >>>>>>>
>> >>>>>>> I think about adding a small integration test to
the web
>> project
>> >>>>>>> which
>> >>>>>>> shows how to create the @Deployment using
ShrinkWrap? The
>> test
>> >>>>>>> itself
>> >>>>>>> might have only dummy code, just the creation of
the EAR
>> file is
>> >>>>>>> relevant. This might be helpful to users.
>> >>>>>>>
>> >>>>>>> Best regards
>> >>>>>>>
>> >>>>>>> Wolfgang
>> >>>>>>>
>> >>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>> >>>>>>>> The archetype sources should actually be simpler
to maintain, no
>> >>>>>>> need to “fix” the imported QS sources... I guess
for most
>> releases
>> >>>>>>> it would be to simply the effort to sync some
dependency
>> management
>> >>>>>>> versions for the generated parent pom, e.g.
WildFly BOMs
>> version.
>> >>>>>>>>
>> >>>>>>>> Wrt the html5-mobile archetype, I believe it is
similar to the
>> >>>>>>> ones you were looking at, but pointing to an old
QS that was
>> >>>>>>> removed
>> >>>>>>> at some point.
>> >>>>>>>>
>> >>>>>>>> —E
>> >>>>>>>>
>> >>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<
>> wolfgang.knauf(a)gmx.de
>> >>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo
Martins:
>> >>>>>>>>>>
>> >>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang
Knauf
>> >>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>>
>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> Hi Eduardo,
>> >>>>>>>>>>>
>> >>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo
Martins:
>> >>>>>>>>>>>> Hi Wolfgang, the kitchensink QS
truly depends on the QS
>> >>>>>>> parent pom (dependency management, plugins,
etc.), which
>> means that
>> >>>>>>> if we replace it with a “local” parent pom then,
for each
>> release,
>> >>>>>>> we need to sync manually such parents poms
content… I don’t
>> see any
>> >>>>>>> issue with using QS parent pom, it seems that
those
>> archetypes were
>> >>>>>>> designed to generate clones of specific
quickstarts with just
>> >>>>>>> different Maven GAVs. Have you tried to install
the SNAPSHOT
>> >>>>>>> versioned QS parent first (mvn install -N at QS
repo root),
>> or
>> >>>>>>> use a
>> >>>>>>> tag such as 16.0.0.Final, which parent was
released to Maven,
>> >>>>>>> instead of pointing to QS master branch ?
>> >>>>>>>>>>>> Honestly I’m not sure this kind
of app archetype is of much
>> >>>>>>> interest as it is, mostly due to the app's
complexity,
>> probably
>> >>>>>>> would be more helpful almost “empty” apps, but
if the idea
>> is to
>> >>>>>>> have a QS clone tool then perhaps a single
generic archetype
>> for
>> >>>>>>> that would make more sense. I’m open to QS
source changes
>> needed to
>> >>>>>>> be friendly with such archetype :-)
>> >>>>>>>>>>>> —E
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>> >>>>>>> archetype is not really useful. But based on
this archetype,
>> an
>> >>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype"
>> is
>> >>>>>>> generated, which consists of all necessary
pom.xml files and
>> some
>> >>>>>>> deployment descriptor stubs. And *this*
archetype is the
>> reason why
>> >>>>>>> I started working on it: it is a good starting
point for a
>> new
>> >>>>>>> JavaEE application which already defines all
necessary
>> components.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I am willing to maintain this
archetype for the next few
>> >>>>>>> years
>> >>>>>>> and trying to release a version for each major
WildFly
>> version. As
>> >>>>>>> suggested I would add a static root pom.xml to
the archetype
>> github
>> >>>>>>> project which is independent of the quickstart
files, as
>> they are
>> >>>>>>> not "standalone". This main pom.xml
has to be updated for
>> each
>> >>>>>>> WildFly version, but all the other files still
can be pulled
>> from
>> >>>>>>> the "KitchensinkEar" quickstart.
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Then why get any sources from QS repo,
having a proper
>> >>>>>>> do-nothing app project all locally sounds better
to me,
>> probably
>> >>>>>>> less effort needed on every release too.
>> >>>>>>>>>>
>> >>>>>>>>>> —E
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> So you prefer to create a blank archetype
which has no build
>> >>>>>>>>> dependencies, just containing the relevant
pom.xml files and
>> >>>>>>> maybe some
>> >>>>>>>>> required files (don't know if there are
any)? And this
>> >>>>>>> archetype is
>> >>>>>>>>> updated by someone (e.g. me) each time a new
major release
>> >>>>>>> is done?
>> >>>>>>>>>
>> >>>>>>>>> Same applies to the other archetype,
>> >>>>>>> "wildfly-javaee7-webapp-archetype”.
>> >>>>>>>>> The wildfly-archetypes project contains two
more archetypes
>> >>>>>>>>>
("wildfly-html5-mobile-archetype",
>> >>>>>>> "wildfly-subsystem-archetype"), but I
>> >>>>>>>>> did not even take a look at those.
>> >>>>>>>>>
>> >>>>>>>>> Personally, I prefer the standalone
approach, too. It means
>> >>>>>>> more
>> >>>>>>> work to
>> >>>>>>>>> maintain it, but it is simpler ;-)
>> >>>>>>>>>
>> >>>>>>>>> Please vote for any of those solutions ;-):
>> >>>>>>>>> a) continue pulling from KitchensinkEAR
quickstart ("blank"
>> >>>>>>> archetype
>> >>>>>>>>> and archetype with a basic project)...
>> >>>>>>>>> b) create standalone archetype (only
"blank" archetype).
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Best regards
>> >>>>>>>>>
>> >>>>>>>>> Wolfgang
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> wildfly-dev mailing list
>> >>>>>> wildfly-dev(a)lists.jboss.org
>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> wildfly-dev mailing list
>> >>>> wildfly-dev(a)lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>>
>>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
4:09 a.m.
Hmm ok, maybe it just failed build due to some specific like JDK 11, will recheck that.
—E
On 16 May 2019, at 02:25, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
These build for me.
They're not as out of date as I'd thought either.
On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
If you think it’s not a small effort task then certainly agree that’s not a blocker, I
look at the archetypes same way as the quickstarts, an aggregation project, so we may
take outdated/faulty ones out of build and release the working+actual ones. We may give it
a thought later if it makes sense effort wise to update or drop the subsystem ones, no
worries.
—E
On Fri, 10 May 2019 at 21:46, Brian Stansberry <brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
Is that blocking this Eduardo?
If not, updating those is a pretty big task and right now I don't see it happening
anytime soon.
On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
Brian, any idea what to do wrt the subsystem archetypes? ATM even build fails and most
likely there is someone else better than me to look into that…
—E
> On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>
> Hi Wolfgang, I actually did start reviewing it, but unfortunately had to put it on
hold due to unexpected blocker kind of priority tasks/issues needed to be solved asap. If
nothing urgent comes I should be able to finish the review the next couple of days.
>
> —E
>
>> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>
>> Hi,
>>
>> just want to ask for an update ;-)
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
>>> I will review it, soon hopefully.
>>>
>>> —E
>>>
>>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> just want to ask about the state of the pull request and further
steps...
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>> Am 21.03.19 um 12:47 schrieb Wolfgang Knauf:
>>>>> OK, I sent a pull request:
>>>>> https://github.com/wildfly/wildfly-archetypes/pull/3
<https://github.com/wildfly/wildfly-archetypes/pull/3>
>>>>>
>>>>> There already exists a JIRA (created by myself):
>>>>> https://issues.jboss.org/browse/WFLY-9703
<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(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
>>>>>>> <mailto:wolfgang.knauf@gmx.de
<mailto:wolfgang.knauf@gmx.de>>> wrote:
>>>>>>>
>>>>>>> OK, so there are two votes (mine and Eduardo's) for
"create a blank
>>>>>>> archetype from scratch - no demo source included"
and no vote for
>>>>>>> "continue using the quickstart" approach.
>>>>>>>
>>>>>>> Currently, I struggle with the archetype and will send a
pull
>>>>>>> request in
>>>>>>> the next few days.
>>>>>>>
>>>>>>> Any objections against the name
>>>>>>> "wildfly-javaee-webapp-ear-archetype"
>>>>>>> (which means: a new subdirectory in git)?
>>>>>>>
>>>>>>> If this is done, the next step would be to create a
>>>>>>> "wildfly-javaee-webapp-archetype". And then
someone could clean
>>>>>>> up the
>>>>>>> old archetypes.
>>>>>>>
>>>>>>> I think about adding a small integration test to the web
project
>>>>>>> which
>>>>>>> shows how to create the @Deployment using ShrinkWrap?
The test
>>>>>>> itself
>>>>>>> might have only dummy code, just the creation of the EAR
file is
>>>>>>> relevant. This might be helpful to users.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Wolfgang
>>>>>>>
>>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
>>>>>>>> The archetype sources should actually be simpler to
maintain, no
>>>>>>> need to “fix” the imported QS sources... I guess for
most releases
>>>>>>> it would be to simply the effort to sync some dependency
management
>>>>>>> versions for the generated parent pom, e.g. WildFly BOMs
version.
>>>>>>>>
>>>>>>>> Wrt the html5-mobile archetype, I believe it is similar
to the
>>>>>>> ones you were looking at, but pointing to an old QS that
was
>>>>>>> removed
>>>>>>> at some point.
>>>>>>>>
>>>>>>>> —E
>>>>>>>>
>>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
>>>>>>> <mailto:wolfgang.knauf@gmx.de
<mailto:wolfgang.knauf@gmx.de>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>>>>>>>>
>>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de> <mailto:wolfgang.knauf@gmx.de
<mailto:wolfgang.knauf@gmx.de>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Eduardo,
>>>>>>>>>>>
>>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo
Martins:
>>>>>>>>>>>> Hi Wolfgang, the kitchensink QS truly
depends on the QS
>>>>>>> parent pom (dependency management, plugins, etc.), which
means that
>>>>>>> if we replace it with a “local” parent pom then, for
each release,
>>>>>>> we need to sync manually such parents poms content… I
don’t see any
>>>>>>> issue with using QS parent pom, it seems that those
archetypes were
>>>>>>> designed to generate clones of specific quickstarts with
just
>>>>>>> different Maven GAVs. Have you tried to install the
SNAPSHOT
>>>>>>> versioned QS parent first (mvn install -N at QS repo
root), or
>>>>>>> use a
>>>>>>> tag such as 16.0.0.Final, which parent was released to
Maven,
>>>>>>> instead of pointing to QS master branch ?
>>>>>>>>>>>> Honestly I’m not sure this kind of app
archetype is of much
>>>>>>> interest as it is, mostly due to the app's
complexity, probably
>>>>>>> would be more helpful almost “empty” apps, but if the
idea is to
>>>>>>> have a QS clone tool then perhaps a single generic
archetype for
>>>>>>> that would make more sense. I’m open to QS source
changes needed to
>>>>>>> be friendly with such archetype :-)
>>>>>>>>>>>> —E
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>>>>>> archetype is not really useful. But based on this
archetype, an
>>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
>>>>>>> generated, which consists of all necessary pom.xml files
and some
>>>>>>> deployment descriptor stubs. And *this* archetype is the
reason why
>>>>>>> I started working on it: it is a good starting point for
a new
>>>>>>> JavaEE application which already defines all necessary
components.
>>>>>>>>>>>
>>>>>>>>>>> I am willing to maintain this archetype for
the next few
>>>>>>> years
>>>>>>> and trying to release a version for each major WildFly
version. As
>>>>>>> suggested I would add a static root pom.xml to the
archetype github
>>>>>>> project which is independent of the quickstart files, as
they are
>>>>>>> not "standalone". This main pom.xml has to be
updated for each
>>>>>>> WildFly version, but all the other files still can be
pulled from
>>>>>>> the "KitchensinkEar" quickstart.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then why get any sources from QS repo, having a
proper
>>>>>>> do-nothing app project all locally sounds better to me,
probably
>>>>>>> less effort needed on every release too.
>>>>>>>>>>
>>>>>>>>>> —E
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So you prefer to create a blank archetype which has
no build
>>>>>>>>> dependencies, just containing the relevant pom.xml
files and
>>>>>>> maybe some
>>>>>>>>> required files (don't know if there are any)?
And this
>>>>>>> archetype is
>>>>>>>>> updated by someone (e.g. me) each time a new major
release
>>>>>>> is done?
>>>>>>>>>
>>>>>>>>> Same applies to the other archetype,
>>>>>>> "wildfly-javaee7-webapp-archetype”.
>>>>>>>>> The wildfly-archetypes project contains two more
archetypes
>>>>>>>>> ("wildfly-html5-mobile-archetype",
>>>>>>> "wildfly-subsystem-archetype"), but I
>>>>>>>>> did not even take a look at those.
>>>>>>>>>
>>>>>>>>> Personally, I prefer the standalone approach, too.
It means
>>>>>>> more
>>>>>>> work to
>>>>>>>>> maintain it, but it is simpler ;-)
>>>>>>>>>
>>>>>>>>> Please vote for any of those solutions ;-):
>>>>>>>>> a) continue pulling from KitchensinkEAR quickstart
("blank"
>>>>>>> archetype
>>>>>>>>> and archetype with a basic project)...
>>>>>>>>> b) create standalone archetype (only
"blank" archetype).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Wolfgang
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
3:14 p.m.
You mean "wildfly-subsystem-archetype", building with "mvn clean install
-Dmodule=some.module.name"?
They build for me using Java 1.8 and Java 11 (Win7, Maven 3.6.0).
But when built with Java 11, there is a message "command cmd not found"
(translated) - not an error, just a message. But the build seems to finish.
But I don't know this archetype...
Wolfgang
Am 16.05.19 um 11:09 schrieb Eduardo Martins:
Hmm ok, maybe it just failed build due to some specific like JDK 11,
will recheck that.
—E
> On 16 May 2019, at 02:25, Brian Stansberry
> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>>
wrote:
>
> These build for me.
>
> They're not as out of date as I'd thought either.
>
> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins(a)redhat.com
> <mailto:emartins@redhat.com>> wrote:
>
> If you think it’s not a small effort task then certainly agree
> that’s not a blocker, I look at the archetypes same way as the
> quickstarts, an aggregation project, so we may take
> outdated/faulty ones out of build and release the working+actual
> ones. We may give it a thought later if it makes sense effort wise
> to update or drop the subsystem ones, no worries.
>
> —E
>
> On Fri, 10 May 2019 at 21:46, Brian Stansberry
> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>>
> wrote:
>
> Is that blocking this Eduardo?
>
> If not, updating those is a pretty big task and right now I
> don't see it happening anytime soon.
>
> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins
> <emartins(a)redhat.com <mailto:emartins@redhat.com>> wrote:
>
> Brian, any idea what to do wrt the subsystem archetypes?
> ATM even build fails and most likely there is someone else
> better than me to look into that…
>
> —E
>
> > On 7 May 2019, at 09:18, Eduardo Martins
> <emartins(a)redhat.com <mailto:emartins@redhat.com>> wrote:
> >
> > Hi Wolfgang, I actually did start reviewing it, but
> unfortunately had to put it on hold due to unexpected
> blocker kind of priority tasks/issues needed to be solved
> asap. If nothing urgent comes I should be able to finish
> the review the next couple of days.
> >
> > —E
> >
> >> On 6 May 2019, at 20:50, Wolfgang Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>>
wrote:
> >>
> >> Hi,
> >>
> >> just want to ask for an update ;-)
> >>
> >> Best regards
> >>
> >> Wolfgang
> >>
> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
> >>> I will review it, soon hopefully.
> >>>
> >>> —E
> >>>
> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>>
wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> just want to ask about the state of the pull request
> and further steps...
> >>>>
> >>>> Best regards
> >>>>
> >>>> Wolfgang
> >>>>
> >>>> Am 21.03.19 um 12:47 schrieb Wolfgang Knauf:
> >>>>> OK, I sent a pull request:
> >>>>>
https://github.com/wildfly/wildfly-archetypes/pull/3
> >>>>>
> >>>>> There already exists a JIRA (created by myself):
> >>>>> https://issues.jboss.org/browse/WFLY-9703 - but I
> cannot assign it to
> >>>>> myself, probably because I only have the role
"jira
> user".
> >>>>>
> >>>>> Next steps (if the pull request is accepted):
> >>>>> -someone has to release if to maven central. See
the
> release scripts in
> >>>>> the wildfly-archetypes root. This is probably
> something that has to done
> >>>>> by the JBoss team.
> >>>>> -the old archetype can be removed.
> >>>>> -I will create a similar archetype replacement for
> >>>>> "wildfly-javaee7-webapp-archetype"
> >>>>>
> >>>>>
> >>>>> Wolfgang
> >>>>>
> >>>>> Am 19.03.19 um 12:09 schrieb Wolfgang Knauf:
> >>>>>>
> >>>>>> Am 18.03.19 um 22:49 schrieb Eduardo Martins:
> >>>>>>> Webapp-ear sounds a bit weird, perhaps
app-ear and
> app-web instead? :-)
> >>>>>>
> >>>>>>
> >>>>>> What do you think about
> "wildfly-javaee-ear-archetype" and
> >>>>>> "wildfly-javaee-web-archetype"?
> >>>>>>
> >>>>>>
> >>>>>> Attached is a suggested integration test
prototype,
> which shows how to
> >>>>>> create the EAR file using ShrinkWrap. The test
code
> will be placed in
> >>>>>> the web module. The kitchensink quickstart had
the
> tests in the EJB jar,
> >>>>>> but this is the wrong place if you also want to
> test the web layer.
> >>>>>>
> >>>>>> If this is all sound OK, I will start committing
it
> to my git repository
> >>>>>> and sending the pull request.
> >>>>>>
> >>>>>> Best regards
> >>>>>>
> >>>>>> Wolfgang
> >>>>>>
> >>>>>>>
> >>>>>>> On Mon, 18 Mar 2019 at 21:04, Wolfgang
Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
> >>>>>>> <mailto:wolfgang.knauf@gmx.de
> <mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>
> >>>>>>> OK, so there are two votes (mine and
> Eduardo's) for "create a blank
> >>>>>>> archetype from scratch - no demo source
> included" and no vote for
> >>>>>>> "continue using the
quickstart" approach.
> >>>>>>>
> >>>>>>> Currently, I struggle with the archetype
and
> will send a pull
> >>>>>>> request in
> >>>>>>> the next few days.
> >>>>>>>
> >>>>>>> Any objections against the name
> >>>>>>>
"wildfly-javaee-webapp-ear-archetype"
> >>>>>>> (which means: a new subdirectory in
git)?
> >>>>>>>
> >>>>>>> If this is done, the next step would be
to
> create a
> >>>>>>>
"wildfly-javaee-webapp-archetype". And then
> someone could clean
> >>>>>>> up the
> >>>>>>> old archetypes.
> >>>>>>>
> >>>>>>> I think about adding a small integration
test
> to the web project
> >>>>>>> which
> >>>>>>> shows how to create the @Deployment
using
> ShrinkWrap? The test
> >>>>>>> itself
> >>>>>>> might have only dummy code, just the
creation
> of the EAR file is
> >>>>>>> relevant. This might be helpful to
users.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>>
> >>>>>>> Wolfgang
> >>>>>>>
> >>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo
Martins:
> >>>>>>>> The archetype sources should actually be
simpler
> to maintain, no
> >>>>>>> need to “fix” the imported QS sources...
I
> guess for most releases
> >>>>>>> it would be to simply the effort to sync
some
> dependency management
> >>>>>>> versions for the generated parent pom,
e.g.
> WildFly BOMs version.
> >>>>>>>>
> >>>>>>>> Wrt the html5-mobile archetype, I
believe it is
> similar to the
> >>>>>>> ones you were looking at, but pointing
to an
> old QS that was
> >>>>>>> removed
> >>>>>>> at some point.
> >>>>>>>>
> >>>>>>>> —E
> >>>>>>>>
> >>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang
Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
> >>>>>>> <mailto:wolfgang.knauf@gmx.de
> <mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo
Martins:
> >>>>>>>>>>
> >>>>>>>>>>> On 12 Mar 2019, at 19:12,
Wolfgang Knauf
> >>>>>>> <wolfgang.knauf(a)gmx.de
> <mailto:wolfgang.knauf@gmx.de>
> <mailto:wolfgang.knauf@gmx.de
> <mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Eduardo,
> >>>>>>>>>>>
> >>>>>>>>>>> Am 12.03.19 um 08:58 schrieb
Eduardo Martins:
> >>>>>>>>>>>> Hi Wolfgang, the
kitchensink QS truly depends
> on the QS
> >>>>>>> parent pom (dependency management,
plugins,
> etc.), which means that
> >>>>>>> if we replace it with a “local” parent
pom
> then, for each release,
> >>>>>>> we need to sync manually such parents
poms
> content… I don’t see any
> >>>>>>> issue with using QS parent pom, it seems
that
> those archetypes were
> >>>>>>> designed to generate clones of specific
> quickstarts with just
> >>>>>>> different Maven GAVs. Have you tried to
> install the SNAPSHOT
> >>>>>>> versioned QS parent first (mvn install
-N at
> QS repo root), or
> >>>>>>> use a
> >>>>>>> tag such as 16.0.0.Final, which parent
was
> released to Maven,
> >>>>>>> instead of pointing to QS master branch
?
> >>>>>>>>>>>> Honestly I’m not sure
this kind of app
> archetype is of much
> >>>>>>> interest as it is, mostly due to the
app's
> complexity, probably
> >>>>>>> would be more helpful almost “empty”
apps, but
> if the idea is to
> >>>>>>> have a QS clone tool then perhaps a
single
> generic archetype for
> >>>>>>> that would make more sense. I’m open to
QS
> source changes needed to
> >>>>>>> be friendly with such archetype :-)
> >>>>>>>>>>>> —E
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I agree that the
> "wildfly-javaee7-webapp-ear-archetype"
> >>>>>>> archetype is not really useful. But
based on
> this archetype, an
> >>>>>>> empty archetype
> "wildfly-javaee7-webapp-ear-blank-archetype" is
> >>>>>>> generated, which consists of all
necessary
> pom.xml files and some
> >>>>>>> deployment descriptor stubs. And *this*
> archetype is the reason why
> >>>>>>> I started working on it: it is a good
starting
> point for a new
> >>>>>>> JavaEE application which already defines
all
> necessary components.
> >>>>>>>>>>>
> >>>>>>>>>>> I am willing to maintain
this archetype for
> the next few
> >>>>>>> years
> >>>>>>> and trying to release a version for each
major
> WildFly version. As
> >>>>>>> suggested I would add a static root
pom.xml to
> the archetype github
> >>>>>>> project which is independent of the
quickstart
> files, as they are
> >>>>>>> not "standalone". This main
pom.xml has to be
> updated for each
> >>>>>>> WildFly version, but all the other files
still
> can be pulled from
> >>>>>>> the "KitchensinkEar"
quickstart.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Then why get any sources from QS
repo, having a
> proper
> >>>>>>> do-nothing app project all locally
sounds
> better to me, probably
> >>>>>>> less effort needed on every release
too.
> >>>>>>>>>>
> >>>>>>>>>> —E
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So you prefer to create a blank
archetype which
> has no build
> >>>>>>>>> dependencies, just containing the
relevant
> pom.xml files and
> >>>>>>> maybe some
> >>>>>>>>> required files (don't know if
there are any)?
> And this
> >>>>>>> archetype is
> >>>>>>>>> updated by someone (e.g. me) each
time a new
> major release
> >>>>>>> is done?
> >>>>>>>>>
> >>>>>>>>> Same applies to the other
archetype,
> >>>>>>>
"wildfly-javaee7-webapp-archetype”.
> >>>>>>>>> The wildfly-archetypes project
contains two more
> archetypes
> >>>>>>>>>
("wildfly-html5-mobile-archetype",
> >>>>>>>
"wildfly-subsystem-archetype"), but I
> >>>>>>>>> did not even take a look at those.
> >>>>>>>>>
> >>>>>>>>> Personally, I prefer the standalone
approach,
> too. It means
> >>>>>>> more
> >>>>>>> work to
> >>>>>>>>> maintain it, but it is simpler ;-)
> >>>>>>>>>
> >>>>>>>>> Please vote for any of those
solutions ;-):
> >>>>>>>>> a) continue pulling from
KitchensinkEAR
> quickstart ("blank"
> >>>>>>> archetype
> >>>>>>>>> and archetype with a basic
project)...
> >>>>>>>>> b) create standalone archetype (only
"blank"
> archetype).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>>
> >>>>>>>>> Wolfgang
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> wildfly-dev mailing list
> >>>>>> wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> >>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:52 a.m.
Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is out I will also deploy
the archetype, thanks a lot for your contribution! Yet now I have to ask, do you plan to
submit similar for the other old javaee archetype? :-)
Brian: yep it was just the JDK, I will deploy these too (no planned updates in such code
tho)
—E
On 16 May 2019, at 10:09, Eduardo Martins <emartins(a)redhat.com>
wrote:
Hmm ok, maybe it just failed build due to some specific like JDK 11, will recheck that.
—E
> On 16 May 2019, at 02:25, Brian Stansberry <brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
>
> These build for me.
>
> They're not as out of date as I'd thought either.
>
> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
> If you think it’s not a small effort task then certainly agree that’s not a blocker,
I look at the archetypes same way as the quickstarts, an aggregation project, so we may
take outdated/faulty ones out of build and release the working+actual ones. We may give it
a thought later if it makes sense effort wise to update or drop the subsystem ones, no
worries.
>
> —E
>
> On Fri, 10 May 2019 at 21:46, Brian Stansberry <brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
> Is that blocking this Eduardo?
>
> If not, updating those is a pretty big task and right now I don't see it
happening anytime soon.
>
> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
> Brian, any idea what to do wrt the subsystem archetypes? ATM even build fails and
most likely there is someone else better than me to look into that…
>
> —E
>
> > On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
> >
> > Hi Wolfgang, I actually did start reviewing it, but unfortunately had to put it
on hold due to unexpected blocker kind of priority tasks/issues needed to be solved asap.
If nothing urgent comes I should be able to finish the review the next couple of days.
> >
> > —E
> >
> >> On 6 May 2019, at 20:50, Wolfgang Knauf <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
> >>
> >> Hi,
> >>
> >> just want to ask for an update ;-)
> >>
> >> Best regards
> >>
> >> Wolfgang
> >>
> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
> >>> I will review it, soon hopefully.
> >>>
> >>> —E
> >>>
> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> just want to ask about the state of the pull request and further
steps...
> >>>>
> >>>> Best regards
> >>>>
> >>>> Wolfgang
> >>>>
> >>>> Am 21.03.19 um 12:47 schrieb Wolfgang Knauf:
> >>>>> OK, I sent a pull request:
> >>>>> https://github.com/wildfly/wildfly-archetypes/pull/3
<https://github.com/wildfly/wildfly-archetypes/pull/3>
> >>>>>
> >>>>> There already exists a JIRA (created by myself):
> >>>>> https://issues.jboss.org/browse/WFLY-9703
<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(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
> >>>>>>> <mailto:wolfgang.knauf@gmx.de
<mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>
> >>>>>>> OK, so there are two votes (mine and Eduardo's)
for "create a blank
> >>>>>>> archetype from scratch - no demo source
included" and no vote for
> >>>>>>> "continue using the quickstart" approach.
> >>>>>>>
> >>>>>>> Currently, I struggle with the archetype and will
send a pull
> >>>>>>> request in
> >>>>>>> the next few days.
> >>>>>>>
> >>>>>>> Any objections against the name
> >>>>>>> "wildfly-javaee-webapp-ear-archetype"
> >>>>>>> (which means: a new subdirectory in git)?
> >>>>>>>
> >>>>>>> If this is done, the next step would be to create a
> >>>>>>> "wildfly-javaee-webapp-archetype". And
then someone could clean
> >>>>>>> up the
> >>>>>>> old archetypes.
> >>>>>>>
> >>>>>>> I think about adding a small integration test to the
web project
> >>>>>>> which
> >>>>>>> shows how to create the @Deployment using
ShrinkWrap? The test
> >>>>>>> itself
> >>>>>>> might have only dummy code, just the creation of the
EAR file is
> >>>>>>> relevant. This might be helpful to users.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>>
> >>>>>>> Wolfgang
> >>>>>>>
> >>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo Martins:
> >>>>>>>> The archetype sources should actually be simpler to
maintain, no
> >>>>>>> need to “fix” the imported QS sources... I guess for
most releases
> >>>>>>> it would be to simply the effort to sync some
dependency management
> >>>>>>> versions for the generated parent pom, e.g. WildFly
BOMs version.
> >>>>>>>>
> >>>>>>>> Wrt the html5-mobile archetype, I believe it is
similar to the
> >>>>>>> ones you were looking at, but pointing to an old QS
that was
> >>>>>>> removed
> >>>>>>> at some point.
> >>>>>>>>
> >>>>>>>> —E
> >>>>>>>>
> >>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
> >>>>>>> <mailto:wolfgang.knauf@gmx.de
<mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
> >>>>>>>>>>
> >>>>>>>>>>> On 12 Mar 2019, at 19:12, Wolfgang
Knauf
> >>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de> <mailto:wolfgang.knauf@gmx.de
<mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Eduardo,
> >>>>>>>>>>>
> >>>>>>>>>>> Am 12.03.19 um 08:58 schrieb Eduardo
Martins:
> >>>>>>>>>>>> Hi Wolfgang, the kitchensink QS
truly depends on the QS
> >>>>>>> parent pom (dependency management, plugins, etc.),
which means that
> >>>>>>> if we replace it with a “local” parent pom then, for
each release,
> >>>>>>> we need to sync manually such parents poms content…
I don’t see any
> >>>>>>> issue with using QS parent pom, it seems that those
archetypes were
> >>>>>>> designed to generate clones of specific quickstarts
with just
> >>>>>>> different Maven GAVs. Have you tried to install the
SNAPSHOT
> >>>>>>> versioned QS parent first (mvn install -N at QS repo
root), or
> >>>>>>> use a
> >>>>>>> tag such as 16.0.0.Final, which parent was released
to Maven,
> >>>>>>> instead of pointing to QS master branch ?
> >>>>>>>>>>>> Honestly I’m not sure this kind of
app archetype is of much
> >>>>>>> interest as it is, mostly due to the app's
complexity, probably
> >>>>>>> would be more helpful almost “empty” apps, but if
the idea is to
> >>>>>>> have a QS clone tool then perhaps a single generic
archetype for
> >>>>>>> that would make more sense. I’m open to QS source
changes needed to
> >>>>>>> be friendly with such archetype :-)
> >>>>>>>>>>>> —E
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
> >>>>>>> archetype is not really useful. But based on this
archetype, an
> >>>>>>> empty archetype
"wildfly-javaee7-webapp-ear-blank-archetype" is
> >>>>>>> generated, which consists of all necessary pom.xml
files and some
> >>>>>>> deployment descriptor stubs. And *this* archetype is
the reason why
> >>>>>>> I started working on it: it is a good starting point
for a new
> >>>>>>> JavaEE application which already defines all
necessary components.
> >>>>>>>>>>>
> >>>>>>>>>>> I am willing to maintain this archetype
for the next few
> >>>>>>> years
> >>>>>>> and trying to release a version for each major
WildFly version. As
> >>>>>>> suggested I would add a static root pom.xml to the
archetype github
> >>>>>>> project which is independent of the quickstart
files, as they are
> >>>>>>> not "standalone". This main pom.xml has to
be updated for each
> >>>>>>> WildFly version, but all the other files still can
be pulled from
> >>>>>>> the "KitchensinkEar" quickstart.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Then why get any sources from QS repo,
having a proper
> >>>>>>> do-nothing app project all locally sounds better to
me, probably
> >>>>>>> less effort needed on every release too.
> >>>>>>>>>>
> >>>>>>>>>> —E
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So you prefer to create a blank archetype which
has no build
> >>>>>>>>> dependencies, just containing the relevant
pom.xml files and
> >>>>>>> maybe some
> >>>>>>>>> required files (don't know if there are
any)? And this
> >>>>>>> archetype is
> >>>>>>>>> updated by someone (e.g. me) each time a new
major release
> >>>>>>> is done?
> >>>>>>>>>
> >>>>>>>>> Same applies to the other archetype,
> >>>>>>> "wildfly-javaee7-webapp-archetype”.
> >>>>>>>>> The wildfly-archetypes project contains two more
archetypes
> >>>>>>>>> ("wildfly-html5-mobile-archetype",
> >>>>>>> "wildfly-subsystem-archetype"), but I
> >>>>>>>>> did not even take a look at those.
> >>>>>>>>>
> >>>>>>>>> Personally, I prefer the standalone approach,
too. It means
> >>>>>>> more
> >>>>>>> work to
> >>>>>>>>> maintain it, but it is simpler ;-)
> >>>>>>>>>
> >>>>>>>>> Please vote for any of those solutions ;-):
> >>>>>>>>> a) continue pulling from KitchensinkEAR
quickstart ("blank"
> >>>>>>> archetype
> >>>>>>>>> and archetype with a basic project)...
> >>>>>>>>> b) create standalone archetype (only
"blank" archetype).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>>
> >>>>>>>>> Wolfgang
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> wildfly-dev mailing list
> >>>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >>>>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
10:05 a.m.
Excellent! Thank you so much Wolfgang!
On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins(a)redhat.com> wrote:
Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is
out I
will also deploy the archetype, thanks a lot for your contribution! Yet now
I have to ask, do you plan to submit similar for the other old javaee
archetype? :-)
Brian: yep it was just the JDK, I will deploy these too (no planned
updates in such code tho)
—E
On 16 May 2019, at 10:09, Eduardo Martins <emartins(a)redhat.com> wrote:
Hmm ok, maybe it just failed build due to some specific like JDK 11, will
recheck that.
—E
On 16 May 2019, at 02:25, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
These build for me.
They're not as out of date as I'd thought either.
On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins(a)redhat.com>
wrote:
> If you think it’s not a small effort task then certainly agree that’s not
> a blocker, I look at the archetypes same way as the quickstarts, an
> aggregation project, so we may take outdated/faulty ones out of build and
> release the working+actual ones. We may give it a thought later if it makes
> sense effort wise to update or drop the subsystem ones, no worries.
>
> —E
>
> On Fri, 10 May 2019 at 21:46, Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> Is that blocking this Eduardo?
>>
>> If not, updating those is a pretty big task and right now I don't see it
>> happening anytime soon.
>>
>> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins <emartins(a)redhat.com>
>> wrote:
>>
>>> Brian, any idea what to do wrt the subsystem archetypes? ATM even build
>>> fails and most likely there is someone else better than me to look into
>>> that…
>>>
>>> —E
>>>
>>> > On 7 May 2019, at 09:18, Eduardo Martins <emartins(a)redhat.com>
wrote:
>>> >
>>> > Hi Wolfgang, I actually did start reviewing it, but unfortunately had
>>> to put it on hold due to unexpected blocker kind of priority tasks/issues
>>> needed to be solved asap. If nothing urgent comes I should be able to
>>> finish the review the next couple of days.
>>> >
>>> > —E
>>> >
>>> >> On 6 May 2019, at 20:50, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de>
>>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> just want to ask for an update ;-)
>>> >>
>>> >> Best regards
>>> >>
>>> >> Wolfgang
>>> >>
>>> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
>>> >>> I will review it, soon hopefully.
>>> >>>
>>> >>> —E
>>> >>>
>>> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf
<wolfgang.knauf(a)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(a)gmx.de
>>> >>>>>>> <mailto:wolfgang.knauf@gmx.de>> wrote:
>>> >>>>>>>
>>> >>>>>>> OK, so there are two votes (mine and
Eduardo's) for "create
>>> a blank
>>> >>>>>>> archetype from scratch - no demo source
included" and no
>>> vote for
>>> >>>>>>> "continue using the quickstart"
approach.
>>> >>>>>>>
>>> >>>>>>> Currently, I struggle with the archetype and
will send a
>>> pull
>>> >>>>>>> request in
>>> >>>>>>> the next few days.
>>> >>>>>>>
>>> >>>>>>> Any objections against the name
>>> >>>>>>> "wildfly-javaee-webapp-ear-archetype"
>>> >>>>>>> (which means: a new subdirectory in git)?
>>> >>>>>>>
>>> >>>>>>> If this is done, the next step would be to
create a
>>> >>>>>>> "wildfly-javaee-webapp-archetype".
And then someone could
>>> clean
>>> >>>>>>> up the
>>> >>>>>>> old archetypes.
>>> >>>>>>>
>>> >>>>>>> I think about adding a small integration
test to the web
>>> project
>>> >>>>>>> which
>>> >>>>>>> shows how to create the @Deployment using
ShrinkWrap? The
>>> test
>>> >>>>>>> itself
>>> >>>>>>> might have only dummy code, just the
creation of the EAR
>>> file is
>>> >>>>>>> relevant. This might be helpful to users.
>>> >>>>>>>
>>> >>>>>>> Best regards
>>> >>>>>>>
>>> >>>>>>> Wolfgang
>>> >>>>>>>
>>> >>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo
Martins:
>>> >>>>>>>> The archetype sources should actually be
simpler to maintain,
>>> no
>>> >>>>>>> need to “fix” the imported QS sources... I
guess for most
>>> releases
>>> >>>>>>> it would be to simply the effort to sync
some dependency
>>> management
>>> >>>>>>> versions for the generated parent pom, e.g.
WildFly BOMs
>>> version.
>>> >>>>>>>>
>>> >>>>>>>> Wrt the html5-mobile archetype, I believe it
is similar to the
>>> >>>>>>> ones you were looking at, but pointing to an
old QS that was
>>> >>>>>>> removed
>>> >>>>>>> at some point.
>>> >>>>>>>>
>>> >>>>>>>> —E
>>> >>>>>>>>
>>> >>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang Knauf
<
>>> wolfgang.knauf(a)gmx.de
>>> >>>>>>> <mailto:wolfgang.knauf@gmx.de>>
wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo
Martins:
>>> >>>>>>>>>>
>>> >>>>>>>>>>> On 12 Mar 2019, at 19:12,
Wolfgang Knauf
>>> >>>>>>> <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>>
>>> wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Hi Eduardo,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Am 12.03.19 um 08:58 schrieb
Eduardo Martins:
>>> >>>>>>>>>>>> Hi Wolfgang, the kitchensink
QS truly depends on the QS
>>> >>>>>>> parent pom (dependency management, plugins,
etc.), which
>>> means that
>>> >>>>>>> if we replace it with a “local” parent pom
then, for each
>>> release,
>>> >>>>>>> we need to sync manually such parents poms
content… I don’t
>>> see any
>>> >>>>>>> issue with using QS parent pom, it seems
that those
>>> archetypes were
>>> >>>>>>> designed to generate clones of specific
quickstarts with
>>> just
>>> >>>>>>> different Maven GAVs. Have you tried to
install the SNAPSHOT
>>> >>>>>>> versioned QS parent first (mvn install -N at
QS repo root),
>>> or
>>> >>>>>>> use a
>>> >>>>>>> tag such as 16.0.0.Final, which parent was
released to
>>> Maven,
>>> >>>>>>> instead of pointing to QS master branch ?
>>> >>>>>>>>>>>> Honestly I’m not sure this
kind of app archetype is of much
>>> >>>>>>> interest as it is, mostly due to the
app's complexity,
>>> probably
>>> >>>>>>> would be more helpful almost “empty” apps,
but if the idea
>>> is to
>>> >>>>>>> have a QS clone tool then perhaps a single
generic
>>> archetype for
>>> >>>>>>> that would make more sense. I’m open to QS
source changes
>>> needed to
>>> >>>>>>> be friendly with such archetype :-)
>>> >>>>>>>>>>>> —E
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I agree that the
"wildfly-javaee7-webapp-ear-archetype"
>>> >>>>>>> archetype is not really useful. But based on
this
>>> archetype, an
>>> >>>>>>> empty archetype
>>> "wildfly-javaee7-webapp-ear-blank-archetype" is
>>> >>>>>>> generated, which consists of all necessary
pom.xml files
>>> and some
>>> >>>>>>> deployment descriptor stubs. And *this*
archetype is the
>>> reason why
>>> >>>>>>> I started working on it: it is a good
starting point for a
>>> new
>>> >>>>>>> JavaEE application which already defines all
necessary
>>> components.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I am willing to maintain this
archetype for the next few
>>> >>>>>>> years
>>> >>>>>>> and trying to release a version for each
major WildFly
>>> version. As
>>> >>>>>>> suggested I would add a static root pom.xml
to the
>>> archetype github
>>> >>>>>>> project which is independent of the
quickstart files, as
>>> they are
>>> >>>>>>> not "standalone". This main
pom.xml has to be updated for
>>> each
>>> >>>>>>> WildFly version, but all the other files
still can be
>>> pulled from
>>> >>>>>>> the "KitchensinkEar" quickstart.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> Then why get any sources from QS
repo, having a proper
>>> >>>>>>> do-nothing app project all locally sounds
better to me,
>>> probably
>>> >>>>>>> less effort needed on every release too.
>>> >>>>>>>>>>
>>> >>>>>>>>>> —E
>>> >>>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> So you prefer to create a blank
archetype which has no build
>>> >>>>>>>>> dependencies, just containing the
relevant pom.xml files and
>>> >>>>>>> maybe some
>>> >>>>>>>>> required files (don't know if there
are any)? And this
>>> >>>>>>> archetype is
>>> >>>>>>>>> updated by someone (e.g. me) each time a
new major release
>>> >>>>>>> is done?
>>> >>>>>>>>>
>>> >>>>>>>>> Same applies to the other archetype,
>>> >>>>>>> "wildfly-javaee7-webapp-archetype”.
>>> >>>>>>>>> The wildfly-archetypes project contains
two more archetypes
>>> >>>>>>>>>
("wildfly-html5-mobile-archetype",
>>> >>>>>>> "wildfly-subsystem-archetype"),
but I
>>> >>>>>>>>> did not even take a look at those.
>>> >>>>>>>>>
>>> >>>>>>>>> Personally, I prefer the standalone
approach, too. It means
>>> >>>>>>> more
>>> >>>>>>> work to
>>> >>>>>>>>> maintain it, but it is simpler ;-)
>>> >>>>>>>>>
>>> >>>>>>>>> Please vote for any of those solutions
;-):
>>> >>>>>>>>> a) continue pulling from KitchensinkEAR
quickstart ("blank"
>>> >>>>>>> archetype
>>> >>>>>>>>> and archetype with a basic project)...
>>> >>>>>>>>> b) create standalone archetype (only
"blank" archetype).
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> Best regards
>>> >>>>>>>>>
>>> >>>>>>>>> Wolfgang
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> wildfly-dev mailing list
>>> >>>>>> wildfly-dev(a)lists.jboss.org
>>> >>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>> wildfly-dev(a)lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> wildfly-dev mailing list
>>> >> wildfly-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >
>>>
>>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
2:36 p.m.
Thanks for the deploy, Eduardo!
If you consider it reasonable I will create an archetype for "web app
only", similar to the old "wildfly-javaee7-webapp-archetype".
But I will probably need a few weeks...
What happens to the old archetype
"wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as it does
not build anyway. It might be relevant only for research.
Best regards
Wolfgang
Am 03.06.19 um 17:05 schrieb Brian Stansberry:
Excellent! Thank you so much Wolfgang!
On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is
out I will also deploy the archetype, thanks a lot for your
contribution! Yet now I have to ask, do you plan to submit similar
for the other old javaee archetype? :-)
Brian: yep it was just the JDK, I will deploy these too (no planned
updates in such code tho)
—E
> On 16 May 2019, at 10:09, Eduardo Martins <emartins(a)redhat.com
> <mailto:emartins@redhat.com>> wrote:
>
> Hmm ok, maybe it just failed build due to some specific like JDK
> 11, will recheck that.
>
> —E
>
>> On 16 May 2019, at 02:25, Brian Stansberry
>> <brian.stansberry(a)redhat.com
>> <mailto:brian.stansberry@redhat.com>> wrote:
>>
>> These build for me.
>>
>> They're not as out of date as I'd thought either.
>>
>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>> <emartins(a)redhat.com <mailto:emartins@redhat.com>> wrote:
>>
>> If you think it’s not a small effort task then certainly
>> agree that’s not a blocker, I look at the archetypes same way
>> as the quickstarts, an aggregation project, so we may take
>> outdated/faulty ones out of build and release the
>> working+actual ones. We may give it a thought later if it
>> makes sense effort wise to update or drop the subsystem ones,
>> no worries.
>>
>> —E
>>
2:42 p.m.
Hi Eduardo,
while building a "wildfly-javaee-webapp-archetype", I think I found a
small WildFly issue: you remember that you pointed me to the fact that
"beans.xml" is optional?
But when creating a blank project from my new web archetype (which
defines a "faces-config.xml", but no "beans.xml"), the attached error
is
in the WildFly console. But it seems the app is deployed anyway.
The error disappears if I add e.g. an annotated EJB, or if I add a
"beans.xml".
Do you think this is a WildFly bug? Or should I add a default
"beans.xml" just to avoid this error?
I did not test it with a blank project from the EAR archetype - will do
this in the next few days.
Best regards
Wolfgang
Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
Thanks for the deploy, Eduardo!
If you consider it reasonable I will create an archetype for "web app
only", similar to the old "wildfly-javaee7-webapp-archetype".
But I will probably need a few weeks...
What happens to the old archetype
"wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as it does
not build anyway. It might be relevant only for research.
Best regards
Wolfgang
Am 03.06.19 um 17:05 schrieb Brian Stansberry:
> Excellent! Thank you so much Wolfgang!
>
> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins(a)redhat.com
> <mailto:emartins@redhat.com>> wrote:
>
> Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is
> out I will also deploy the archetype, thanks a lot for your
> contribution! Yet now I have to ask, do you plan to submit similar
> for the other old javaee archetype? :-)
>
> Brian: yep it was just the JDK, I will deploy these too (no planned
> updates in such code tho)
>
> —E
>
>> On 16 May 2019, at 10:09, Eduardo Martins <emartins(a)redhat.com
>> <mailto:emartins@redhat.com>> wrote:
>>
>> Hmm ok, maybe it just failed build due to some specific like JDK
>> 11, will recheck that.
>>
>> —E
>>
>>> On 16 May 2019, at 02:25, Brian Stansberry
>>> <brian.stansberry(a)redhat.com
>>> <mailto:brian.stansberry@redhat.com>> wrote:
>>>
>>> These build for me.
>>>
>>> They're not as out of date as I'd thought either.
>>>
>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>> <emartins(a)redhat.com <mailto:emartins@redhat.com>> wrote:
>>>
>>> If you think it’s not a small effort task then certainly
>>> agree that’s not a blocker, I look at the archetypes same way
>>> as the quickstarts, an aggregation project, so we may take
>>> outdated/faulty ones out of build and release the
>>> working+actual ones. We may give it a thought later if it
>>> makes sense effort wise to update or drop the subsystem ones,
>>> no worries.
>>>
>>> —E
>>>
2:57 p.m.
Hi to all,
just wanted to ask for an update: do you think that the error message is
acceptable and I should create the archetype without "beans.xml" anyway
(and add an info to the readme.txt file)?
Or should I add a default "beans.xml" to the archetype to avoid it?
Or is it worth a JIRA?
Best regards
Wolfgang
Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
Hi Eduardo,
while building a "wildfly-javaee-webapp-archetype", I think I found a
small WildFly issue: you remember that you pointed me to the fact that
"beans.xml" is optional?
But when creating a blank project from my new web archetype (which
defines a "faces-config.xml", but no "beans.xml"), the attached error
is
in the WildFly console. But it seems the app is deployed anyway.
The error disappears if I add e.g. an annotated EJB, or if I add a
"beans.xml".
Do you think this is a WildFly bug? Or should I add a default
"beans.xml" just to avoid this error?
I did not test it with a blank project from the EAR archetype - will do
this in the next few days.
Best regards
Wolfgang
Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
> Thanks for the deploy, Eduardo!
>
> If you consider it reasonable I will create an archetype for "web app
> only", similar to the old "wildfly-javaee7-webapp-archetype".
> But I will probably need a few weeks...
>
> What happens to the old archetype
> "wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as it
> does not build anyway. It might be relevant only for research.
>
> Best regards
>
> Wolfgang
>
>
>
> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>> Excellent! Thank you so much Wolfgang!
>>
>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins(a)redhat.com
>> <mailto:emartins@redhat.com>> wrote:
>>
>> Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is
>> out I will also deploy the archetype, thanks a lot for your
>> contribution! Yet now I have to ask, do you plan to submit similar
>> for the other old javaee archetype? :-)
>>
>> Brian: yep it was just the JDK, I will deploy these too (no planned
>> updates in such code tho)
>>
>> —E
>>
>>> On 16 May 2019, at 10:09, Eduardo Martins <emartins(a)redhat.com
>>> <mailto:emartins@redhat.com>> wrote:
>>>
>>> Hmm ok, maybe it just failed build due to some specific like JDK
>>> 11, will recheck that.
>>>
>>> —E
>>>
>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>> <brian.stansberry(a)redhat.com
>>>> <mailto:brian.stansberry@redhat.com>> wrote:
>>>>
>>>> These build for me.
>>>>
>>>> They're not as out of date as I'd thought either.
>>>>
>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>>> <emartins(a)redhat.com <mailto:emartins@redhat.com>>
wrote:
>>>>
>>>> If you think it’s not a small effort task then certainly
>>>> agree that’s not a blocker, I look at the archetypes same way
>>>> as the quickstarts, an aggregation project, so we may take
>>>> outdated/faulty ones out of build and release the
>>>> working+actual ones. We may give it a thought later if it
>>>> makes sense effort wise to update or drop the subsystem ones,
>>>> no worries.
>>>>
>>>> —E
>>>>
3:37 p.m.
Hi Wolfgang, when reviewing it seemed to me that in the *ear* archetype the beans.xml was
not needed. I can’t tell if that’s the case for this new archetype without you submitting
it for review, but if it fails to deploy without it… ;-)
—E
On 12 Jun 2019, at 20:57, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
Hi to all,
just wanted to ask for an update: do you think that the error message is
acceptable and I should create the archetype without "beans.xml" anyway
(and add an info to the readme.txt file)?
Or should I add a default "beans.xml" to the archetype to avoid it?
Or is it worth a JIRA?
Best regards
Wolfgang
Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
> Hi Eduardo,
>
> while building a "wildfly-javaee-webapp-archetype", I think I found a
> small WildFly issue: you remember that you pointed me to the fact that
> "beans.xml" is optional?
> But when creating a blank project from my new web archetype (which
> defines a "faces-config.xml", but no "beans.xml"), the attached
error is
> in the WildFly console. But it seems the app is deployed anyway.
>
> The error disappears if I add e.g. an annotated EJB, or if I add a
> "beans.xml".
>
> Do you think this is a WildFly bug? Or should I add a default
> "beans.xml" just to avoid this error?
>
> I did not test it with a blank project from the EAR archetype - will do
> this in the next few days.
>
> Best regards
>
> Wolfgang
>
>
> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>> Thanks for the deploy, Eduardo!
>>
>> If you consider it reasonable I will create an archetype for "web app
>> only", similar to the old "wildfly-javaee7-webapp-archetype".
>> But I will probably need a few weeks...
>>
>> What happens to the old archetype
>> "wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as it
>> does not build anyway. It might be relevant only for research.
>>
>> Best regards
>>
>> Wolfgang
>>
>>
>>
>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>> Excellent! Thank you so much Wolfgang!
>>>
>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins(a)redhat.com
>>> <mailto:emartins@redhat.com>> wrote:
>>>
>>> Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is
>>> out I will also deploy the archetype, thanks a lot for your
>>> contribution! Yet now I have to ask, do you plan to submit similar
>>> for the other old javaee archetype? :-)
>>>
>>> Brian: yep it was just the JDK, I will deploy these too (no planned
>>> updates in such code tho)
>>>
>>> —E
>>>
>>>> On 16 May 2019, at 10:09, Eduardo Martins <emartins(a)redhat.com
>>>> <mailto:emartins@redhat.com>> wrote:
>>>>
>>>> Hmm ok, maybe it just failed build due to some specific like JDK
>>>> 11, will recheck that.
>>>>
>>>> —E
>>>>
>>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>>> <brian.stansberry(a)redhat.com
>>>>> <mailto:brian.stansberry@redhat.com>> wrote:
>>>>>
>>>>> These build for me.
>>>>>
>>>>> They're not as out of date as I'd thought either.
>>>>>
>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>>>> <emartins(a)redhat.com <mailto:emartins@redhat.com>>
wrote:
>>>>>
>>>>> If you think it’s not a small effort task then certainly
>>>>> agree that’s not a blocker, I look at the archetypes same
way
>>>>> as the quickstarts, an aggregation project, so we may take
>>>>> outdated/faulty ones out of build and release the
>>>>> working+actual ones. We may give it a thought later if it
>>>>> makes sense effort wise to update or drop the subsystem
ones,
>>>>> no worries.
>>>>>
>>>>> —E
>>>>>
7:12 a.m.
Hi Eduardo,
i sent a pull request for this new archetype, without beans.xml.
Depending on your findings, we can add it afterwards if necessary.
But as far as I understand it, this file is optional now
(https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
- so this could be considered a bug...
Best regards
Wolfgang
Am 12.06.19 um 22:37 schrieb Eduardo Martins:
Hi Wolfgang, when reviewing it seemed to me that in the *ear*
archetype the beans.xml was not needed. I can’t tell if that’s the case for this new
archetype without you submitting it for review, but if it fails to deploy without it… ;-)
—E
> On 12 Jun 2019, at 20:57, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>
> Hi to all,
>
> just wanted to ask for an update: do you think that the error message is
> acceptable and I should create the archetype without "beans.xml" anyway
> (and add an info to the readme.txt file)?
> Or should I add a default "beans.xml" to the archetype to avoid it?
> Or is it worth a JIRA?
>
> Best regards
>
> Wolfgang
>
> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>> Hi Eduardo,
>>
>> while building a "wildfly-javaee-webapp-archetype", I think I found a
>> small WildFly issue: you remember that you pointed me to the fact that
>> "beans.xml" is optional?
>> But when creating a blank project from my new web archetype (which
>> defines a "faces-config.xml", but no "beans.xml"), the
attached error is
>> in the WildFly console. But it seems the app is deployed anyway.
>>
>> The error disappears if I add e.g. an annotated EJB, or if I add a
>> "beans.xml".
>>
>> Do you think this is a WildFly bug? Or should I add a default
>> "beans.xml" just to avoid this error?
>>
>> I did not test it with a blank project from the EAR archetype - will do
>> this in the next few days.
>>
>> Best regards
>>
>> Wolfgang
>>
>>
>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>> Thanks for the deploy, Eduardo!
>>>
>>> If you consider it reasonable I will create an archetype for "web app
>>> only", similar to the old "wildfly-javaee7-webapp-archetype".
>>> But I will probably need a few weeks...
>>>
>>> What happens to the old archetype
>>> "wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as it
>>> does not build anyway. It might be relevant only for research.
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>>
>>>
>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>> Excellent! Thank you so much Wolfgang!
>>>>
>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <emartins(a)redhat.com
>>>> <mailto:emartins@redhat.com>> wrote:
>>>>
>>>> Wolfgang: yours and mine PRs are merged, and when WFLY 17 Final is
>>>> out I will also deploy the archetype, thanks a lot for your
>>>> contribution! Yet now I have to ask, do you plan to submit similar
>>>> for the other old javaee archetype? :-)
>>>>
>>>> Brian: yep it was just the JDK, I will deploy these too (no planned
>>>> updates in such code tho)
>>>>
>>>> —E
>>>>
>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<emartins(a)redhat.com
>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>
>>>>> Hmm ok, maybe it just failed build due to some specific like
JDK
>>>>> 11, will recheck that.
>>>>>
>>>>> —E
>>>>>
>>>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>>>> <brian.stansberry(a)redhat.com
>>>>>> <mailto:brian.stansberry@redhat.com>> wrote:
>>>>>>
>>>>>> These build for me.
>>>>>>
>>>>>> They're not as out of date as I'd thought either.
>>>>>>
>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>
>>>>>> If you think it’s not a small effort task then
certainly
>>>>>> agree that’s not a blocker, I look at the archetypes
same way
>>>>>> as the quickstarts, an aggregation project, so we may
take
>>>>>> outdated/faulty ones out of build and release the
>>>>>> working+actual ones. We may give it a thought later if
it
>>>>>> makes sense effort wise to update or drop the subsystem
ones,
>>>>>> no worries.
>>>>>>
>>>>>> —E
>>>>>>
3:35 p.m.
Hi Eduardo,
wanted to ask for an update on this pull request.
It is already outdated, as WildFly 17 is now final and all versions in
pom.xml should be updated...
Best regards
Wolfgang
Am 16.06.19 um 14:12 schrieb Wolfgang Knauf:
Hi Eduardo,
i sent a pull request for this new archetype, without beans.xml.
Depending on your findings, we can add it afterwards if necessary.
But as far as I understand it, this file is optional now
(https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
- so this could be considered a bug...
Best regards
Wolfgang
Am 12.06.19 um 22:37 schrieb Eduardo Martins:
> Hi Wolfgang, when reviewing it seemed to me that in the *ear*
> archetype the beans.xml was not needed. I can’t tell if that’s the
> case for this new archetype without you submitting it for review, but
> if it fails to deploy without it… ;-)
>
> —E
>
>> On 12 Jun 2019, at 20:57, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>>
>> Hi to all,
>>
>> just wanted to ask for an update: do you think that the error message is
>> acceptable and I should create the archetype without "beans.xml"
anyway
>> (and add an info to the readme.txt file)?
>> Or should I add a default "beans.xml" to the archetype to avoid it?
>> Or is it worth a JIRA?
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>> Hi Eduardo,
>>>
>>> while building a "wildfly-javaee-webapp-archetype", I think I found
a
>>> small WildFly issue: you remember that you pointed me to the fact that
>>> "beans.xml" is optional?
>>> But when creating a blank project from my new web archetype (which
>>> defines a "faces-config.xml", but no "beans.xml"), the
attached
>>> error is
>>> in the WildFly console. But it seems the app is deployed anyway.
>>>
>>> The error disappears if I add e.g. an annotated EJB, or if I add a
>>> "beans.xml".
>>>
>>> Do you think this is a WildFly bug? Or should I add a default
>>> "beans.xml" just to avoid this error?
>>>
>>> I did not test it with a blank project from the EAR archetype - will do
>>> this in the next few days.
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>>
>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>> Thanks for the deploy, Eduardo!
>>>>
>>>> If you consider it reasonable I will create an archetype for "web
app
>>>> only", similar to the old
"wildfly-javaee7-webapp-archetype".
>>>> But I will probably need a few weeks...
>>>>
>>>> What happens to the old archetype
>>>> "wildfly-javaee7-webapp-ear-archetype"? It could be deleted, as
it
>>>> does not build anyway. It might be relevant only for research.
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>>
>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>> Excellent! Thank you so much Wolfgang!
>>>>>
>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins
<emartins(a)redhat.com
>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>
>>>>> Wolfgang: yours and mine PRs are merged, and when WFLY 17
>>>>> Final is
>>>>> out I will also deploy the archetype, thanks a lot for your
>>>>> contribution! Yet now I have to ask, do you plan to submit
>>>>> similar
>>>>> for the other old javaee archetype? :-)
>>>>>
>>>>> Brian: yep it was just the JDK, I will deploy these too (no
>>>>> planned
>>>>> updates in such code tho)
>>>>>
>>>>> —E
>>>>>
>>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<emartins(a)redhat.com
>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>
>>>>>> Hmm ok, maybe it just failed build due to some specific
like
>>>>>> JDK
>>>>>> 11, will recheck that.
>>>>>>
>>>>>> —E
>>>>>>
>>>>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>>>>> <brian.stansberry(a)redhat.com
>>>>>>> <mailto:brian.stansberry@redhat.com>> wrote:
>>>>>>>
>>>>>>> These build for me.
>>>>>>>
>>>>>>> They're not as out of date as I'd thought
either.
>>>>>>>
>>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>>
>>>>>>> If you think it’s not a small effort task then
certainly
>>>>>>> agree that’s not a blocker, I look at the
archetypes
>>>>>>> same way
>>>>>>> as the quickstarts, an aggregation project, so we
may
>>>>>>> take
>>>>>>> outdated/faulty ones out of build and release the
>>>>>>> working+actual ones. We may give it a thought later
if it
>>>>>>> makes sense effort wise to update or drop the
subsystem
>>>>>>> ones,
>>>>>>> no worries.
>>>>>>>
>>>>>>> —E
>>>>>>>
>
>
2:18 p.m.
Hi Eduardo,
once again a reminder for
https://github.com/wildfly/wildfly-archetypes/pull/5 ;-).
I updated the two archetypes to use WildFly 17.0.Final.
Best regards
Wolfgang
Am 07.08.19 um 22:35 schrieb Wolfgang Knauf:
Hi Eduardo,
wanted to ask for an update on this pull request.
It is already outdated, as WildFly 17 is now final and all versions in
pom.xml should be updated...
Best regards
Wolfgang
Am 16.06.19 um 14:12 schrieb Wolfgang Knauf:
> Hi Eduardo,
>
> i sent a pull request for this new archetype, without beans.xml.
> Depending on your findings, we can add it afterwards if necessary.
>
> But as far as I understand it, this file is optional now
> (https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
> - so this could be considered a bug...
>
> Best regards
>
> Wolfgang
>
>
> Am 12.06.19 um 22:37 schrieb Eduardo Martins:
>> Hi Wolfgang, when reviewing it seemed to me that in the *ear*
>> archetype the beans.xml was not needed. I can’t tell if that’s the
>> case for this new archetype without you submitting it for review, but
>> if it fails to deploy without it… ;-)
>>
>> —E
>>
>>> On 12 Jun 2019, at 20:57, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
>>>
>>> Hi to all,
>>>
>>> just wanted to ask for an update: do you think that the error
>>> message is
>>> acceptable and I should create the archetype without "beans.xml"
anyway
>>> (and add an info to the readme.txt file)?
>>> Or should I add a default "beans.xml" to the archetype to avoid
it?
>>> Or is it worth a JIRA?
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>>> Hi Eduardo,
>>>>
>>>> while building a "wildfly-javaee-webapp-archetype", I think I
found a
>>>> small WildFly issue: you remember that you pointed me to the fact that
>>>> "beans.xml" is optional?
>>>> But when creating a blank project from my new web archetype (which
>>>> defines a "faces-config.xml", but no "beans.xml"),
the attached
>>>> error is
>>>> in the WildFly console. But it seems the app is deployed anyway.
>>>>
>>>> The error disappears if I add e.g. an annotated EJB, or if I add a
>>>> "beans.xml".
>>>>
>>>> Do you think this is a WildFly bug? Or should I add a default
>>>> "beans.xml" just to avoid this error?
>>>>
>>>> I did not test it with a blank project from the EAR archetype -
>>>> will do
>>>> this in the next few days.
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>>> Thanks for the deploy, Eduardo!
>>>>>
>>>>> If you consider it reasonable I will create an archetype for
"web app
>>>>> only", similar to the old
"wildfly-javaee7-webapp-archetype".
>>>>> But I will probably need a few weeks...
>>>>>
>>>>> What happens to the old archetype
>>>>> "wildfly-javaee7-webapp-ear-archetype"? It could be
deleted, as it
>>>>> does not build anyway. It might be relevant only for research.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Wolfgang
>>>>>
>>>>>
>>>>>
>>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>>> Excellent! Thank you so much Wolfgang!
>>>>>>
>>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins
<emartins(a)redhat.com
>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>
>>>>>> Wolfgang: yours and mine PRs are merged, and when WFLY 17
>>>>>> Final is
>>>>>> out I will also deploy the archetype, thanks a lot for your
>>>>>> contribution! Yet now I have to ask, do you plan to submit
>>>>>> similar
>>>>>> for the other old javaee archetype? :-)
>>>>>>
>>>>>> Brian: yep it was just the JDK, I will deploy these too (no
>>>>>> planned
>>>>>> updates in such code tho)
>>>>>>
>>>>>> —E
>>>>>>
>>>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<emartins(a)redhat.com
>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>
>>>>>>> Hmm ok, maybe it just failed build due to some specific
>>>>>>> like JDK
>>>>>>> 11, will recheck that.
>>>>>>>
>>>>>>> —E
>>>>>>>
>>>>>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>>>>>> <brian.stansberry(a)redhat.com
>>>>>>>> <mailto:brian.stansberry@redhat.com>>
wrote:
>>>>>>>>
>>>>>>>> These build for me.
>>>>>>>>
>>>>>>>> They're not as out of date as I'd thought
either.
>>>>>>>>
>>>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>>>
>>>>>>>> If you think it’s not a small effort task then
certainly
>>>>>>>> agree that’s not a blocker, I look at the
archetypes
>>>>>>>> same way
>>>>>>>> as the quickstarts, an aggregation project, so
we may
>>>>>>>> take
>>>>>>>> outdated/faulty ones out of build and release
the
>>>>>>>> working+actual ones. We may give it a thought
later if it
>>>>>>>> makes sense effort wise to update or drop the
>>>>>>>> subsystem ones,
>>>>>>>> no worries.
>>>>>>>>
>>>>>>>> —E
>>>>>>>>
>>
>>
3:25 a.m.
Hi Wolfgang, fyi just got back from some time off, and should be able to look at this next
week.
—E
On 11 Sep 2019, at 20:18, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
Hi Eduardo,
once again a reminder for
https://github.com/wildfly/wildfly-archetypes/pull/5 ;-).
I updated the two archetypes to use WildFly 17.0.Final.
Best regards
Wolfgang
Am 07.08.19 um 22:35 schrieb Wolfgang Knauf:
> Hi Eduardo,
>
> wanted to ask for an update on this pull request.
>
> It is already outdated, as WildFly 17 is now final and all versions in
> pom.xml should be updated...
>
> Best regards
>
> Wolfgang
>
> Am 16.06.19 um 14:12 schrieb Wolfgang Knauf:
>> Hi Eduardo,
>>
>> i sent a pull request for this new archetype, without beans.xml.
>> Depending on your findings, we can add it afterwards if necessary.
>>
>> But as far as I understand it, this file is optional now
>> (https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
>> - so this could be considered a bug...
>>
>> Best regards
>>
>> Wolfgang
>>
>>
>> Am 12.06.19 um 22:37 schrieb Eduardo Martins:
>>> Hi Wolfgang, when reviewing it seemed to me that in the *ear*
>>> archetype the beans.xml was not needed. I can’t tell if that’s the
>>> case for this new archetype without you submitting it for review, but
>>> if it fails to deploy without it… ;-)
>>>
>>> —E
>>>
>>>> On 12 Jun 2019, at 20:57, Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
>>>>
>>>> Hi to all,
>>>>
>>>> just wanted to ask for an update: do you think that the error
>>>> message is
>>>> acceptable and I should create the archetype without
"beans.xml" anyway
>>>> (and add an info to the readme.txt file)?
>>>> Or should I add a default "beans.xml" to the archetype to avoid
it?
>>>> Or is it worth a JIRA?
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>>>> Hi Eduardo,
>>>>>
>>>>> while building a "wildfly-javaee-webapp-archetype", I think
I found a
>>>>> small WildFly issue: you remember that you pointed me to the fact
that
>>>>> "beans.xml" is optional?
>>>>> But when creating a blank project from my new web archetype (which
>>>>> defines a "faces-config.xml", but no
"beans.xml"), the attached
>>>>> error is
>>>>> in the WildFly console. But it seems the app is deployed anyway.
>>>>>
>>>>> The error disappears if I add e.g. an annotated EJB, or if I add a
>>>>> "beans.xml".
>>>>>
>>>>> Do you think this is a WildFly bug? Or should I add a default
>>>>> "beans.xml" just to avoid this error?
>>>>>
>>>>> I did not test it with a blank project from the EAR archetype -
>>>>> will do
>>>>> this in the next few days.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Wolfgang
>>>>>
>>>>>
>>>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>>>> Thanks for the deploy, Eduardo!
>>>>>>
>>>>>> If you consider it reasonable I will create an archetype for
"web app
>>>>>> only", similar to the old
"wildfly-javaee7-webapp-archetype".
>>>>>> But I will probably need a few weeks...
>>>>>>
>>>>>> What happens to the old archetype
>>>>>> "wildfly-javaee7-webapp-ear-archetype"? It could be
deleted, as it
>>>>>> does not build anyway. It might be relevant only for research.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>>>> Excellent! Thank you so much Wolfgang!
>>>>>>>
>>>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins
<emartins(a)redhat.com
>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>
>>>>>>> Wolfgang: yours and mine PRs are merged, and when WFLY
17
>>>>>>> Final is
>>>>>>> out I will also deploy the archetype, thanks a lot for
your
>>>>>>> contribution! Yet now I have to ask, do you plan to
submit
>>>>>>> similar
>>>>>>> for the other old javaee archetype? :-)
>>>>>>>
>>>>>>> Brian: yep it was just the JDK, I will deploy these too
(no
>>>>>>> planned
>>>>>>> updates in such code tho)
>>>>>>>
>>>>>>> —E
>>>>>>>
>>>>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<emartins(a)redhat.com
>>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>>
>>>>>>>> Hmm ok, maybe it just failed build due to some
specific
>>>>>>>> like JDK
>>>>>>>> 11, will recheck that.
>>>>>>>>
>>>>>>>> —E
>>>>>>>>
>>>>>>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>>>>>>> <brian.stansberry(a)redhat.com
>>>>>>>>> <mailto:brian.stansberry@redhat.com>>
wrote:
>>>>>>>>>
>>>>>>>>> These build for me.
>>>>>>>>>
>>>>>>>>> They're not as out of date as I'd
thought either.
>>>>>>>>>
>>>>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins
>>>>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>>>>
>>>>>>>>> If you think it’s not a small effort task
then certainly
>>>>>>>>> agree that’s not a blocker, I look at the
archetypes
>>>>>>>>> same way
>>>>>>>>> as the quickstarts, an aggregation project,
so we may
>>>>>>>>> take
>>>>>>>>> outdated/faulty ones out of build and
release the
>>>>>>>>> working+actual ones. We may give it a
thought later if it
>>>>>>>>> makes sense effort wise to update or drop
the
>>>>>>>>> subsystem ones,
>>>>>>>>> no worries.
>>>>>>>>>
>>>>>>>>> —E
>>>>>>>>>
>>>
>>>
2:28 p.m.
Good news Wolfgang, I just released WildFly Archetypes 18.0.0.Final!
Besides merging your PR I did a couple major changes:
1. Cleaned up the repo of the old archetypes and setup a maven project aggregator [1]
2. Moved all to WildFly 18.0.0.Final and… Jakarta EE! [2]
All archetypes were deployed too, just try it out on your command line right now...
$ mvn archetype:generate -DgroupId=my.project.org -DartifactId=sampleproject
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.wildfly.archetype
-DarchetypeArtifactId=wildfly-jakartaee-ear-archetype -DarchetypeVersion=18.0.0.Final
or…
$ mvn archetype:generate -DgroupId=my.project.org -DartifactId=sampleproject
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.wildfly.archetype
-DarchetypeArtifactId=wildfly-jakartaee-webapp-archetype -DarchetypeVersion=18.0.0.Final
Feel free to have a look at the master branch now, it’s already set for WFLY 19
development, even if honestly I dunno yet how we going to maintain this project, but will
certainly let you know once we have that figured out.
So… huge huge thank you, for your contributions, and also for your patience :-)
Best regards.
—E
[1]
https://github.com/wildfly/wildfly-archetypes/commit/c960f01cf8d5ab3d115b...
[2]
https://github.com/wildfly/wildfly-archetypes/commit/8dc0e2fbacb51142b024...
On 16 Sep 2019, at 09:25, Eduardo Martins <emartins(a)redhat.com>
wrote:
Hi Wolfgang, fyi just got back from some time off, and should be able to look at this
next week.
—E
> On 11 Sep 2019, at 20:18, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>
> Hi Eduardo,
>
> once again a reminder for
> https://github.com/wildfly/wildfly-archetypes/pull/5 ;-).
> I updated the two archetypes to use WildFly 17.0.Final.
>
> Best regards
>
> Wolfgang
>
> Am 07.08.19 um 22:35 schrieb Wolfgang Knauf:
>> Hi Eduardo,
>>
>> wanted to ask for an update on this pull request.
>>
>> It is already outdated, as WildFly 17 is now final and all versions in
>> pom.xml should be updated...
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 16.06.19 um 14:12 schrieb Wolfgang Knauf:
>>> Hi Eduardo,
>>>
>>> i sent a pull request for this new archetype, without beans.xml.
>>> Depending on your findings, we can add it afterwards if necessary.
>>>
>>> But as far as I understand it, this file is optional now
>>> (https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
>>> - so this could be considered a bug...
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>>
>>> Am 12.06.19 um 22:37 schrieb Eduardo Martins:
>>>> Hi Wolfgang, when reviewing it seemed to me that in the *ear*
>>>> archetype the beans.xml was not needed. I can’t tell if that’s the
>>>> case for this new archetype without you submitting it for review, but
>>>> if it fails to deploy without it… ;-)
>>>>
>>>> —E
>>>>
>>>>> On 12 Jun 2019, at 20:57, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
>>>>>
>>>>> Hi to all,
>>>>>
>>>>> just wanted to ask for an update: do you think that the error
>>>>> message is
>>>>> acceptable and I should create the archetype without
"beans.xml" anyway
>>>>> (and add an info to the readme.txt file)?
>>>>> Or should I add a default "beans.xml" to the archetype to
avoid it?
>>>>> Or is it worth a JIRA?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Wolfgang
>>>>>
>>>>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>>>>> Hi Eduardo,
>>>>>>
>>>>>> while building a "wildfly-javaee-webapp-archetype", I
think I found a
>>>>>> small WildFly issue: you remember that you pointed me to the fact
that
>>>>>> "beans.xml" is optional?
>>>>>> But when creating a blank project from my new web archetype
(which
>>>>>> defines a "faces-config.xml", but no
"beans.xml"), the attached
>>>>>> error is
>>>>>> in the WildFly console. But it seems the app is deployed anyway.
>>>>>>
>>>>>> The error disappears if I add e.g. an annotated EJB, or if I add
a
>>>>>> "beans.xml".
>>>>>>
>>>>>> Do you think this is a WildFly bug? Or should I add a default
>>>>>> "beans.xml" just to avoid this error?
>>>>>>
>>>>>> I did not test it with a blank project from the EAR archetype -
>>>>>> will do
>>>>>> this in the next few days.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>>
>>>>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>>>>> Thanks for the deploy, Eduardo!
>>>>>>>
>>>>>>> If you consider it reasonable I will create an archetype for
"web app
>>>>>>> only", similar to the old
"wildfly-javaee7-webapp-archetype".
>>>>>>> But I will probably need a few weeks...
>>>>>>>
>>>>>>> What happens to the old archetype
>>>>>>> "wildfly-javaee7-webapp-ear-archetype"? It could be
deleted, as it
>>>>>>> does not build anyway. It might be relevant only for
research.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Wolfgang
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>>>>> Excellent! Thank you so much Wolfgang!
>>>>>>>>
>>>>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins
<emartins(a)redhat.com
>>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>>
>>>>>>>> Wolfgang: yours and mine PRs are merged, and when
WFLY 17
>>>>>>>> Final is
>>>>>>>> out I will also deploy the archetype, thanks a lot
for your
>>>>>>>> contribution! Yet now I have to ask, do you plan to
submit
>>>>>>>> similar
>>>>>>>> for the other old javaee archetype? :-)
>>>>>>>>
>>>>>>>> Brian: yep it was just the JDK, I will deploy these
too (no
>>>>>>>> planned
>>>>>>>> updates in such code tho)
>>>>>>>>
>>>>>>>> —E
>>>>>>>>
>>>>>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<emartins(a)redhat.com
>>>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>>>
>>>>>>>>> Hmm ok, maybe it just failed build due to some
specific
>>>>>>>>> like JDK
>>>>>>>>> 11, will recheck that.
>>>>>>>>>
>>>>>>>>> —E
>>>>>>>>>
>>>>>>>>>> On 16 May 2019, at 02:25, Brian Stansberry
>>>>>>>>>> <brian.stansberry(a)redhat.com
>>>>>>>>>>
<mailto:brian.stansberry@redhat.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> These build for me.
>>>>>>>>>>
>>>>>>>>>> They're not as out of date as I'd
thought either.
>>>>>>>>>>
>>>>>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo
Martins
>>>>>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> If you think it’s not a small effort task
then certainly
>>>>>>>>>> agree that’s not a blocker, I look at the
archetypes
>>>>>>>>>> same way
>>>>>>>>>> as the quickstarts, an aggregation
project, so we may
>>>>>>>>>> take
>>>>>>>>>> outdated/faulty ones out of build and
release the
>>>>>>>>>> working+actual ones. We may give it a
thought later if it
>>>>>>>>>> makes sense effort wise to update or drop
the
>>>>>>>>>> subsystem ones,
>>>>>>>>>> no worries.
>>>>>>>>>>
>>>>>>>>>> —E
>>>>>>>>>>
>>>>
>>>>
2:51 p.m.
Many thanks Eduardo!
I will take a look at it during the next few days, and I will also check
whether the deploy error with blank web archetype project still occurs
with WildFly 18.
I did not manage to use this archetype from Eclipse. It seems it must be
added to http://central.maven.org/maven2/archetype-catalog.xml so that
Eclipse can detect it.
Do you know how this happens?
Best regards
Wolfgang
Am 14.10.19 um 21:28 schrieb Eduardo Martins:
Good news Wolfgang, I just released WildFly Archetypes 18.0.0.Final!
Besides merging your PR I did a couple major changes:
1. Cleaned up the repo of the old archetypes and setup a maven project aggregator [1]
2. Moved all to WildFly 18.0.0.Final and… Jakarta EE! [2]
All archetypes were deployed too, just try it out on your command line right now...
$ mvn archetype:generate -DgroupId=my.project.org -DartifactId=sampleproject
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.wildfly.archetype
-DarchetypeArtifactId=wildfly-jakartaee-ear-archetype -DarchetypeVersion=18.0.0.Final
or…
$ mvn archetype:generate -DgroupId=my.project.org -DartifactId=sampleproject
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.wildfly.archetype
-DarchetypeArtifactId=wildfly-jakartaee-webapp-archetype -DarchetypeVersion=18.0.0.Final
Feel free to have a look at the master branch now, it’s already set for WFLY 19
development, even if honestly I dunno yet how we going to maintain this project, but will
certainly let you know once we have that figured out.
So… huge huge thank you, for your contributions, and also for your patience :-)
Best regards.
—E
[1]
https://github.com/wildfly/wildfly-archetypes/commit/c960f01cf8d5ab3d115b...
[2]
https://github.com/wildfly/wildfly-archetypes/commit/8dc0e2fbacb51142b024...
> On 16 Sep 2019, at 09:25, Eduardo Martins <emartins(a)redhat.com> wrote:
>
> Hi Wolfgang, fyi just got back from some time off, and should be able to look at this
next week.
>
> —E
>
>> On 11 Sep 2019, at 20:18, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>>
>> Hi Eduardo,
>>
>> once again a reminder for
>> https://github.com/wildfly/wildfly-archetypes/pull/5 ;-).
>> I updated the two archetypes to use WildFly 17.0.Final.
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 07.08.19 um 22:35 schrieb Wolfgang Knauf:
>>> Hi Eduardo,
>>>
>>> wanted to ask for an update on this pull request.
>>>
>>> It is already outdated, as WildFly 17 is now final and all versions in
>>> pom.xml should be updated...
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>> Am 16.06.19 um 14:12 schrieb Wolfgang Knauf:
>>>> Hi Eduardo,
>>>>
>>>> i sent a pull request for this new archetype, without beans.xml.
>>>> Depending on your findings, we can add it afterwards if necessary.
>>>>
>>>> But as far as I understand it, this file is optional now
>>>>
(https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
>>>> - so this could be considered a bug...
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>> Am 12.06.19 um 22:37 schrieb Eduardo Martins:
>>>>> Hi Wolfgang, when reviewing it seemed to me that in the *ear*
>>>>> archetype the beans.xml was not needed. I can’t tell if that’s the
>>>>> case for this new archetype without you submitting it for review,
but
>>>>> if it fails to deploy without it… ;-)
>>>>>
>>>>> —E
>>>>>
>>>>>> On 12 Jun 2019, at 20:57, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de> wrote:
>>>>>>
>>>>>> Hi to all,
>>>>>>
>>>>>> just wanted to ask for an update: do you think that the error
>>>>>> message is
>>>>>> acceptable and I should create the archetype without
"beans.xml" anyway
>>>>>> (and add an info to the readme.txt file)?
>>>>>> Or should I add a default "beans.xml" to the archetype
to avoid it?
>>>>>> Or is it worth a JIRA?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>>>>>> Hi Eduardo,
>>>>>>>
>>>>>>> while building a "wildfly-javaee-webapp-archetype",
I think I found a
>>>>>>> small WildFly issue: you remember that you pointed me to the
fact that
>>>>>>> "beans.xml" is optional?
>>>>>>> But when creating a blank project from my new web archetype
(which
>>>>>>> defines a "faces-config.xml", but no
"beans.xml"), the attached
>>>>>>> error is
>>>>>>> in the WildFly console. But it seems the app is deployed
anyway.
>>>>>>>
>>>>>>> The error disappears if I add e.g. an annotated EJB, or if I
add a
>>>>>>> "beans.xml".
>>>>>>>
>>>>>>> Do you think this is a WildFly bug? Or should I add a
default
>>>>>>> "beans.xml" just to avoid this error?
>>>>>>>
>>>>>>> I did not test it with a blank project from the EAR archetype
-
>>>>>>> will do
>>>>>>> this in the next few days.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Wolfgang
>>>>>>>
>>>>>>>
>>>>>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>>>>>> Thanks for the deploy, Eduardo!
>>>>>>>>
>>>>>>>> If you consider it reasonable I will create an archetype
for "web app
>>>>>>>> only", similar to the old
"wildfly-javaee7-webapp-archetype".
>>>>>>>> But I will probably need a few weeks...
>>>>>>>>
>>>>>>>> What happens to the old archetype
>>>>>>>> "wildfly-javaee7-webapp-ear-archetype"? It
could be deleted, as it
>>>>>>>> does not build anyway. It might be relevant only for
research.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Wolfgang
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>>>>>> Excellent! Thank you so much Wolfgang!
>>>>>>>>>
>>>>>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins
<emartins(a)redhat.com
>>>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>>>
>>>>>>>>> Wolfgang: yours and mine PRs are merged, and
when WFLY 17
>>>>>>>>> Final is
>>>>>>>>> out I will also deploy the archetype, thanks a
lot for your
>>>>>>>>> contribution! Yet now I have to ask, do you plan
to submit
>>>>>>>>> similar
>>>>>>>>> for the other old javaee archetype? :-)
>>>>>>>>>
>>>>>>>>> Brian: yep it was just the JDK, I will deploy
these too (no
>>>>>>>>> planned
>>>>>>>>> updates in such code tho)
>>>>>>>>>
>>>>>>>>> —E
>>>>>>>>>
>>>>>>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<emartins(a)redhat.com
>>>>>>>>>> <mailto:emartins@redhat.com>>
wrote:
>>>>>>>>>>
>>>>>>>>>> Hmm ok, maybe it just failed build due to
some specific
>>>>>>>>>> like JDK
>>>>>>>>>> 11, will recheck that.
>>>>>>>>>>
>>>>>>>>>> —E
>>>>>>>>>>
>>>>>>>>>>> On 16 May 2019, at 02:25, Brian
Stansberry
>>>>>>>>>>> <brian.stansberry(a)redhat.com
>>>>>>>>>>>
<mailto:brian.stansberry@redhat.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> These build for me.
>>>>>>>>>>>
>>>>>>>>>>> They're not as out of date as
I'd thought either.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo
Martins
>>>>>>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If you think it’s not a small effort
task then certainly
>>>>>>>>>>> agree that’s not a blocker, I look
at the archetypes
>>>>>>>>>>> same way
>>>>>>>>>>> as the quickstarts, an aggregation
project, so we may
>>>>>>>>>>> take
>>>>>>>>>>> outdated/faulty ones out of build
and release the
>>>>>>>>>>> working+actual ones. We may give it
a thought later if it
>>>>>>>>>>> makes sense effort wise to update or
drop the
>>>>>>>>>>> subsystem ones,
>>>>>>>>>>> no worries.
>>>>>>>>>>>
>>>>>>>>>>> —E
>>>>>>>>>>>
>>>>>
>>>>>
>
3:34 p.m.
Hi Eduardo,
after waiting some days, the archetype was added to the file mentioned
below. If this was your magical work, then "thank you!" ;-).
The deployment error for empty projects created based on the webapp
archetype is also gone for WildFly 18.
All issues are resolved, thanks for your work on the archetype!
When WildFly 19 is on the way, I will check whether changes are required.
What do you think is best: create a new archetype version for any
WildFly version, or do this only if relevant changes besides changing
the WildFly version in pom.xml are required? I would prefer creating an
archetype for each version - then a user has archetypes for any version,
without having to research compatibilites.
Best regards
Wolfgang
Am 16.10.19 um 21:51 schrieb Wolfgang Knauf:
Many thanks Eduardo!
I will take a look at it during the next few days, and I will also check
whether the deploy error with blank web archetype project still occurs
with WildFly 18.
I did not manage to use this archetype from Eclipse. It seems it must be
added to http://central.maven.org/maven2/archetype-catalog.xml so that
Eclipse can detect it.
Do you know how this happens?
Best regards
Wolfgang
Am 14.10.19 um 21:28 schrieb Eduardo Martins:
> Good news Wolfgang, I just released WildFly Archetypes 18.0.0.Final!
>
> Besides merging your PR I did a couple major changes:
>
> 1. Cleaned up the repo of the old archetypes and setup a maven
> project aggregator [1]
> 2. Moved all to WildFly 18.0.0.Final and… Jakarta EE! [2]
>
> All archetypes were deployed too, just try it out on your command line
> right now...
>
> $ mvn archetype:generate -DgroupId=my.project.org
> -DartifactId=sampleproject -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.wildfly.archetype
> -DarchetypeArtifactId=wildfly-jakartaee-ear-archetype
> -DarchetypeVersion=18.0.0.Final
>
> or…
>
> $ mvn archetype:generate -DgroupId=my.project.org
> -DartifactId=sampleproject -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.wildfly.archetype
> -DarchetypeArtifactId=wildfly-jakartaee-webapp-archetype
> -DarchetypeVersion=18.0.0.Final
>
> Feel free to have a look at the master branch now, it’s already set
> for WFLY 19 development, even if honestly I dunno yet how we going to
> maintain this project, but will certainly let you know once we have
> that figured out.
>
> So… huge huge thank you, for your contributions, and also for your
> patience :-)
>
> Best regards.
>
> —E
>
> [1]
>
https://github.com/wildfly/wildfly-archetypes/commit/c960f01cf8d5ab3d115b...
>
> [2]
>
https://github.com/wildfly/wildfly-archetypes/commit/8dc0e2fbacb51142b024...
>
>
2:54 p.m.
Excellent!
Thanks, Wolfgang and Eduardo!
Best regards,
Brian
On Mon, Oct 14, 2019 at 2:29 PM Eduardo Martins <emartins(a)redhat.com> wrote:
Good news Wolfgang, I just released WildFly Archetypes 18.0.0.Final!
Besides merging your PR I did a couple major changes:
1. Cleaned up the repo of the old archetypes and setup a maven
project aggregator [1]
2. Moved all to WildFly 18.0.0.Final and… Jakarta EE! [2]
All archetypes were deployed too, just try it out on your command line
right now...
$ mvn archetype:generate -DgroupId=my.project.org
-DartifactId=sampleproject -Dversion=1.0-SNAPSHOT
-DarchetypeGroupId=org.wildfly.archetype
-DarchetypeArtifactId=wildfly-jakartaee-ear-archetype
-DarchetypeVersion=18.0.0.Final
or…
$ mvn archetype:generate -DgroupId=my.project.org
-DartifactId=sampleproject -Dversion=1.0-SNAPSHOT
-DarchetypeGroupId=org.wildfly.archetype
-DarchetypeArtifactId=wildfly-jakartaee-webapp-archetype
-DarchetypeVersion=18.0.0.Final
Feel free to have a look at the master branch now, it’s already set for
WFLY 19 development, even if honestly I dunno yet how we going to maintain
this project, but will certainly let you know once we have that figured out.
So… huge huge thank you, for your contributions, and also for your
patience :-)
Best regards.
—E
[1]
https://github.com/wildfly/wildfly-archetypes/commit/c960f01cf8d5ab3d115b...
[2]
https://github.com/wildfly/wildfly-archetypes/commit/8dc0e2fbacb51142b024...
> On 16 Sep 2019, at 09:25, Eduardo Martins <emartins(a)redhat.com> wrote:
>
> Hi Wolfgang, fyi just got back from some time off, and should be able to
look at this next week.
>
> —E
>
>> On 11 Sep 2019, at 20:18, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>>
>> Hi Eduardo,
>>
>> once again a reminder for
>> https://github.com/wildfly/wildfly-archetypes/pull/5 ;-).
>> I updated the two archetypes to use WildFly 17.0.Final.
>>
>> Best regards
>>
>> Wolfgang
>>
>> Am 07.08.19 um 22:35 schrieb Wolfgang Knauf:
>>> Hi Eduardo,
>>>
>>> wanted to ask for an update on this pull request.
>>>
>>> It is already outdated, as WildFly 17 is now final and all versions in
>>> pom.xml should be updated...
>>>
>>> Best regards
>>>
>>> Wolfgang
>>>
>>> Am 16.06.19 um 14:12 schrieb Wolfgang Knauf:
>>>> Hi Eduardo,
>>>>
>>>> i sent a pull request for this new archetype, without beans.xml.
>>>> Depending on your findings, we can add it afterwards if necessary.
>>>>
>>>> But as far as I understand it, this file is optional now
>>>> (
https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7)
>>>> - so this could be considered a bug...
>>>>
>>>> Best regards
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>> Am 12.06.19 um 22:37 schrieb Eduardo Martins:
>>>>> Hi Wolfgang, when reviewing it seemed to me that in the *ear*
>>>>> archetype the beans.xml was not needed. I can’t tell if that’s the
>>>>> case for this new archetype without you submitting it for review,
but
>>>>> if it fails to deploy without it… ;-)
>>>>>
>>>>> —E
>>>>>
>>>>>> On 12 Jun 2019, at 20:57, Wolfgang Knauf
<wolfgang.knauf(a)gmx.de>
wrote:
>>>>>>
>>>>>> Hi to all,
>>>>>>
>>>>>> just wanted to ask for an update: do you think that the error
>>>>>> message is
>>>>>> acceptable and I should create the archetype without
"beans.xml"
anyway
>>>>>> (and add an info to the readme.txt file)?
>>>>>> Or should I add a default "beans.xml" to the archetype
to avoid it?
>>>>>> Or is it worth a JIRA?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>> Am 05.06.19 um 21:42 schrieb Wolfgang Knauf:
>>>>>>> Hi Eduardo,
>>>>>>>
>>>>>>> while building a
"wildfly-javaee-webapp-archetype", I think I
found a
>>>>>>> small WildFly issue: you remember that you pointed me to the
fact
that
>>>>>>> "beans.xml" is optional?
>>>>>>> But when creating a blank project from my new web archetype
(which
>>>>>>> defines a "faces-config.xml", but no
"beans.xml"), the attached
>>>>>>> error is
>>>>>>> in the WildFly console. But it seems the app is deployed
anyway.
>>>>>>>
>>>>>>> The error disappears if I add e.g. an annotated EJB, or if I
add a
>>>>>>> "beans.xml".
>>>>>>>
>>>>>>> Do you think this is a WildFly bug? Or should I add a
default
>>>>>>> "beans.xml" just to avoid this error?
>>>>>>>
>>>>>>> I did not test it with a blank project from the EAR
archetype -
>>>>>>> will do
>>>>>>> this in the next few days.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Wolfgang
>>>>>>>
>>>>>>>
>>>>>>> Am 03.06.19 um 21:36 schrieb Wolfgang Knauf:
>>>>>>>> Thanks for the deploy, Eduardo!
>>>>>>>>
>>>>>>>> If you consider it reasonable I will create an archetype
for "web
app
>>>>>>>> only", similar to the old
"wildfly-javaee7-webapp-archetype".
>>>>>>>> But I will probably need a few weeks...
>>>>>>>>
>>>>>>>> What happens to the old archetype
>>>>>>>> "wildfly-javaee7-webapp-ear-archetype"? It
could be deleted, as it
>>>>>>>> does not build anyway. It might be relevant only for
research.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Wolfgang
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 03.06.19 um 17:05 schrieb Brian Stansberry:
>>>>>>>>> Excellent! Thank you so much Wolfgang!
>>>>>>>>>
>>>>>>>>> On Mon, Jun 3, 2019 at 9:52 AM Eduardo Martins <
emartins(a)redhat.com
>>>>>>>>> <mailto:emartins@redhat.com>> wrote:
>>>>>>>>>
>>>>>>>>> Wolfgang: yours and mine PRs are merged, and
when WFLY 17
>>>>>>>>> Final is
>>>>>>>>> out I will also deploy the archetype, thanks a
lot for your
>>>>>>>>> contribution! Yet now I have to ask, do you plan
to submit
>>>>>>>>> similar
>>>>>>>>> for the other old javaee archetype? :-)
>>>>>>>>>
>>>>>>>>> Brian: yep it was just the JDK, I will deploy
these too (no
>>>>>>>>> planned
>>>>>>>>> updates in such code tho)
>>>>>>>>>
>>>>>>>>> —E
>>>>>>>>>
>>>>>>>>>> On 16 May 2019, at 10:09, Eduardo Martins
<
emartins(a)redhat.com
>>>>>>>>>> <mailto:emartins@redhat.com>>
wrote:
>>>>>>>>>>
>>>>>>>>>> Hmm ok, maybe it just failed build due to
some specific
>>>>>>>>>> like JDK
>>>>>>>>>> 11, will recheck that.
>>>>>>>>>>
>>>>>>>>>> —E
>>>>>>>>>>
>>>>>>>>>>> On 16 May 2019, at 02:25, Brian
Stansberry
>>>>>>>>>>> <brian.stansberry(a)redhat.com
>>>>>>>>>>>
<mailto:brian.stansberry@redhat.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> These build for me.
>>>>>>>>>>>
>>>>>>>>>>> They're not as out of date as
I'd thought either.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, May 10, 2019 at 6:34 PM Eduardo
Martins
>>>>>>>>>>> <emartins(a)redhat.com
<mailto:emartins@redhat.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If you think it’s not a small effort
task then
certainly
>>>>>>>>>>> agree that’s not a blocker, I look
at the archetypes
>>>>>>>>>>> same way
>>>>>>>>>>> as the quickstarts, an aggregation
project, so we may
>>>>>>>>>>> take
>>>>>>>>>>> outdated/faulty ones out of build
and release the
>>>>>>>>>>> working+actual ones. We may give it
a thought later if
it
>>>>>>>>>>> makes sense effort wise to update or
drop the
>>>>>>>>>>> subsystem ones,
>>>>>>>>>>> no worries.
>>>>>>>>>>>
>>>>>>>>>>> —E
>>>>>>>>>>>
>>>>>
>>>>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
10:04 p.m.
Hi Wolfgang,
On Tue, Feb 19, 2019 at 3:22 PM Wolfgang Knauf <wolfgang.knauf(a)gmx.de>
wrote:
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?
Having someone working on these would be great! As you can see they haven't
been touched for several years.
The existing ones are so out of date that I think it's reasonable to just
replace them with EE 8 variants.
Note that WF 16 should be released next week, so if you want the latest
that's a better target.
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.
Including the WF version in the archetype name will result in a lot of
archetypes over time, as WF will do a new release each quarter. WDYT about
a version-less name and just tag the repo per release?
I suppose if we pruned versioned archetypes after a while the number of
archetypes wouldn't get too crazy.
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 ;-).
No such thing as a dumb question!
Best regards,
Brian
Best regards
Wolfgang
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1854
days inactive
2102
days old
47 comments
3 participants
participants (3)
-
Brian Stansberry -
Eduardo Martins -
Wolfgang Knauf