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

Hi,

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

Best regards

Wolfgang

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

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

a) Deletes whatever is in src/main/resources/archetypes.

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

c) Does some text replacement.

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

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

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

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

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

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

Brian Stansberry

Manager, Senior Principal Software Engineer

Red Hat