From jason.greene at redhat.com Fri Aug 4 12:12:26 2017 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 4 Aug 2017 11:12:26 -0500 Subject: [wildfly-dev] WildFly 11 Beta is Out! / Remaining Schedule Message-ID: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> Last night WildFly 11 Beta1 was released! The announcement with feature highlights is available here: http://wildfly.org/news/2017/08/03/WildFly11-Beta-Released/ Thank you everyone for your many contributions. This is a significant milestone as between Core and Full, WildFly 11 has in total encompassed 2594 completed jira issues, including a number of major architectural improvements and feature additions. As mentioned in the announcement we plan to move to CR1 quickly (~ 2 weeks), and as always, you can see the latest schedule here: https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter Thanks again! -Jason From hbraun at redhat.com Mon Aug 7 03:10:29 2017 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 7 Aug 2017 09:10:29 +0200 Subject: [wildfly-dev] WildFly 11 Beta is Out! / Remaining Schedule In-Reply-To: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> References: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> Message-ID: <19CA654A-5859-401B-9ED8-6F88788279B3@redhat.com> Congrats to all contributors. Great job! Heiko > Am 04.08.2017 um 18:12 schrieb Jason Greene : > > Last night WildFly 11 Beta1 was released! The announcement with feature highlights is available here: > http://wildfly.org/news/2017/08/03/WildFly11-Beta-Released/ > > Thank you everyone for your many contributions. This is a significant milestone as between Core and Full, WildFly 11 has in total encompassed 2594 completed jira issues, including a number of major architectural improvements and feature additions. > > As mentioned in the announcement we plan to move to CR1 quickly (~ 2 weeks), and as always, you can see the latest schedule here: > > https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter > > Thanks again! > > -Jason > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From vtunka at redhat.com Mon Aug 7 08:13:09 2017 From: vtunka at redhat.com (Vaclav Tunka) Date: Mon, 7 Aug 2017 14:13:09 +0200 Subject: [wildfly-dev] WildFly 11 Beta is Out! / Remaining Schedule In-Reply-To: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> References: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> Message-ID: <600779ec-56c6-0ac1-b8a5-0d9ee2fe254c@redhat.com> Thanks everyone who contributed to this release, great job! Vaclav On 08/04/2017 06:12 PM, Jason Greene wrote: > Last night WildFly 11 Beta1 was released! The announcement with feature highlights is available here: > http://wildfly.org/news/2017/08/03/WildFly11-Beta-Released/ > > Thank you everyone for your many contributions. This is a significant milestone as between Core and Full, WildFly 11 has in total encompassed 2594 completed jira issues, including a number of major architectural improvements and feature additions. > > As mentioned in the announcement we plan to move to CR1 quickly (~ 2 weeks), and as always, you can see the latest schedule here: > > https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter > > Thanks again! > > -Jason > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From anilsaldhana at gmail.com Mon Aug 7 09:22:35 2017 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Mon, 7 Aug 2017 08:22:35 -0500 Subject: [wildfly-dev] WildFly 11 Beta is Out! / Remaining Schedule In-Reply-To: <600779ec-56c6-0ac1-b8a5-0d9ee2fe254c@redhat.com> References: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> <600779ec-56c6-0ac1-b8a5-0d9ee2fe254c@redhat.com> Message-ID: <7F3EB5AF-F003-4A43-92A1-798F18333037@gmail.com> Great contribution by everyone. Congratulations. > On Aug 7, 2017, at 7:13 AM, Vaclav Tunka wrote: > > Thanks everyone who contributed to this release, great job! > > Vaclav > > >> On 08/04/2017 06:12 PM, Jason Greene wrote: >> Last night WildFly 11 Beta1 was released! The announcement with feature highlights is available here: >> http://wildfly.org/news/2017/08/03/WildFly11-Beta-Released/ >> >> Thank you everyone for your many contributions. This is a significant milestone as between Core and Full, WildFly 11 has in total encompassed 2594 completed jira issues, including a number of major architectural improvements and feature additions. >> >> As mentioned in the announcement we plan to move to CR1 quickly (~ 2 weeks), and as always, you can see the latest schedule here: >> >> https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter >> >> Thanks again! >> >> -Jason >> >> >> _______________________________________________ >> 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 From anmiller at redhat.com Mon Aug 7 09:59:53 2017 From: anmiller at redhat.com (Andrig Miller) Date: Mon, 7 Aug 2017 07:59:53 -0600 Subject: [wildfly-dev] WildFly 11 Beta is Out! / Remaining Schedule In-Reply-To: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> References: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> Message-ID: Congratulations to the entire team. Andy On Fri, Aug 4, 2017 at 10:12 AM, Jason Greene wrote: > Last night WildFly 11 Beta1 was released! The announcement with feature > highlights is available here: > http://wildfly.org/news/2017/08/03/WildFly11-Beta-Released/ > > Thank you everyone for your many contributions. This is a significant > milestone as between Core and Full, WildFly 11 has in total encompassed > 2594 completed jira issues, including a number of major architectural > improvements and feature additions. > > As mentioned in the announcement we plan to move to CR1 quickly (~ 2 > weeks), and as always, you can see the latest schedule here: > > https://issues.jboss.org/projects/WFLY?selectedItem= > com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter > > Thanks again! > > -Jason > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170807/906327d9/attachment.html From tomaz.cerar at gmail.com Mon Aug 7 17:36:58 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 7 Aug 2017 23:36:58 +0200 Subject: [wildfly-dev] WildFly 11 Beta is Out! / Remaining Schedule In-Reply-To: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> References: <8438489C-F8C8-429F-8E92-C45A2D6BE1E3@redhat.com> Message-ID: As an add-on to the WildFly 11 Beta1 release, we have also released accompanying quickstarts which can be found at https://github.com/wildfly/quickstart/releases/tag/11.0.0.Beta1 This marks first release made after we completely changed QS development process, which now allows as to do much more rapid releases and have "always stable" and up-to-date QS Please give it a try and if you find any issues, please let us know. -- tomaz On Fri, Aug 4, 2017 at 6:12 PM, Jason Greene wrote: > Last night WildFly 11 Beta1 was released! The announcement with feature > highlights is available here: > http://wildfly.org/news/2017/08/03/WildFly11-Beta-Released/ > > Thank you everyone for your many contributions. This is a significant > milestone as between Core and Full, WildFly 11 has in total encompassed > 2594 completed jira issues, including a number of major architectural > improvements and feature additions. > > As mentioned in the announcement we plan to move to CR1 quickly (~ 2 > weeks), and as always, you can see the latest schedule here: > > https://issues.jboss.org/projects/WFLY?selectedItem= > com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter > > Thanks again! > > -Jason > > > _______________________________________________ > 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/20170807/26b62f7a/attachment.html From rory.odonnell at oracle.com Tue Aug 8 06:08:33 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 8 Aug 2017 11:08:33 +0100 Subject: [wildfly-dev] Ready for JDK 9 ? Message-ID: Hi Jason/Tomaz, Thank you very much for all your testing of JDK 9 during its development! Such contributions have significantly helped shape and improve JDK 9. Now that we have reached the JDK 9 Final Release Candidate phase [1] , I would like to ask if your project can be considered to be 'ready for JDK 9', or if there are any remaining show stopper issues which you've encountered when testing with the JDK 9 release candidate. JDK 9 b181 is available at http://jdk.java.net/9/ If you have a public web page, mailing list post, or even a tweet announcing you project's readiness for JDK 9, I'd love to add the URL to the upcoming JDK 9 readiness page on the Quality Outreach wiki. Looking forward to hearing from you, Rory [1] http://openjdk.java.net/projects/jdk9/ -- 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/20170808/fbd7d0fe/attachment.html From sanne at hibernate.org Fri Aug 11 17:43:27 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 11 Aug 2017 22:43:27 +0100 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro Message-ID: Hi all, I just noticed that the Apache Avro version included in WildFly was upgraded to 1.8.1. This breaks Hibernate Search. It wasn't caught by automated integration tests as this aspect wasn't covered by integration tests within the wildfly codebase - we have them within Hibernate. A quick grep on the module definitions doesn't reveal any other user, and "git blame" seems to suggest it was updated just for the sake of updating some components.. so I'm guessing there is no other stackeholder I should align with? 1# Could we please revert it to 1.7.6, which is what Hibernate Search requires? Alternatively we'll need some ad-hoc coding on Hibernate Search and a new version respin - with all associated risks - just for the sake of updating this. 2# What can we do to prevent such things in the future? I can of course contribute some more integration tests but it's never going to be enough: there will always be more tests "upstream". Could we rather agree on some improved communication process when you all consider updating an indirect dependency? Thanks, Sanne - https://issues.jboss.org/browse/WFLY-9221 From jperkins at redhat.com Fri Aug 11 20:08:17 2017 From: jperkins at redhat.com (James Perkins) Date: Fri, 11 Aug 2017 17:08:17 -0700 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: References: Message-ID: It looks like it came in as part of https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of these sweeping version updates like this for this exact reason. We've had issues with this type of thing before and I do think we need a better approach. IMO we can definitely downgrade this. I also see no other modules that depend on it either. On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero wrote: > Hi all, > > I just noticed that the Apache Avro version included in WildFly was > upgraded to 1.8.1. > > This breaks Hibernate Search. It wasn't caught by automated > integration tests as this aspect wasn't covered by integration tests > within the wildfly codebase - we have them within Hibernate. > > A quick grep on the module definitions doesn't reveal any other user, > and "git blame" seems to suggest it was updated just for the sake of > updating some components.. so I'm guessing there is no other > stackeholder I should align with? > > 1# Could we please revert it to 1.7.6, which is what Hibernate Search > requires? > > Alternatively we'll need some ad-hoc coding on Hibernate Search and a > new version respin - with all associated risks - just for the sake of > updating this. > > 2# What can we do to prevent such things in the future? > > I can of course contribute some more integration tests but it's never > going to be enough: there will always be more tests "upstream". Could > we rather agree on some improved communication process when you all > consider updating an indirect dependency? > > Thanks, > Sanne > > - https://issues.jboss.org/browse/WFLY-9221 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170811/f005d44c/attachment.html From sanne at hibernate.org Sat Aug 12 05:44:16 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 12 Aug 2017 10:44:16 +0100 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: References: Message-ID: Thanks James! I've sent a PR to restore the previous version. I'll be checking some more cross-project dependency requirements next weeek. On 12 August 2017 at 01:08, James Perkins wrote: > It looks like it came in as part of > https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of > these sweeping version updates like this for this exact reason. We've had > issues with this type of thing before and I do think we need a better > approach. > > IMO we can definitely downgrade this. I also see no other modules that > depend on it either. > > On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero > wrote: >> >> Hi all, >> >> I just noticed that the Apache Avro version included in WildFly was >> upgraded to 1.8.1. >> >> This breaks Hibernate Search. It wasn't caught by automated >> integration tests as this aspect wasn't covered by integration tests >> within the wildfly codebase - we have them within Hibernate. >> >> A quick grep on the module definitions doesn't reveal any other user, >> and "git blame" seems to suggest it was updated just for the sake of >> updating some components.. so I'm guessing there is no other >> stackeholder I should align with? >> >> 1# Could we please revert it to 1.7.6, which is what Hibernate Search >> requires? >> >> Alternatively we'll need some ad-hoc coding on Hibernate Search and a >> new version respin - with all associated risks - just for the sake of >> updating this. >> >> 2# What can we do to prevent such things in the future? >> >> I can of course contribute some more integration tests but it's never >> going to be enough: there will always be more tests "upstream". Could >> we rather agree on some improved communication process when you all >> consider updating an indirect dependency? >> >> Thanks, >> Sanne >> >> - https://issues.jboss.org/browse/WFLY-9221 >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat From cdewolf at redhat.com Mon Aug 14 04:00:42 2017 From: cdewolf at redhat.com (Carlo de Wolf) Date: Mon, 14 Aug 2017 10:00:42 +0200 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: References: Message-ID: <7a6f3b64-82c6-5266-6bea-3914382b5f18@redhat.com> These form of conflicts must be guarded in a test(suite) that is part of WildFly release criteria. Carlo On 08/12/2017 11:44 AM, Sanne Grinovero wrote: > Thanks James! I've sent a PR to restore the previous version. > > I'll be checking some more cross-project dependency requirements next weeek. > > On 12 August 2017 at 01:08, James Perkins wrote: >> It looks like it came in as part of >> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of >> these sweeping version updates like this for this exact reason. We've had >> issues with this type of thing before and I do think we need a better >> approach. >> >> IMO we can definitely downgrade this. I also see no other modules that >> depend on it either. >> >> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero >> wrote: >>> Hi all, >>> >>> I just noticed that the Apache Avro version included in WildFly was >>> upgraded to 1.8.1. >>> >>> This breaks Hibernate Search. It wasn't caught by automated >>> integration tests as this aspect wasn't covered by integration tests >>> within the wildfly codebase - we have them within Hibernate. >>> >>> A quick grep on the module definitions doesn't reveal any other user, >>> and "git blame" seems to suggest it was updated just for the sake of >>> updating some components.. so I'm guessing there is no other >>> stackeholder I should align with? >>> >>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search >>> requires? >>> >>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a >>> new version respin - with all associated risks - just for the sake of >>> updating this. >>> >>> 2# What can we do to prevent such things in the future? >>> >>> I can of course contribute some more integration tests but it's never >>> going to be enough: there will always be more tests "upstream". Could >>> we rather agree on some improved communication process when you all >>> consider updating an indirect dependency? >>> >>> Thanks, >>> Sanne >>> >>> - https://issues.jboss.org/browse/WFLY-9221 >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From jperkins at redhat.com Mon Aug 14 10:48:32 2017 From: jperkins at redhat.com (James Perkins) Date: Mon, 14 Aug 2017 07:48:32 -0700 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: <7a6f3b64-82c6-5266-6bea-3914382b5f18@redhat.com> References: <7a6f3b64-82c6-5266-6bea-3914382b5f18@redhat.com> Message-ID: There's no way we can have tests for every feature that every project brings into WildFly. On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf wrote: > These form of conflicts must be guarded in a test(suite) that is part of > WildFly release criteria. > > Carlo > > > On 08/12/2017 11:44 AM, Sanne Grinovero wrote: > >> Thanks James! I've sent a PR to restore the previous version. >> >> I'll be checking some more cross-project dependency requirements next >> weeek. >> >> On 12 August 2017 at 01:08, James Perkins wrote: >> >>> It looks like it came in as part of >>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan >>> of >>> these sweeping version updates like this for this exact reason. We've had >>> issues with this type of thing before and I do think we need a better >>> approach. >>> >>> IMO we can definitely downgrade this. I also see no other modules that >>> depend on it either. >>> >>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero >>> wrote: >>> >>>> Hi all, >>>> >>>> I just noticed that the Apache Avro version included in WildFly was >>>> upgraded to 1.8.1. >>>> >>>> This breaks Hibernate Search. It wasn't caught by automated >>>> integration tests as this aspect wasn't covered by integration tests >>>> within the wildfly codebase - we have them within Hibernate. >>>> >>>> A quick grep on the module definitions doesn't reveal any other user, >>>> and "git blame" seems to suggest it was updated just for the sake of >>>> updating some components.. so I'm guessing there is no other >>>> stackeholder I should align with? >>>> >>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search >>>> requires? >>>> >>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a >>>> new version respin - with all associated risks - just for the sake of >>>> updating this. >>>> >>>> 2# What can we do to prevent such things in the future? >>>> >>>> I can of course contribute some more integration tests but it's never >>>> going to be enough: there will always be more tests "upstream". Could >>>> we rather agree on some improved communication process when you all >>>> consider updating an indirect dependency? >>>> >>>> Thanks, >>>> Sanne >>>> >>>> - https://issues.jboss.org/browse/WFLY-9221 >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170814/dd812750/attachment.html From sanne at hibernate.org Mon Aug 14 11:24:21 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 14 Aug 2017 16:24:21 +0100 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: References: <7a6f3b64-82c6-5266-6bea-3914382b5f18@redhat.com> Message-ID: On 14 August 2017 at 15:48, James Perkins wrote: > There's no way we can have tests for every feature that every project brings > into WildFly. Indeed: we could add some more tests, but there's a practical limit; the combined Hibernate projects would potentially contribute some ~8000 additional tests - but that's also adding some 3 hours testing to each build, which doesn't scale. You might want to hand-pick some strategical ones covering integration, but such a manual selection is bound to be out of date in no time. On the other hand Carlo make a good point: the need to make sure such things don't happen again. I suspect the solution is to be found in some evolution of the "feature packs" concept. The primary problem is that in upstream (Hibernate projects) we pick our own dependencies and build our own modules. This same structure is then replicated in WildFly, but the structure of the modules and the versions are just crafted by humans to look like the same - which introduces the need for us to "watch" what you're all changing, as versions could drift apart, to the point of not actually working correctly in some cases. We need to make sure that the very same combination of module definitions and dependencies that we use to test upstream is incorporater verbatim into WildFly. That would be a reliable solution, and without the need to expand on the testsuite dimensions - neither code (maintenance) nor build times. It would also avoid you all needing to install the 30+ RDBMS vendors & versions we support to actually run all those tests. Toma? had kindly contributed a prototype for Hibernate Search to publish feature packs, and I loved the idea as it addresses such problems, but then we failed to find a consensus about how this would work. I'm still looking forward to hear some clarification on such plans: - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html Thanks, Sanne > On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf wrote: >> >> These form of conflicts must be guarded in a test(suite) that is part of >> WildFly release criteria. >> >> Carlo >> >> >> On 08/12/2017 11:44 AM, Sanne Grinovero wrote: >>> >>> Thanks James! I've sent a PR to restore the previous version. >>> >>> I'll be checking some more cross-project dependency requirements next >>> weeek. >>> >>> On 12 August 2017 at 01:08, James Perkins wrote: >>>> >>>> It looks like it came in as part of >>>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan >>>> of >>>> these sweeping version updates like this for this exact reason. We've >>>> had >>>> issues with this type of thing before and I do think we need a better >>>> approach. >>>> >>>> IMO we can definitely downgrade this. I also see no other modules that >>>> depend on it either. >>>> >>>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I just noticed that the Apache Avro version included in WildFly was >>>>> upgraded to 1.8.1. >>>>> >>>>> This breaks Hibernate Search. It wasn't caught by automated >>>>> integration tests as this aspect wasn't covered by integration tests >>>>> within the wildfly codebase - we have them within Hibernate. >>>>> >>>>> A quick grep on the module definitions doesn't reveal any other user, >>>>> and "git blame" seems to suggest it was updated just for the sake of >>>>> updating some components.. so I'm guessing there is no other >>>>> stackeholder I should align with? >>>>> >>>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search >>>>> requires? >>>>> >>>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a >>>>> new version respin - with all associated risks - just for the sake of >>>>> updating this. >>>>> >>>>> 2# What can we do to prevent such things in the future? >>>>> >>>>> I can of course contribute some more integration tests but it's never >>>>> going to be enough: there will always be more tests "upstream". Could >>>>> we rather agree on some improved communication process when you all >>>>> consider updating an indirect dependency? >>>>> >>>>> Thanks, >>>>> Sanne >>>>> >>>>> - https://issues.jboss.org/browse/WFLY-9221 >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> >>>> >>>> -- >>>> James R. Perkins >>>> JBoss by Red Hat >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> > > > > -- > James R. Perkins > JBoss by Red Hat From cdewolf at redhat.com Tue Aug 15 03:17:13 2017 From: cdewolf at redhat.com (Carlo de Wolf) Date: Tue, 15 Aug 2017 09:17:13 +0200 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: References: <7a6f3b64-82c6-5266-6bea-3914382b5f18@redhat.com> Message-ID: That would be no different than a project provisioning the runtime. At which point the project can do whatever tests they see fit to ensure final integration into the product. Tie to this component upgrades being dictated from down the lines of dependencies instead of coming from above and I think you would have all bases covered. Carlo On 08/14/2017 05:24 PM, Sanne Grinovero wrote: > On 14 August 2017 at 15:48, James Perkins wrote: >> There's no way we can have tests for every feature that every project brings >> into WildFly. > Indeed: we could add some more tests, but there's a practical limit; > the combined Hibernate projects would potentially contribute some > ~8000 additional tests - but that's also adding some 3 hours testing > to each build, which doesn't scale. > You might want to hand-pick some strategical ones covering > integration, but such a manual selection is bound to be out of date in > no time. > > On the other hand Carlo make a good point: the need to make sure such > things don't happen again. > > I suspect the solution is to be found in some evolution of the > "feature packs" concept. The primary problem is that in upstream > (Hibernate projects) we pick our own dependencies and build our own > modules. > This same structure is then replicated in WildFly, but the structure > of the modules and the versions are just crafted by humans to look > like the same - which introduces the need for us to "watch" what > you're all changing, as versions could drift apart, to the point of > not actually working correctly in some cases. > We need to make sure that the very same combination of module > definitions and dependencies that we use to test upstream is > incorporater verbatim into WildFly. > > That would be a reliable solution, and without the need to expand on > the testsuite dimensions - neither code (maintenance) nor build times. > It would also avoid you all needing to install the 30+ RDBMS vendors & > versions we support to actually run all those tests. > > Toma? had kindly contributed a prototype for Hibernate Search to > publish feature packs, and I loved the idea as it addresses such > problems, but then we failed to find a consensus about how this would > work. > I'm still looking forward to hear some clarification on such plans: > - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html > > Thanks, > Sanne > > >> On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf wrote: >>> These form of conflicts must be guarded in a test(suite) that is part of >>> WildFly release criteria. >>> >>> Carlo >>> >>> >>> On 08/12/2017 11:44 AM, Sanne Grinovero wrote: >>>> Thanks James! I've sent a PR to restore the previous version. >>>> >>>> I'll be checking some more cross-project dependency requirements next >>>> weeek. >>>> >>>> On 12 August 2017 at 01:08, James Perkins wrote: >>>>> It looks like it came in as part of >>>>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan >>>>> of >>>>> these sweeping version updates like this for this exact reason. We've >>>>> had >>>>> issues with this type of thing before and I do think we need a better >>>>> approach. >>>>> >>>>> IMO we can definitely downgrade this. I also see no other modules that >>>>> depend on it either. >>>>> >>>>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> I just noticed that the Apache Avro version included in WildFly was >>>>>> upgraded to 1.8.1. >>>>>> >>>>>> This breaks Hibernate Search. It wasn't caught by automated >>>>>> integration tests as this aspect wasn't covered by integration tests >>>>>> within the wildfly codebase - we have them within Hibernate. >>>>>> >>>>>> A quick grep on the module definitions doesn't reveal any other user, >>>>>> and "git blame" seems to suggest it was updated just for the sake of >>>>>> updating some components.. so I'm guessing there is no other >>>>>> stackeholder I should align with? >>>>>> >>>>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search >>>>>> requires? >>>>>> >>>>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a >>>>>> new version respin - with all associated risks - just for the sake of >>>>>> updating this. >>>>>> >>>>>> 2# What can we do to prevent such things in the future? >>>>>> >>>>>> I can of course contribute some more integration tests but it's never >>>>>> going to be enough: there will always be more tests "upstream". Could >>>>>> we rather agree on some improved communication process when you all >>>>>> consider updating an indirect dependency? >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> >>>>>> - https://issues.jboss.org/browse/WFLY-9221 >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> >>>>> -- >>>>> James R. Perkins >>>>> JBoss by Red Hat >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat From sanne at hibernate.org Tue Aug 15 08:12:32 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 15 Aug 2017 13:12:32 +0100 Subject: [wildfly-dev] Version ownership (conflict?): Apache Avro In-Reply-To: References: <7a6f3b64-82c6-5266-6bea-3914382b5f18@redhat.com> Message-ID: On 15 Aug 2017 08:17, "Carlo de Wolf" wrote: That would be no different than a project provisioning the runtime. At which point the project can do whatever tests they see fit to ensure final integration into the product. Tie to this component upgrades being dictated from down the lines of dependencies instead of coming from above and I think you would have all bases covered. +1 that would be awesome. In the Hibernate team we'd be open to volunteer testing such a new process but we're looking forward for directions from the WildFly team... or shall we just move forward with the current notion of feature packs? I heard rumours of someone to experiment with new tools? Please let us know. Thanks Sanne Carlo On 08/14/2017 05:24 PM, Sanne Grinovero wrote: > On 14 August 2017 at 15:48, James Perkins wrote: > >> There's no way we can have tests for every feature that every project >> brings >> into WildFly. >> > Indeed: we could add some more tests, but there's a practical limit; > the combined Hibernate projects would potentially contribute some > ~8000 additional tests - but that's also adding some 3 hours testing > to each build, which doesn't scale. > You might want to hand-pick some strategical ones covering > integration, but such a manual selection is bound to be out of date in > no time. > > On the other hand Carlo make a good point: the need to make sure such > things don't happen again. > > I suspect the solution is to be found in some evolution of the > "feature packs" concept. The primary problem is that in upstream > (Hibernate projects) we pick our own dependencies and build our own > modules. > This same structure is then replicated in WildFly, but the structure > of the modules and the versions are just crafted by humans to look > like the same - which introduces the need for us to "watch" what > you're all changing, as versions could drift apart, to the point of > not actually working correctly in some cases. > We need to make sure that the very same combination of module > definitions and dependencies that we use to test upstream is > incorporater verbatim into WildFly. > > That would be a reliable solution, and without the need to expand on > the testsuite dimensions - neither code (maintenance) nor build times. > It would also avoid you all needing to install the 30+ RDBMS vendors & > versions we support to actually run all those tests. > > Toma? had kindly contributed a prototype for Hibernate Search to > publish feature packs, and I loved the idea as it addresses such > problems, but then we failed to find a consensus about how this would > work. > I'm still looking forward to hear some clarification on such plans: > - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html > > Thanks, > Sanne > > > On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf wrote: >> >>> These form of conflicts must be guarded in a test(suite) that is part of >>> WildFly release criteria. >>> >>> Carlo >>> >>> >>> On 08/12/2017 11:44 AM, Sanne Grinovero wrote: >>> >>>> Thanks James! I've sent a PR to restore the previous version. >>>> >>>> I'll be checking some more cross-project dependency requirements next >>>> weeek. >>>> >>>> On 12 August 2017 at 01:08, James Perkins wrote: >>>> >>>>> It looks like it came in as part of >>>>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big >>>>> fan >>>>> of >>>>> these sweeping version updates like this for this exact reason. We've >>>>> had >>>>> issues with this type of thing before and I do think we need a better >>>>> approach. >>>>> >>>>> IMO we can definitely downgrade this. I also see no other modules that >>>>> depend on it either. >>>>> >>>>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I just noticed that the Apache Avro version included in WildFly was >>>>>> upgraded to 1.8.1. >>>>>> >>>>>> This breaks Hibernate Search. It wasn't caught by automated >>>>>> integration tests as this aspect wasn't covered by integration tests >>>>>> within the wildfly codebase - we have them within Hibernate. >>>>>> >>>>>> A quick grep on the module definitions doesn't reveal any other user, >>>>>> and "git blame" seems to suggest it was updated just for the sake of >>>>>> updating some components.. so I'm guessing there is no other >>>>>> stackeholder I should align with? >>>>>> >>>>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search >>>>>> requires? >>>>>> >>>>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a >>>>>> new version respin - with all associated risks - just for the sake of >>>>>> updating this. >>>>>> >>>>>> 2# What can we do to prevent such things in the future? >>>>>> >>>>>> I can of course contribute some more integration tests but it's never >>>>>> going to be enough: there will always be more tests "upstream". Could >>>>>> we rather agree on some improved communication process when you all >>>>>> consider updating an indirect dependency? >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> >>>>>> - https://issues.jboss.org/browse/WFLY-9221 >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> James R. Perkins >>>>> JBoss by Red Hat >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> >> >> -- >> James R. Perkins >> JBoss by Red Hat >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170815/159d6bf9/attachment.html From tomaz.cerar at gmail.com Thu Aug 31 09:21:50 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 31 Aug 2017 15:21:50 +0200 Subject: [wildfly-dev] WildFly 11 and JDK9 Message-ID: Hey guys, during development of WF11 we have done lots of work on making it build & run on JDK9. as release nears I would like to summarize what the current state is and how to move on. Currently most of our core [1] & full [2] testsuite passes on latest builds of JDK9. Remaining failures are already addressed by [3] and [4] **But** passing testsuite on JDK9 is not the same as using our binary distribution under JDK9. Currently as part of running build / testsuite we override version of javassit to 3.22.0-CR2 which is currently the only version that works properly on JDK9. As there is no .GA version of javassit that work on JDK9 avalible we currently do not have it as default. On top of that, hibernate as main user of javassit is not tested enough with this version of javassist unless hibernate / JPA team says otherwise. That would in practice mean that users running WF11 on JDK9 would have issues with JPA/Hibernate based applications. Currently I see two options how to address this: - upgrade javassist to 3.22.x in server, preferably ask for .GA release. - produce additional WildFly.x.x.x-jdk9 zip that would include the newer javassist. So question is do we even want to have working JDK9 build of WildFly 11 .Final or should we postpone this for next update release. -- tomaz [1] https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea [3] https://github.com/wildfly/wildfly-core/pull/2738 [4] https://github.com/wildfly/wildfly-core/pull/2751 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170831/3620a15b/attachment-0001.html From jason.greene at redhat.com Thu Aug 31 10:54:43 2017 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 31 Aug 2017 09:54:43 -0500 Subject: [wildfly-dev] WildFly 11 and JDK9 In-Reply-To: References: Message-ID: <70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com> I think its probably too late, but I think we can follow up with an 11.1 or 11.0.1 that includes Java 9 fixes. I suspect we probably won?t have everything even if we did update Javassist (still some test failures etc). If someone has a strong argument otherwise, speak now or forever hold your peace! > On Aug 31, 2017, at 8:21 AM, Toma? Cerar wrote: > > Hey guys, > > during development of WF11 we have done lots of work on making it build & run on JDK9. > as release nears I would like to summarize what the current state is and how to move on. > > Currently most of our core [1] & full [2] testsuite passes on latest builds of JDK9. > Remaining failures are already addressed by [3] and [4] > > **But** passing testsuite on JDK9 is not the same as using our binary distribution under JDK9. > > Currently as part of running build / testsuite we override version of javassit to 3.22.0-CR2 > which is currently the only version that works properly on JDK9. > As there is no .GA version of javassit that work on JDK9 avalible we currently do not have it as default. > > On top of that, hibernate as main user of javassit is not tested enough with this version of javassist > unless hibernate / JPA team says otherwise. > > That would in practice mean that users running WF11 on JDK9 would have issues with JPA/Hibernate > based applications. > > Currently I see two options how to address this: > - upgrade javassist to 3.22.x in server, preferably ask for .GA release. > - produce additional WildFly.x.x.x-jdk9 zip that would include the newer javassist. > > So question is do we even want to have working JDK9 build of WildFly 11 .Final > or should we postpone this for next update release. > > -- > tomaz > > > [1] https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 > [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > [3] https://github.com/wildfly/wildfly-core/pull/2738 > [4] https://github.com/wildfly/wildfly-core/pull/2751 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene Chief Architect, JBoss EAP Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170831/cf995933/attachment.html From steve at hibernate.org Thu Aug 31 11:24:05 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 31 Aug 2017 15:24:05 +0000 Subject: [wildfly-dev] WildFly 11 and JDK9 In-Reply-To: <70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com> References: <70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com> Message-ID: I guess we'd have to TIAS. Generally history tells us that these Javassist updates do not go smoothly for Hibernate/WF. However, at least part of purpose of this 3.22 release was for Hibernate and Java 9: https://issues.jboss.org/browse/JASSIST-261 Back then I was able to use those 3.22 snapshots successfully, so hopefully this upgrade should go smoothly. But I agree that I would feel more comfortable with a Final rather than a CR. On Thu, Aug 31, 2017 at 10:14 AM Jason Greene wrote: > I think its probably too late, but I think we can follow up with an 11.1 > or 11.0.1 that includes Java 9 fixes. > > I suspect we probably won?t have everything even if we did update > Javassist (still some test failures etc). > > If someone has a strong argument otherwise, speak now or forever hold your > peace! > > On Aug 31, 2017, at 8:21 AM, Toma? Cerar wrote: > > Hey guys, > > during development of WF11 we have done lots of work on making it build & > run on JDK9. > as release nears I would like to summarize what the current state is and > how to move on. > > Currently most of our core [1] & full [2] testsuite passes on latest > builds of JDK9. > Remaining failures are already addressed by [3] and [4] > > **But** passing testsuite on JDK9 is not the same as using our binary > distribution under JDK9. > > Currently as part of running build / testsuite we override version of > javassit to 3.22.0-CR2 > which is currently the only version that works properly on JDK9. > As there is no .GA version of javassit that work on JDK9 avalible we > currently do not have it as default. > > On top of that, hibernate as main user of javassit is not tested enough > with this version of javassist > unless hibernate / JPA team says otherwise. > > That would in practice mean that users running WF11 on JDK9 would have > issues with JPA/Hibernate > based applications. > > Currently I see two options how to address this: > - upgrade javassist to 3.22.x in server, preferably ask for .GA release. > - produce additional WildFly.x.x.x-jdk9 zip that would include the newer > javassist. > > So question is do we even want to have working JDK9 build of WildFly 11 > .Final > or should we postpone this for next update release. > > -- > tomaz > > > [1] > https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 > [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > [3] https://github.com/wildfly/wildfly-core/pull/2738 > [4] https://github.com/wildfly/wildfly-core/pull/2751 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Jason T. Greene > Chief Architect, JBoss EAP > Red Hat > > _______________________________________________ > 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/20170831/bac4c4ac/attachment.html