From kkhan at redhat.com Fri Feb 8 10:04:00 2019 From: kkhan at redhat.com (Kabir Khan) Date: Fri, 8 Feb 2019 16:04:00 +0100 Subject: [wildfly-dev] Missing transformer tests Message-ID: TL;DR: It looks like we may be missing transformer tests in the following subsystems: ejb3, infinispan, jca, logging, undertow. I've not dug in beyond that. Full: We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing WF14) for transformer testing until EAP 7.2.0 was released. [1] renames this to be EAP_7_2_0 and points to EAP 7.2.0. In addition I have some WIP to update the full mixed domain and subsystem tests to do the same. When doing this I noticed that the only subsystem that had transformer tests referencing EAP_7_2_0_TEMP was modcluster. I knew messaging-activemq had some changes, which Emmanuel is looking at. I've run the model comparison tool against master/7.2.0: and see changes which might be significant: ====== Resource root address: ["subsystem" => "ejb3"] - Current version: 0.0.0; legacy version: 5.0.0 ======= --- Problems for relative address to root ["passivation-store" => "*"]: Different 'access-type' for attribute 'bean-cache'. Current: "read-write"; legacy: "read-only" Different 'access-type' for attribute 'cache-container'. Current: "read-write"; legacy: "read-only" ====== Resource root address: ["subsystem" => "infinispan"] - Current version: 0.0.0; legacy version: 8.0.0 ======= * --- Problems for relative address to root ["remote-cache-container" => "*"]: Different 'default' for attribute 'protocol-version'. Current: "2.9"; legacy: "2.8" ====== Resource root address: ["subsystem" => "jca"] - Current version: 0.0.0; legacy version: 5.0.0 ======= --- Problems for relative address to root ["distributed-workmanager" => "*","long-running-threads" => "*"]: * Missing attributes in current: [handoff-executor]; missing in legacy [] * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy [] --- Problems for relative address to root ["distributed-workmanager" => "*","short-running-threads" => "*"]: * Missing attributes in current: [handoff-executor]; missing in legacy [] * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy [] --- Problems for relative address to root ["workmanager" => "*","long-running-threads" => "*"]: * Missing attributes in current: [handoff-executor]; missing in legacy [] * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy [] --- Problems for relative address to root ["workmanager" => "*","short-running-threads" => "*"]: * Missing attributes in current: [handoff-executor]; missing in legacy [] * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy [] --- Problems for relative address to root ["workmanager" => "default","long-running-threads" => "*"]: * Missing attributes in current: [handoff-executor]; missing in legacy [] * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy [] --- Problems for relative address to root ["workmanager" => "default","short-running-threads" => "*"]: * Missing attributes in current: [handoff-executor]; missing in legacy [] * Missing parameters for operation 'add' in current: [handoff-executor]; missing in legacy [] ====== Resource root address: ["subsystem" => "logging"] - Current version: 0.0.0; legacy version: 7.0.0 ======= * --- Problems for relative address to root ["json-formatter" => "*"]: Different 'default' for attribute 'record-delimiter'. Current: " "; legacy: "" * --- Problems for relative address to root ["logging-profile" => "*","json-formatter" => "*"]: Different 'default' for attribute 'record-delimiter'. Current: " "; legacy: "" * --- Problems for relative address to root ["logging-profile" => "*","xml-formatter" => "*"]: Different 'default' for attribute 'record-delimiter'. Current: " "; legacy: "" * --- Problems for relative address to root ["xml-formatter" => "*"]: Different 'default' for attribute 'record-delimiter'. Current: " "; legacy: "" ====== Resource root address: ["subsystem" => "undertow"] - Current version: 0.0.0; legacy version: 7.0.0 ======= --- Problems for relative address to root ["application-security-domain" => "*"]: * Missing attributes in current: []; missing in legacy [enable-jaspi, integrated-jaspi] * Missing parameters for operation 'add' in current: []; missing in legacy [enable-jaspi, integrated-jaspi] Although WF16 doesn't provide any domain mode guarantees for previous releases, this will one day end up as a product release and then it is important that we have these tests in place. It is easier to add them as we go along than to retrofit them when that time comes. Thanks, Kabir [1] https://github.com/wildfly/wildfly-core/pull/3664 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190208/8dfc5f3c/attachment.html From brian.stansberry at redhat.com Fri Feb 8 10:33:18 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 8 Feb 2019 09:33:18 -0600 Subject: [wildfly-dev] Missing transformer tests In-Reply-To: References: Message-ID: On Fri, Feb 8, 2019 at 9:07 AM Kabir Khan wrote: > TL;DR: It looks like we may be missing transformer tests in the following > subsystems: ejb3, infinispan, jca, logging, undertow. I've not dug in > beyond that. > > Full: > We have been using ModelTestControllerVersion.EAP_7_2_0_TEMP (containing > WF14) for transformer testing until EAP 7.2.0 was released. [1] renames > this to be EAP_7_2_0 and points to EAP 7.2.0. > > In addition I have some WIP to update the full mixed domain and subsystem > tests to do the same. When doing this I noticed that the only subsystem > that had transformer tests referencing EAP_7_2_0_TEMP was modcluster. I > knew messaging-activemq had some changes, which Emmanuel is looking at. > > I've run the model comparison tool against master/7.2.0: and see changes > which might be significant: > > ====== Resource root address: ["subsystem" => "ejb3"] - Current version: > 0.0.0; legacy version: 5.0.0 ======= > --- Problems for relative address to root ["passivation-store" => "*"]: > Different 'access-type' for attribute 'bean-cache'. Current: "read-write"; > legacy: "read-only" > Different 'access-type' for attribute 'cache-container'. Current: > "read-write"; legacy: "read-only" > > ====== Resource root address: ["subsystem" => "infinispan"] - Current > version: 0.0.0; legacy version: 8.0.0 ======= > * --- Problems for relative address to root ["remote-cache-container" => > "*"]: > Different 'default' for attribute 'protocol-version'. Current: "2.9"; > legacy: "2.8" > > > ====== Resource root address: ["subsystem" => "jca"] - Current version: > 0.0.0; legacy version: 5.0.0 ======= > --- Problems for relative address to root ["distributed-workmanager" => > "*","long-running-threads" => "*"]: > * Missing attributes in current: [handoff-executor]; missing in legacy [] > * Missing parameters for operation 'add' in current: [handoff-executor]; > missing in legacy [] > --- Problems for relative address to root ["distributed-workmanager" => > "*","short-running-threads" => "*"]: > * Missing attributes in current: [handoff-executor]; missing in legacy [] > * Missing parameters for operation 'add' in current: [handoff-executor]; > missing in legacy [] > --- Problems for relative address to root ["workmanager" => > "*","long-running-threads" => "*"]: > * Missing attributes in current: [handoff-executor]; missing in legacy [] > * Missing parameters for operation 'add' in current: [handoff-executor]; > missing in legacy [] > --- Problems for relative address to root ["workmanager" => > "*","short-running-threads" => "*"]: > * Missing attributes in current: [handoff-executor]; missing in legacy [] > * Missing parameters for operation 'add' in current: [handoff-executor]; > missing in legacy [] > --- Problems for relative address to root ["workmanager" => > "default","long-running-threads" => "*"]: > * Missing attributes in current: [handoff-executor]; missing in legacy [] > * Missing parameters for operation 'add' in current: [handoff-executor]; > missing in legacy [] > --- Problems for relative address to root ["workmanager" => > "default","short-running-threads" => "*"]: > * Missing attributes in current: [handoff-executor]; missing in legacy [] > * Missing parameters for operation 'add' in current: [handoff-executor]; > missing in legacy [] > > > ====== Resource root address: ["subsystem" => "logging"] - Current > version: 0.0.0; legacy version: 7.0.0 ======= > * --- Problems for relative address to root ["json-formatter" => "*"]: > Different 'default' for attribute 'record-delimiter'. Current: " > "; legacy: "" > * --- Problems for relative address to root ["logging-profile" => > "*","json-formatter" => "*"]: > Different 'default' for attribute 'record-delimiter'. Current: " > "; legacy: "" > * --- Problems for relative address to root ["logging-profile" => > "*","xml-formatter" => "*"]: > Different 'default' for attribute 'record-delimiter'. Current: " > "; legacy: "" > * --- Problems for relative address to root ["xml-formatter" => "*"]: > Different 'default' for attribute 'record-delimiter'. Current: " > "; legacy: "" > > > ====== Resource root address: ["subsystem" => "undertow"] - Current > version: 0.0.0; legacy version: 7.0.0 ======= > --- Problems for relative address to root ["application-security-domain" > => "*"]: > * Missing attributes in current: []; missing in legacy [enable-jaspi, > integrated-jaspi] > * Missing parameters for operation 'add' in current: []; missing in legacy > [enable-jaspi, integrated-jaspi] > > Although WF16 doesn't provide any domain mode guarantees for previous > releases, this will one day end up as a product release and then it is > important that we have these tests in place. It is easier to add them as we > go along than to retrofit them when that time comes. > Thanks, Kabir for running the check and for the heads up! This needs to be correct in WildFly regardless of any EAP requirements. I believe the domain mode transformation chain from WF 14 all the way back to at least 11 is correct. There is no reason it shouldn't be extended to 16. Even though any fix would only come in 16, the correct way to write the transformation for something that changed in 15 is as if it had been done in 15. Write the transformation code for 15 -> 14 (constants, method names etc) and then if there are further changes for 16 -> 15, do those. Let future readers of the code read code that reflects the history of the management API. > > Thanks, > > Kabir > > > > [1] https://github.com/wildfly/wildfly-core/pull/3664 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190208/d2839f2a/attachment-0001.html From yborgess at redhat.com Mon Feb 11 05:31:55 2019 From: yborgess at redhat.com (Yeray Borges) Date: Mon, 11 Feb 2019 10:31:55 +0000 Subject: [wildfly-dev] Any uses of org.jboss.metadata?, We are planning to remove it. Message-ID: <0999bb88-13b2-61ee-7af6-8e2b103a6a86@redhat.com> Hello everyone, We are planning to remove completely the private module org.jboss.metadata from wildfly [1]. So, we are asking in order to know if there any direct uses of this module outside of Widfly, and/or if you have any objections regarding this change. Regards. [1] https://issues.jboss.org/browse/WFLY-11679 From rory.odonnell at oracle.com Mon Feb 18 06:07:43 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 18 Feb 2019 11:07:43 +0000 Subject: [wildfly-dev] JDK 12: First Release Candidate available Message-ID: <6e346ca6-1cc4-4d6f-0ecd-588458d8cc33@oracle.com> ? Hi David & Richard,* * **OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at : - jdk.java.net/12/* **JDK 12:? First Release Candidate [1]** * Per the JDK 12 schedule [2], we are now in Release Candidate Phase. * The stabilization repository, jdk/jdk12, is open for P1 bug fixes per the JDK Release Process (JEP 3) [3]. * All changes require approval via the Fix-Request Process [4]. * Release note additions since last email o Build 31 - can_pop_frame and can_force_early_return capabilities are disabled if JVMCI compiler is used (JDK-8218025 ) The JVMTI |can_pop_frame| and |can_force_early_return| capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (|PopFrame| and |ForceEarlyReturnXXX| functions) is not available to JVMTI agents. This issue is being fixed via JDK-8218885 [https://bugs.openjdk.java.net/browse/JDK-8218885 ]. o Build 28: JDK-8212233 : javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module." * Changes in this build. **OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the o GNU General Public License, version?2, with the Classpath Exception . * Release Notes updates * Build 8 o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() are unified across the platforms (JDK-8214918 ) o The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider. (JDK-8217835 ) * Build 7 o Change DOM parser to not resolve EntityReference and add Text node with DocumentBuilderFactory.setExpandEntityReferences(false) (JDK-8206132 ) * Build 6 o Base64.Encoder and Base64.Decoder methods can throw OutOfMemoryError (JDK-8210583 ) * Changes in this build * FOSS Bugs fixed in recent builds o Build 6 : JDK-8216970 : condy causes JVM crash o Build 7: JDK-8215577 : Remove javadoc support for HTML 4 Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html [2] http://openjdk.java.net/projects/jdk/12/#Schedule [3] http://openjdk.java.net/jeps/3 [4] http://openjdk.java.net/jeps/3#Fix-Request-Process -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190218/afd1e8d4/attachment.html From ropalka at redhat.com Mon Feb 18 06:40:18 2019 From: ropalka at redhat.com (Richard Opalka) Date: Mon, 18 Feb 2019 12:40:18 +0100 Subject: [wildfly-dev] JDK 12: First Release Candidate available In-Reply-To: <6e346ca6-1cc4-4d6f-0ecd-588458d8cc33@oracle.com> References: <6e346ca6-1cc4-4d6f-0ecd-588458d8cc33@oracle.com> Message-ID: Hi Rory, we're testing JDK12 RC here at Red Hat and it looks good as far as I can tell. Regards, Richard On Mon, Feb 18, 2019 at 12:18 PM Rory O'Donnell wrote: > Hi David & Richard, > > *OpenJDK builds - JDK 12 Early Access build 32 **is now available **at : > - jdk.java.net/12/ * > *JDK 12: First Release Candidate [1]* > > > - Per the JDK 12 schedule [2], we are now in Release Candidate Phase. > - The stabilization repository, jdk/jdk12, is open for P1 bug fixes > per the JDK Release Process (JEP 3) [3]. > - All changes require approval via the Fix-Request Process [4]. > - Release note additions since last email > - Build 31 - can_pop_frame and can_force_early_return capabilities > are disabled if JVMCI compiler is used (JDK-8218025 > ) The JVMTI > can_pop_frame and can_force_early_return capabilities are disabled > if a JVMCI compiler (like Graal) is used. As a result the corresponding > functionality (PopFrame and ForceEarlyReturnXXX functions) is not > available to JVMTI agents. This issue is being fixed via JDK-8218885 > [ > https://bugs.openjdk.java.net/browse/JDK-8218885 > ]. > - Build 28: JDK-8212233 > : javadoc fails > on jdk12 with "The code being documented uses modules but the packages > defined in $URL are in the unnamed module." > - Changes in this build. > > > *OpenJDK builds - JDK 13 Early Access build 8 is **now available **at : > - jdk.java.net/13/ * > > - These early-access, open-source builds are provided under the > - GNU General Public License, version 2, with the Classpath > Exception . > - Release Notes updates > - Build 8 > - GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() are > unified across the platforms (JDK-8214918 > ) > - The experimental FIPS 140 compliant mode has been removed from > the SunJSSE provider. (JDK-8217835 > ) > - Build 7 > - Change DOM parser to not resolve EntityReference and add Text > node with DocumentBuilderFactory.setExpandEntityReferences(false) ( > JDK-8206132 ) > - Build 6 > - Base64.Encoder and Base64.Decoder methods can throw > OutOfMemoryError (JDK-8210583 > ) > - Changes in this build > > - FOSS Bugs fixed in recent builds > - Build 6 : JDK-8216970 > : condy causes > JVM crash > - Build 7: JDK-8215577 > : Remove javadoc > support for HTML 4 > > > > > Rgds,Rory > [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html > [2] http://openjdk.java.net/projects/jdk/12/#Schedule > [3] http://openjdk.java.net/jeps/3 > [4] http://openjdk.java.net/jeps/3#Fix-Request-Process > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- -- Richard Opalka Principal Software Engineer Red Hat JBoss Middleware Mobile: +420 731 186 942 E-mail: ropalka at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190218/ecf8dba5/attachment.html From rory.odonnell at oracle.com Mon Feb 18 06:45:25 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 18 Feb 2019 11:45:25 +0000 Subject: [wildfly-dev] JDK 12: First Release Candidate available In-Reply-To: References: <6e346ca6-1cc4-4d6f-0ecd-588458d8cc33@oracle.com> Message-ID: <9e56a263-880a-7e31-b4ab-64cca05b5a0d@oracle.com> Thanks for the update Richard! Rgds,Rory On 18/02/2019 11:40, Richard Opalka wrote: > Hi Rory, > > ?? we're testing JDK12 RC here at Red Hat and it looks good as far as > I can tell. > > Regards, > > Richard > > On Mon, Feb 18, 2019 at 12:18 PM Rory O'Donnell > > wrote: > > ? Hi David & Richard,* > * > > **OpenJDK builds *- JDK 12 Early Access build 32 **is now > available **at : - jdk.java.net/12/ * > **JDK 12:? First Release Candidate [1]** > > * Per the JDK 12 schedule [2], we are now in Release Candidate > Phase. > * The stabilization repository, jdk/jdk12, is open for P1 bug > fixes per the JDK Release Process (JEP 3) [3]. > * All changes require approval via the Fix-Request Process [4]. > * Release note additions since last email > o Build 31 - can_pop_frame and can_force_early_return > capabilities are disabled if JVMCI compiler is used > (JDK-8218025 > ) The > JVMTI |can_pop_frame| and |can_force_early_return| > capabilities are disabled if a JVMCI compiler (like Graal) > is used. As a result the corresponding functionality > (|PopFrame| and |ForceEarlyReturnXXX| functions) is not > available to JVMTI agents. This issue is being fixed via > JDK-8218885 > > [https://bugs.openjdk.java.net/browse/JDK-8218885 > ]. > o Build 28: JDK-8212233 > : > javadoc fails on jdk12 with "The code being documented > uses modules but the packages defined in $URL are in the > unnamed module." > * Changes in this build. > > > **OpenJDK builds *- JDK 13 Early Access build 8 is **now available > **at : - jdk.java.net/13/ * > > * These early-access, open-source builds are provided under the > o GNU General Public License, version?2, with the Classpath > Exception . > * Release Notes updates > * Build 8 > o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() > are unified across the platforms (JDK-8214918 > ) > o The experimental FIPS 140 compliant mode has been removed > from the SunJSSE provider. (JDK-8217835 > ) > * Build 7 > o Change DOM parser to not resolve EntityReference and add > Text node with > DocumentBuilderFactory.setExpandEntityReferences(false) > (JDK-8206132 > ) > * Build 6 > o Base64.Encoder and Base64.Decoder methods can throw > OutOfMemoryError (JDK-8210583 > ) > * Changes in this build > > * FOSS Bugs fixed in recent builds > o Build 6 : JDK-8216970 > : condy > causes JVM crash > o Build 7: JDK-8215577 > : > Remove javadoc support for HTML 4 > > > Rgds,Rory > > [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html > [2] http://openjdk.java.net/projects/jdk/12/#Schedule > [3] http://openjdk.java.net/jeps/3 > [4] http://openjdk.java.net/jeps/3#Fix-Request-Process > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > -- > Richard Opalka > Principal Software Engineer > Red Hat JBoss Middleware > Mobile: +420 731 186 942 > E-mail: ropalka at redhat.com > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190218/9b9900ed/attachment-0001.html From jperkins at redhat.com Mon Feb 18 11:10:38 2019 From: jperkins at redhat.com (James Perkins) Date: Mon, 18 Feb 2019 08:10:38 -0800 Subject: [wildfly-dev] [WFLY-11031] Add proposal for JSON access logging. Message-ID: Hello All, I've created a proposal [1] for JSON access logging. Any feedback is welcome. [1]: https://github.com/wildfly/wildfly-proposals/pull/176 -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190218/89e7f141/attachment.html From jperkins at redhat.com Mon Feb 18 11:12:10 2019 From: jperkins at redhat.com (James Perkins) Date: Mon, 18 Feb 2019 08:12:10 -0800 Subject: [wildfly-dev] [WFCORE-4332] Proposal for adding a named-formatter attribute to the syslog-handler Message-ID: Hello All, I've created a proposal [1] to add a named-formatter attribute to the syslog-handler. Any feedback is welcome. [1]: https://github.com/wildfly/wildfly-proposals/pull/177 -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190218/f025f2d5/attachment.html From whdrjs1122 at naver.com Mon Feb 18 20:14:13 2019 From: whdrjs1122 at naver.com (=?utf-8?B?7JuQ7KKF6rG0?=) Date: Tue, 19 Feb 2019 10:14:13 +0900 Subject: [wildfly-dev] =?utf-8?q?how_to_redirect_at_wildfly_11_http_to_htt?= =?utf-8?q?ps?= Message-ID: <4fd399ccd8137b31e749869c120b5c4@cweb018.nm.nfra.io> Hi, I'm won. I wonder how to redirect at wildfly 11 http to https. Now, both http and https operating in system. but, If I enter with http, No redirect https. thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190219/d90260dc/attachment.html From wolfgang.knauf at gmx.de Tue Feb 19 16:12:11 2019 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Tue, 19 Feb 2019 22:12:11 +0100 Subject: [wildfly-dev] Updating the WildFly archetypes Message-ID: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> 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 From wolfgang.knauf at gmx.de Wed Feb 20 16:04:34 2019 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Wed, 20 Feb 2019 22:04:34 +0100 Subject: [wildfly-dev] Updating the WildFly archetypes In-Reply-To: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> Message-ID: <582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de> OK, after some digging around: the archetypes are generated based on the "Kitchensink" quickstart. So, actually there should be not much changes to the archetype files itself, just a "rebuild". But currently, a "maven install" for the archetype fails for me. More research needed... Wolfgang Am 19.02.19 um 22:12 schrieb Wolfgang Knauf: > Hi, > > the archetypes at https://github.com/wildfly/wildfly-archetypes > (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for WildFly 8, > and when updating the WildFly version in pom.xmls, a lot of further > changes is required, see https://issues.jboss.org/browse/WFLY-9703 > (which is only part of the changes). > > I am interested in creating new archetypes for WildFly 15. What do you > think? > > My plan is to name them e.g. > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new > archetype version each time a new WildFly major version is released. > > If you are OK with this, I will struggle with my first steps in Git, and > I probably will ask some more or less dumb questions about details ;-). > > Best regards > > Wolfgang > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Thu Feb 21 23:04:39 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Feb 2019 22:04:39 -0600 Subject: [wildfly-dev] Updating the WildFly archetypes In-Reply-To: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> Message-ID: Hi Wolfgang, On Tue, Feb 19, 2019 at 3:22 PM Wolfgang Knauf wrote: > Hi, > > the archetypes at https://github.com/wildfly/wildfly-archetypes > (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for WildFly 8, > and when updating the WildFly version in pom.xmls, a lot of further > changes is required, see https://issues.jboss.org/browse/WFLY-9703 > (which is only part of the changes). > > I am interested in creating new archetypes for WildFly 15. What do you > think? > Having someone working on these would be great! As you can see they haven't been touched for several years. The existing ones are so out of date that I think it's reasonable to just replace them with EE 8 variants. Note that WF 16 should be released next week, so if you want the latest that's a better target. > > My plan is to name them e.g. > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new > archetype version each time a new WildFly major version is released. > Including the WF version in the archetype name will result in a lot of archetypes over time, as WF will do a new release each quarter. WDYT about a version-less name and just tag the repo per release? I suppose if we pruned versioned archetypes after a while the number of archetypes wouldn't get too crazy. > If you are OK with this, I will struggle with my first steps in Git, and > I probably will ask some more or less dumb questions about details ;-). > No such thing as a dumb question! Best regards, Brian > > Best regards > > Wolfgang > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190221/7cd981f8/attachment.html From brian.stansberry at redhat.com Thu Feb 21 23:05:48 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Feb 2019 22:05:48 -0600 Subject: [wildfly-dev] Updating the WildFly archetypes In-Reply-To: <582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de> References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> <582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de> Message-ID: On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf wrote: > OK, after some digging around: the archetypes are generated based on the > "Kitchensink" quickstart. So, actually there should be not much changes > to the archetype files itself, just a "rebuild". But currently, a "maven > install" for the archetype fails for me. More research needed... > > Oops; I missed this post and responded to your first one! Thanks for digging into this! > Wolfgang > > > > Am 19.02.19 um 22:12 schrieb Wolfgang Knauf: > > Hi, > > > > the archetypes at https://github.com/wildfly/wildfly-archetypes > > (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for WildFly 8, > > and when updating the WildFly version in pom.xmls, a lot of further > > changes is required, see https://issues.jboss.org/browse/WFLY-9703 > > (which is only part of the changes). > > > > I am interested in creating new archetypes for WildFly 15. What do you > > think? > > > > My plan is to name them e.g. > > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new > > archetype version each time a new WildFly major version is released. > > > > If you are OK with this, I will struggle with my first steps in Git, and > > I probably will ask some more or less dumb questions about details ;-). > > > > Best regards > > > > Wolfgang > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190221/3354c0fc/attachment-0001.html From wolfgang.knauf at gmx.de Fri Feb 22 16:26:51 2019 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Fri, 22 Feb 2019 22:26:51 +0100 Subject: [wildfly-dev] Updating the WildFly archetypes In-Reply-To: References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> <582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de> Message-ID: 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: org.wildfly.quickstarts quickstart-parent 16.0.0.CR1-SNAPSHOT ../pom.xml ==>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: wildfly-kitchensink 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 with: Am 22.02.19 um 05:05 schrieb Brian Stansberry: > > > On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf > wrote: > > OK, after some digging around: the archetypes are generated based on > the > "Kitchensink" quickstart. So, actually there should be not much changes > to the archetype files itself, just a "rebuild". But currently, a > "maven > install" for the archetype fails for me. More research needed... > > Oops; I missed this post and responded to your first one! Thanks for > digging into this! > > Wolfgang > > > > Am 19.02.19 um 22:12 schrieb Wolfgang Knauf: > > Hi, > > > > the archetypes at https://github.com/wildfly/wildfly-archetypes > >? ? (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for > WildFly 8, > > and when updating the WildFly version in pom.xmls, a lot of further > > changes is required, see https://issues.jboss.org/browse/WFLY-9703 > > (which is only part of the changes). > > > > I am interested in creating new archetypes for WildFly 15. What > do you > > think? > > > > My plan is to name them e.g. > > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new > > archetype version each time a new WildFly major version is released. > > > > If you are OK with this, I will struggle with my first steps in > Git, and > > I probably will ask some more or less dumb questions about > details ;-). > > > > Best regards > > > > Wolfgang > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: archetype_structure.png Type: image/png Size: 13279 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190222/f2908c67/attachment.png From wolfgang.knauf at gmx.de Sun Feb 24 15:02:02 2019 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Sun, 24 Feb 2019 21:02:02 +0100 Subject: [wildfly-dev] Updating the WildFly archetypes In-Reply-To: References: <2c35697c-c08e-9fbc-d824-dd036ec51dce@gmx.de> <582dba4b-d3eb-6b69-d1ea-544043f38c05@gmx.de> Message-ID: 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: > > > ??? > ??????? org.wildfly.quickstarts > ??????? quickstart-parent > ??????? 16.0.0.CR1-SNAPSHOT > ??????? ../pom.xml > ??? > > ==>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: > > wildfly-kitchensink > > 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 > ?? > with: > ?? > > > > > > > Am 22.02.19 um 05:05 schrieb Brian Stansberry: >> >> >> On Wed, Feb 20, 2019 at 3:45 PM Wolfgang Knauf > > wrote: >> >> ??? OK, after some digging around: the archetypes are generated based on >> ??? the >> ??? "Kitchensink" quickstart. So, actually there should be not much >> changes >> ??? to the archetype files itself, just a "rebuild". But currently, a >> ??? "maven >> ??? install" for the archetype fails for me. More research needed... >> >> Oops; I missed this post and responded to your first one! Thanks for >> digging into this! >> >> ??? Wolfgang >> >> >> >> ??? Am 19.02.19 um 22:12 schrieb Wolfgang Knauf: >> ???? > Hi, >> ???? > >> ???? > the archetypes at https://github.com/wildfly/wildfly-archetypes >> ???? >? ? (e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for >> ??? WildFly 8, >> ???? > and when updating the WildFly version in pom.xmls, a lot of >> further >> ???? > changes is required, see https://issues.jboss.org/browse/WFLY-9703 >> ???? > (which is only part of the changes). >> ???? > >> ???? > I am interested in creating new archetypes for WildFly 15. What >> ??? do you >> ???? > think? >> ???? > >> ???? > My plan is to name them e.g. >> ???? > "wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new >> ???? > archetype version each time a new WildFly major version is >> released. >> ???? > >> ???? > If you are OK with this, I will struggle with my first steps in >> ??? Git, and >> ???? > I probably will ask some more or less dumb questions about >> ??? details ;-). >> ???? > >> ???? > Best regards >> ???? > >> ???? > Wolfgang >> ???? > _______________________________________________ >> ???? > wildfly-dev mailing list >> ???? > wildfly-dev at lists.jboss.org >> ???? > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> ???? > >> ??? _______________________________________________ >> ??? wildfly-dev mailing list >> ??? wildfly-dev at lists.jboss.org >> ??? https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat From david.lloyd at redhat.com Wed Feb 27 15:22:38 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 27 Feb 2019 14:22:38 -0600 Subject: [wildfly-dev] FYI: jboss-parent-pom issues are now in GitHub Message-ID: As a reminder, the project is located here: https://github.com/jboss/jboss-parent-pom Please report any lingering issues there, make sure your commits include an issue reference, etc. I'll also be setting up milestones for the releases. Thanks! -- - DML From brian.stansberry at redhat.com Wed Feb 27 15:28:43 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 27 Feb 2019 14:28:43 -0600 Subject: [wildfly-dev] FYI: jboss-parent-pom issues are now in GitHub In-Reply-To: References: Message-ID: Thanks, David! Good call on using github issues for this. On Wed, Feb 27, 2019 at 2:24 PM David Lloyd wrote: > As a reminder, the project is located here: > https://github.com/jboss/jboss-parent-pom > > Please report any lingering issues there, make sure your commits > include an issue reference, etc. I'll also be setting up milestones > for the releases. > > Thanks! > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190227/cb5dc2ec/attachment.html