Updating the WildFly archetypes

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Updating the WildFly archetypes

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Brian Stansberry
In reply to this post by Wolfgang Knauf
Hi Wolfgang,

On Tue, Feb 19, 2019 at 3:22 PM Wolfgang Knauf <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Brian Stansberry
In reply to this post by Wolfgang Knauf


On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
Thanks for the reply, Brian. But before discussing the naming scheme, I
would like to understand the concept of the old archetype creation and
make it work again ;-).

I made some progress on the failing build, but now I reached a point
where the concept "pulling from the kitchensink-ear app" seems to be
broken by design....

To sum it up:

a) in the kitchensink sample, the names of the subdirectories ("ear",
"ejb", "war") have changed. This causes the the archetype build to fail
=> this error is fixable, see below.
But is it intended to provide an archetype with subdirectories "ear",
"ejb" and "war" instead of "myapp-ear", "myapp-ejb" and "myapp-war"? I
prefer the old naming scheme ;-).


b) after fixing this, the archetype test will fail:

[ERROR]   The project foo.bar:multi:[unknown-version]
(C:\Temp\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\target\test-classes\projects\multi\project\multi\pom.xml)
has 1 error
[ERROR]     Non-resolvable parent POM for
foo.bar:multi:[unknown-version]: Could not find artifact
foo.bar:multi:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at
wrong local POM @ line 21, column 13 -> [Help 2]


The reason is the "relativePath" in "....\kitchensink-ear\pom.xml",
which is the root pom in the archetype:


     <parent>
         <groupId>org.wildfly.quickstarts</groupId>
         <artifactId>quickstart-parent</artifactId>
         <version>16.0.0.CR1-SNAPSHOT</version>
         <relativePath>../pom.xml</relativePath>
     </parent>

==>of course this parent file is not found in the generated archetype,
thus it fails. This will make the archetype unusable.

How to resolve this problem? I don't think that it is a good idea to
include all the stuff from the quickstart pom.xml - that's way too much
for any user generated application. Keep it simple ;-).


Best regards

Wolfgang
======================================

And now a detailed analysis of the first problem (broken build because
of renamed directories) - for those who are interested in the details:


When building the "wildfly-javaee7-webapp-ear-archetype", it fails with
this error message:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.1:integration-test
(default-integration-test) on project wildfly-javaee7-webapp-ear-archetype:
[ERROR] Archetype IT 'multi' failed:
org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error
merging velocity templates: Unable to find resource
'archetype-resources/__rootArtifactId__-ejb/pom.xml'


Taking a look at the files: in Git you find the files for the archetype
in the subdir
"wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb"

(https://github.com/wildfly/wildfly-archetypes/tree/master/wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb)
Those files shall be overwritten by the build: they are picked from the
kitchensink sample and converted to a archetype version (with some
placeholders like "${rootArtifactId}").

After the maven build has failed,
"..../archetype-resources/__rootArtifactId__-ejb" contains only empty
directories - all files inside are deleted.
The files that are copied from the kitchensink-ear project are now in
the directories "..../archetype-resources/ear",
".../archetype-resources/ejb", ".../archetype-resources/web".
This is not the place where the tests expect it.

See attached screenshot "archetype_structure.png"



Now about the explanation:
At the time of creation of this archetype project, the "kitchensink-ear"
module had three submodules "wildfly-kitchensink-ear-ear",
"wildfly-kitchensink-ear-ejb" and "wildfly-kitchensink-ear-web".

Here are old sources:
https://github.com/wildfly/quickstart/tree/ed12afad407a2946b85db37bfeec1d2d1dd0201d/kitchensink-ear


In the file
"wildfly-archetypes\wildfly-javaee7-webapp-archetype\pom.xml", there are
defined several archetype replacement rules for the "qstools" plugin.
One is this:
 
<archetypeExpressionReplaceValue>wildfly-kitchensink</archetypeExpressionReplaceValue>
This means: in all path components containing "wildfly-kitchensink" this
will be replaced by "__rootArtifactId__"
E.g. "wildfly-kitchensink-ear-ejb" will become ""__rootArtifactId__ear-ejb"


See source code for the replacements at
https://github.com/jboss-developer/maven-qstools-plugin/blob/master/src/main/java/org/jboss/maven/plugins/qstools/ArchetypeSyncMojo.java


BUT the "kitchensink-ear" module has three submodules "ear", "ejb" and
"web". So, no replacement occurs, and the files are copied to
".../archetype-resources/ejb" instead of
".../archetype-resources/__rootArtifactId__-ejb".


This error is fixable if the file
"...\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\src\main\resources\META-INF\maven\archetype-metadata.xml"
is changed:
replace
    <module id="ejb" dir="__rootArtifactId__-ejb" name="ejb">
with:
    <module id="ejb" dir="ejb" name="ejb">






Am 22.02.19 um 05:05 schrieb Brian Stansberry:

>
>
> On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf <[hidden email]
> <mailto:[hidden email]>> 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

archetype_structure.png (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
About problem b from below: I can think of two possibilities to resolve it:

b.1) modify the qstools class "ArchetypeSyncMojo" so that it merges the
"kitchensink-ear" pom.xml and the quickstart pom into one file.
But I don't like the idea: The quickstarts root pom.xml has 778 lines -
this is way too much overhead for a newly created project. So I prefer...

b.2) creating an archetype from scratch, with only "relevant" snippets
in pom.xml and discard the "copy automatically from kitchensink sample"
code.

