Re: [wildfly-dev] Updating the WildFly archetypes

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