What do you think? Or is it possible to split the root pom file for the
quickstart into a bundle of feature sets? It seems maven does not
support this.

Best regards

Wolfgang

Am 22.02.19 um 22:26 schrieb Wolfgang Knauf:

> Thanks for the reply, Brian. But before discussing the naming scheme, I
> would like to understand the concept of the old archetype creation and
> make it work again ;-).
>
> I made some progress on the failing build, but now I reached a point
> where the concept "pulling from the kitchensink-ear app" seems to be
> broken by design....
>
> To sum it up:
>
> a) in the kitchensink sample, the names of the subdirectories ("ear",
> "ejb", "war") have changed. This causes the the archetype build to fail
> => this error is fixable, see below.
> But is it intended to provide an archetype with subdirectories "ear",
> "ejb" and "war" instead of "myapp-ear", "myapp-ejb" and "myapp-war"? I
> prefer the old naming scheme ;-).
>
>
> b) after fixing this, the archetype test will fail:
>
> [ERROR]   The project foo.bar:multi:[unknown-version]
> (C:\Temp\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\target\test-classes\projects\multi\project\multi\pom.xml)
> has 1 error
> [ERROR]     Non-resolvable parent POM for
> foo.bar:multi:[unknown-version]: Could not find artifact
> foo.bar:multi:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at
> wrong local POM @ line 21, column 13 -> [Help 2]
>
>
> The reason is the "relativePath" in "....\kitchensink-ear\pom.xml",
> which is the root pom in the archetype:
>
>
>      <parent>
>          <groupId>org.wildfly.quickstarts</groupId>
>          <artifactId>quickstart-parent</artifactId>
>          <version>16.0.0.CR1-SNAPSHOT</version>
>          <relativePath>../pom.xml</relativePath>
>      </parent>
>
> ==>of course this parent file is not found in the generated archetype,
> thus it fails. This will make the archetype unusable.
>
> How to resolve this problem? I don't think that it is a good idea to
> include all the stuff from the quickstart pom.xml - that's way too much
> for any user generated application. Keep it simple ;-).
>
>
> Best regards
>
> Wolfgang
> ======================================
>
> And now a detailed analysis of the first problem (broken build because
> of renamed directories) - for those who are interested in the details:
>
>
> When building the "wildfly-javaee7-webapp-ear-archetype", it fails with
> this error message:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:2.1:integration-test
> (default-integration-test) on project wildfly-javaee7-webapp-ear-archetype:
> [ERROR] Archetype IT 'multi' failed:
> org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error
> merging velocity templates: Unable to find resource
> 'archetype-resources/__rootArtifactId__-ejb/pom.xml'
>
>
> Taking a look at the files: in Git you find the files for the archetype
> in the subdir
> "wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb"
>
> (https://github.com/wildfly/wildfly-archetypes/tree/master/wildfly-javaee7-webapp-ear-archetype/src/main/resources/archetype-resources/__rootArtifactId__-ejb)
>
> Those files shall be overwritten by the build: they are picked from the
> kitchensink sample and converted to a archetype version (with some
> placeholders like "${rootArtifactId}").
>
> After the maven build has failed,
> "..../archetype-resources/__rootArtifactId__-ejb" contains only empty
> directories - all files inside are deleted.
> The files that are copied from the kitchensink-ear project are now in
> the directories "..../archetype-resources/ear",
> ".../archetype-resources/ejb", ".../archetype-resources/web".
> This is not the place where the tests expect it.
>
> See attached screenshot "archetype_structure.png"
>
>
>
> Now about the explanation:
> At the time of creation of this archetype project, the "kitchensink-ear"
> module had three submodules "wildfly-kitchensink-ear-ear",
> "wildfly-kitchensink-ear-ejb" and "wildfly-kitchensink-ear-web".
>
> Here are old sources:
> https://github.com/wildfly/quickstart/tree/ed12afad407a2946b85db37bfeec1d2d1dd0201d/kitchensink-ear 
>
>
>
> In the file
> "wildfly-archetypes\wildfly-javaee7-webapp-archetype\pom.xml", there are
> defined several archetype replacement rules for the "qstools" plugin.
> One is this:
>
> <archetypeExpressionReplaceValue>wildfly-kitchensink</archetypeExpressionReplaceValue>
>
> This means: in all path components containing "wildfly-kitchensink" this
> will be replaced by "__rootArtifactId__"
> E.g. "wildfly-kitchensink-ear-ejb" will become ""__rootArtifactId__ear-ejb"
>
>
> See source code for the replacements at
> https://github.com/jboss-developer/maven-qstools-plugin/blob/master/src/main/java/org/jboss/maven/plugins/qstools/ArchetypeSyncMojo.java 
>
>
>
> BUT the "kitchensink-ear" module has three submodules "ear", "ejb" and
> "web". So, no replacement occurs, and the files are copied to
> ".../archetype-resources/ejb" instead of
> ".../archetype-resources/__rootArtifactId__-ejb".
>
>
> This error is fixable if the file
> "...\wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\src\main\resources\META-INF\maven\archetype-metadata.xml"
>
> is changed:
> replace
>     <module id="ejb" dir="__rootArtifactId__-ejb" name="ejb">
> with:
>     <module id="ejb" dir="ejb" name="ejb">
>
>
>
>
>
>
> Am 22.02.19 um 05:05 schrieb Brian Stansberry:
>>
>>
>> On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf <[hidden email]
>> <mailto:[hidden email]>> 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
>>      > [hidden email] <mailto:[hidden email]>
>>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>      >
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
Hi,

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

Best regards

Wolfgang

Am 24.02.19 um 21:02 schrieb Wolfgang Knauf:

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

Re: Updating the WildFly archetypes

Brian Stansberry


On Sat, Mar 2, 2019 at 5:58 AM Wolfgang Knauf <[hidden email]> 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?

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


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

snippet_pom.xml (1K) Download Attachment
pom.xml (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

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.

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

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 <[hidden email]
> <mailto:[hidden email]>> 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
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Eduardo Martins-2
In reply to this post by Wolfgang Knauf
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Brian Stansberry


On Tue, Mar 12, 2019 at 2:25 PM Wolfgang Knauf <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Eduardo Martins-2
In reply to this post by Eduardo Martins-2
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 <[hidden email]> wrote:
>
>
> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>
>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
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 <[hidden email]> wrote:
>>
>>
>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>
>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

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

On Mon, 18 Mar 2019 at 21:04, Wolfgang Knauf <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>
>>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >>
>      >>
>      >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>      >>>
>      >>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>     <[hidden email] <mailto:[hidden email]>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating the WildFly archetypes

Wolfgang Knauf
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 <[hidden email]
>>> <mailto:[hidden email]>> 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 <[hidden email]
>>>      <mailto:[hidden email]>> wrote:
>>>       >>
>>>       >>
>>>       >> Am 13.03.19 um 18:25 schrieb Eduardo Martins:
>>>       >>>
>>>       >>>> On 12 Mar 2019, at 19:12, Wolfgang Knauf
>>>      <[hidden email] <mailto:[hidden email]>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12