Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
Hi Fabio, yes good point. Infinispan has been using our feature packs as well, but they are in a similar situation and will have to change strategy. Even if others will need them, we don't have much choice: the existing feature packs won't work with the newer WildFly versions. So we'll keep going with our plan to delete these, and then if there's compelling need for a "Galleon XP" pack to be delivered in the future... we'll seen when the demands materialize. Regarding older WildFly versions which we still support: obviously we're not backporting the removal to any supported branch so older Wildfly versions (and older Infinispan versions) will be able to continue using them. Thanks Sanne On Fri, 17 Apr 2020 at 05:55, Fabio Massimo Ercoli wrote: > Hello, > > I take advantage of the topic to say that there is an `integrationtests` > module in Infinispan too using feature packs, which are usings in turn the > feature packs of the Hibernate Search 5. > I have to ask the ISPN guys on Zulip about that, maybe they have already > planned to remove such modules and maybe we can get rid of them with the > Search 6 integration. > > Thanks, > Fabio > > On Fri, Apr 17, 2020 at 12:26 AM Sanne Grinovero > wrote: > >> We have a PR for this now, if someone would like to have a look: >> - https://github.com/hibernate/hibernate-orm/pull/3347 >> >> One thing to note, is that it also removes all Arquillian based tests: >> we had some which were testing more than just the basics of our >> feature pack; although most had been disabled already for other >> reasons. Sadly even the few useful ones will need to be removed as >> well. >> >> After this, we no longer have Arquillian among the test dependencies >> either... back to basics. >> >> Thanks, >> Sanne >> >> On Thu, 16 Apr 2020 at 16:18, Yoann Rodiere wrote: >> > >> > > Any specific reason you say that Yoann? >> > >> > No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI >> had a high chance of breaking OSGi tests, unless the Jakarta artifacts >> properly support OSGi. >> > >> > But it was just a hunch; if it works, I don't have anything against >> keeping it. >> > >> > >> > Yoann Rodière >> > Hibernate Team >> > yo...@hibernate.org >> > >> > >> > On Thu, 16 Apr 2020 at 16:12, Steve Ebersole >> wrote: >> >> >> >> I do not plan on dropping hibernate-osgi. Its there; it works. Any >> >> specific reason you say that Yoann? >> >> >> >> Brett is the only one to do anything with that "tutorial". Though as >> time >> >> went on its focus was more a way to find problems when the paxexam >> tests >> >> failed - they almost always give useless feedback. If you think >> people are >> >> using it as a tutorial then I agree we should remove it or update it. >> >> Depending whether it still has benefit for troubleshooting I'd actually >> >> just clarify its intent somehow rather removing it. Brett? >> >> >> >> >> >> >> >> On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero >> wrote: >> >> >> >> > Agreed, I'll remove it. Thanks Steve and Yoann! >> >> > >> >> > I'll remove them from 5.5 soon, you can then merge the removal in 6.0 >> >> > or do it differently if that's easier. >> >> > >> >> > This is the JIRA: >> >> > - https://hibernate.atlassian.net/browse/HHH-13952 >> >> > >> >> > Regarding OSGi (which Yoann raised): I agree we shouldn't spend >> >> > significant amounts of time on it, but as long as tests still work >> and >> >> > it doesn't get in the way I'll leave them be. >> >> > I have a related JIRA for OSGi as well: the tutorial is using very >> old >> >> > (unmaintained?) dependency versions, so it will either need to be >> >> > removed (people can always read the older tutorial), or it should be >> >> > updated (and tested). >> >> > I might give it a shot to update it, but I'm afraid it will need a >> >> > full set of Jakarta EE 9 dependencies available as well. >> >> > - https://hibernate.atlassian.net/browse/HHH-13951 >> >> > >> >> > Yoann, great idea about the platform agnostic testrunner. We should >> >> > keep that in mind, hopefully we'll be able to make it happen >> >> > eventually. >> >> > >> >> > Thanks, >> >> > Sanne >> >> > >> >> > >> >> > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole >> wrote: >> >> > > >> >> > > Considering the changes in WildFly, I also think we should just >> drop >> >> > hibernate-orm-modules. >> >> > > >> >> > > For 6.0 I will definitely do this. I also think removing it is >> good for >> >> > 5.5. >> >> > > >> >> > > Not sure it is even worth the hassle for earlier releases however. >> >> > > >> >> > > >> >> > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero < >> sa...@hibernate.org> >> >> > wrote: >> >> > >> >> >> > >> As we're working to upgrade to Jakarta EE 9, our feature packs for >> >> > >> Wildfly are not going to be functional for a while at least. >> >> > >> >> >> > >> Not only do we have to upgrade to JPA 3, but we also need to >> upgrade >> >> > >> our integrations with a different Validator, a
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
Hello, I take advantage of the topic to say that there is an `integrationtests` module in Infinispan too using feature packs, which are usings in turn the feature packs of the Hibernate Search 5. I have to ask the ISPN guys on Zulip about that, maybe they have already planned to remove such modules and maybe we can get rid of them with the Search 6 integration. Thanks, Fabio On Fri, Apr 17, 2020 at 12:26 AM Sanne Grinovero wrote: > We have a PR for this now, if someone would like to have a look: > - https://github.com/hibernate/hibernate-orm/pull/3347 > > One thing to note, is that it also removes all Arquillian based tests: > we had some which were testing more than just the basics of our > feature pack; although most had been disabled already for other > reasons. Sadly even the few useful ones will need to be removed as > well. > > After this, we no longer have Arquillian among the test dependencies > either... back to basics. > > Thanks, > Sanne > > On Thu, 16 Apr 2020 at 16:18, Yoann Rodiere wrote: > > > > > Any specific reason you say that Yoann? > > > > No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI had > a high chance of breaking OSGi tests, unless the Jakarta artifacts properly > support OSGi. > > > > But it was just a hunch; if it works, I don't have anything against > keeping it. > > > > > > Yoann Rodière > > Hibernate Team > > yo...@hibernate.org > > > > > > On Thu, 16 Apr 2020 at 16:12, Steve Ebersole > wrote: > >> > >> I do not plan on dropping hibernate-osgi. Its there; it works. Any > >> specific reason you say that Yoann? > >> > >> Brett is the only one to do anything with that "tutorial". Though as > time > >> went on its focus was more a way to find problems when the paxexam tests > >> failed - they almost always give useless feedback. If you think people > are > >> using it as a tutorial then I agree we should remove it or update it. > >> Depending whether it still has benefit for troubleshooting I'd actually > >> just clarify its intent somehow rather removing it. Brett? > >> > >> > >> > >> On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero > wrote: > >> > >> > Agreed, I'll remove it. Thanks Steve and Yoann! > >> > > >> > I'll remove them from 5.5 soon, you can then merge the removal in 6.0 > >> > or do it differently if that's easier. > >> > > >> > This is the JIRA: > >> > - https://hibernate.atlassian.net/browse/HHH-13952 > >> > > >> > Regarding OSGi (which Yoann raised): I agree we shouldn't spend > >> > significant amounts of time on it, but as long as tests still work and > >> > it doesn't get in the way I'll leave them be. > >> > I have a related JIRA for OSGi as well: the tutorial is using very old > >> > (unmaintained?) dependency versions, so it will either need to be > >> > removed (people can always read the older tutorial), or it should be > >> > updated (and tested). > >> > I might give it a shot to update it, but I'm afraid it will need a > >> > full set of Jakarta EE 9 dependencies available as well. > >> > - https://hibernate.atlassian.net/browse/HHH-13951 > >> > > >> > Yoann, great idea about the platform agnostic testrunner. We should > >> > keep that in mind, hopefully we'll be able to make it happen > >> > eventually. > >> > > >> > Thanks, > >> > Sanne > >> > > >> > > >> > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole > wrote: > >> > > > >> > > Considering the changes in WildFly, I also think we should just drop > >> > hibernate-orm-modules. > >> > > > >> > > For 6.0 I will definitely do this. I also think removing it is > good for > >> > 5.5. > >> > > > >> > > Not sure it is even worth the hassle for earlier releases however. > >> > > > >> > > > >> > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero < > sa...@hibernate.org> > >> > wrote: > >> > >> > >> > >> As we're working to upgrade to Jakarta EE 9, our feature packs for > >> > >> Wildfly are not going to be functional for a while at least. > >> > >> > >> > >> Not only do we have to upgrade to JPA 3, but we also need to > upgrade > >> > >> our integrations with a different Validator, a different CDI - > none of > >> > >> these are provided by WildFly yet. > >> > >> > >> > >> I see several options: > >> > >> A] I could disable the feature pack generation and its integration > >> > tests. > >> > >> B] Keep generating and releasing a knowingly broken feature pack, > >> > >> disable its integration tests, document this is work in progress. > >> > >> C] Delete all this stuff > >> > >> > >> > >> Frankly it's tempting to just delete it all: WildFly has switched > to a > >> > >> new model which replaces the "feature pack" notion we have, so > even if > >> > >> Wildfly were to provide an Jakarta EE 9 build for us to run > >> > >> integration tests sometimes soon I'm sadly quite certain that we'll > >> > >> have to rethink how these packs are generated, and if it's still > worth > >> > >> for us doing this. > >> > >> > >> > >> Any thoughts? > >> > >> > >> > >> Thanks, > >> > >>
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
We have a PR for this now, if someone would like to have a look: - https://github.com/hibernate/hibernate-orm/pull/3347 One thing to note, is that it also removes all Arquillian based tests: we had some which were testing more than just the basics of our feature pack; although most had been disabled already for other reasons. Sadly even the few useful ones will need to be removed as well. After this, we no longer have Arquillian among the test dependencies either... back to basics. Thanks, Sanne On Thu, 16 Apr 2020 at 16:18, Yoann Rodiere wrote: > > > Any specific reason you say that Yoann? > > No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI had a > high chance of breaking OSGi tests, unless the Jakarta artifacts properly > support OSGi. > > But it was just a hunch; if it works, I don't have anything against keeping > it. > > > Yoann Rodière > Hibernate Team > yo...@hibernate.org > > > On Thu, 16 Apr 2020 at 16:12, Steve Ebersole wrote: >> >> I do not plan on dropping hibernate-osgi. Its there; it works. Any >> specific reason you say that Yoann? >> >> Brett is the only one to do anything with that "tutorial". Though as time >> went on its focus was more a way to find problems when the paxexam tests >> failed - they almost always give useless feedback. If you think people are >> using it as a tutorial then I agree we should remove it or update it. >> Depending whether it still has benefit for troubleshooting I'd actually >> just clarify its intent somehow rather removing it. Brett? >> >> >> >> On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero wrote: >> >> > Agreed, I'll remove it. Thanks Steve and Yoann! >> > >> > I'll remove them from 5.5 soon, you can then merge the removal in 6.0 >> > or do it differently if that's easier. >> > >> > This is the JIRA: >> > - https://hibernate.atlassian.net/browse/HHH-13952 >> > >> > Regarding OSGi (which Yoann raised): I agree we shouldn't spend >> > significant amounts of time on it, but as long as tests still work and >> > it doesn't get in the way I'll leave them be. >> > I have a related JIRA for OSGi as well: the tutorial is using very old >> > (unmaintained?) dependency versions, so it will either need to be >> > removed (people can always read the older tutorial), or it should be >> > updated (and tested). >> > I might give it a shot to update it, but I'm afraid it will need a >> > full set of Jakarta EE 9 dependencies available as well. >> > - https://hibernate.atlassian.net/browse/HHH-13951 >> > >> > Yoann, great idea about the platform agnostic testrunner. We should >> > keep that in mind, hopefully we'll be able to make it happen >> > eventually. >> > >> > Thanks, >> > Sanne >> > >> > >> > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole wrote: >> > > >> > > Considering the changes in WildFly, I also think we should just drop >> > hibernate-orm-modules. >> > > >> > > For 6.0 I will definitely do this. I also think removing it is good for >> > 5.5. >> > > >> > > Not sure it is even worth the hassle for earlier releases however. >> > > >> > > >> > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero >> > wrote: >> > >> >> > >> As we're working to upgrade to Jakarta EE 9, our feature packs for >> > >> Wildfly are not going to be functional for a while at least. >> > >> >> > >> Not only do we have to upgrade to JPA 3, but we also need to upgrade >> > >> our integrations with a different Validator, a different CDI - none of >> > >> these are provided by WildFly yet. >> > >> >> > >> I see several options: >> > >> A] I could disable the feature pack generation and its integration >> > tests. >> > >> B] Keep generating and releasing a knowingly broken feature pack, >> > >> disable its integration tests, document this is work in progress. >> > >> C] Delete all this stuff >> > >> >> > >> Frankly it's tempting to just delete it all: WildFly has switched to a >> > >> new model which replaces the "feature pack" notion we have, so even if >> > >> Wildfly were to provide an Jakarta EE 9 build for us to run >> > >> integration tests sometimes soon I'm sadly quite certain that we'll >> > >> have to rethink how these packs are generated, and if it's still worth >> > >> for us doing this. >> > >> >> > >> Any thoughts? >> > >> >> > >> Thanks, >> > >> Sanne >> > >> ___ >> > >> hibernate-dev mailing list >> > >> hibernate-dev@lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
> Any specific reason you say that Yoann? No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI had a high chance of breaking OSGi tests, unless the Jakarta artifacts properly support OSGi. But it was just a hunch; if it works, I don't have anything against keeping it. Yoann Rodière Hibernate Team yo...@hibernate.org On Thu, 16 Apr 2020 at 16:12, Steve Ebersole wrote: > I do not plan on dropping hibernate-osgi. Its there; it works. Any > specific reason you say that Yoann? > > Brett is the only one to do anything with that "tutorial". Though as time > went on its focus was more a way to find problems when the paxexam tests > failed - they almost always give useless feedback. If you think people are > using it as a tutorial then I agree we should remove it or update it. > Depending whether it still has benefit for troubleshooting I'd actually > just clarify its intent somehow rather removing it. Brett? > > > > On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero > wrote: > > > Agreed, I'll remove it. Thanks Steve and Yoann! > > > > I'll remove them from 5.5 soon, you can then merge the removal in 6.0 > > or do it differently if that's easier. > > > > This is the JIRA: > > - https://hibernate.atlassian.net/browse/HHH-13952 > > > > Regarding OSGi (which Yoann raised): I agree we shouldn't spend > > significant amounts of time on it, but as long as tests still work and > > it doesn't get in the way I'll leave them be. > > I have a related JIRA for OSGi as well: the tutorial is using very old > > (unmaintained?) dependency versions, so it will either need to be > > removed (people can always read the older tutorial), or it should be > > updated (and tested). > > I might give it a shot to update it, but I'm afraid it will need a > > full set of Jakarta EE 9 dependencies available as well. > > - https://hibernate.atlassian.net/browse/HHH-13951 > > > > Yoann, great idea about the platform agnostic testrunner. We should > > keep that in mind, hopefully we'll be able to make it happen > > eventually. > > > > Thanks, > > Sanne > > > > > > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole > wrote: > > > > > > Considering the changes in WildFly, I also think we should just drop > > hibernate-orm-modules. > > > > > > For 6.0 I will definitely do this. I also think removing it is good > for > > 5.5. > > > > > > Not sure it is even worth the hassle for earlier releases however. > > > > > > > > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero > > wrote: > > >> > > >> As we're working to upgrade to Jakarta EE 9, our feature packs for > > >> Wildfly are not going to be functional for a while at least. > > >> > > >> Not only do we have to upgrade to JPA 3, but we also need to upgrade > > >> our integrations with a different Validator, a different CDI - none of > > >> these are provided by WildFly yet. > > >> > > >> I see several options: > > >> A] I could disable the feature pack generation and its integration > > tests. > > >> B] Keep generating and releasing a knowingly broken feature pack, > > >> disable its integration tests, document this is work in progress. > > >> C] Delete all this stuff > > >> > > >> Frankly it's tempting to just delete it all: WildFly has switched to a > > >> new model which replaces the "feature pack" notion we have, so even if > > >> Wildfly were to provide an Jakarta EE 9 build for us to run > > >> integration tests sometimes soon I'm sadly quite certain that we'll > > >> have to rethink how these packs are generated, and if it's still worth > > >> for us doing this. > > >> > > >> Any thoughts? > > >> > > >> Thanks, > > >> Sanne > > >> ___ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
I do not plan on dropping hibernate-osgi. Its there; it works. Any specific reason you say that Yoann? Brett is the only one to do anything with that "tutorial". Though as time went on its focus was more a way to find problems when the paxexam tests failed - they almost always give useless feedback. If you think people are using it as a tutorial then I agree we should remove it or update it. Depending whether it still has benefit for troubleshooting I'd actually just clarify its intent somehow rather removing it. Brett? On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero wrote: > Agreed, I'll remove it. Thanks Steve and Yoann! > > I'll remove them from 5.5 soon, you can then merge the removal in 6.0 > or do it differently if that's easier. > > This is the JIRA: > - https://hibernate.atlassian.net/browse/HHH-13952 > > Regarding OSGi (which Yoann raised): I agree we shouldn't spend > significant amounts of time on it, but as long as tests still work and > it doesn't get in the way I'll leave them be. > I have a related JIRA for OSGi as well: the tutorial is using very old > (unmaintained?) dependency versions, so it will either need to be > removed (people can always read the older tutorial), or it should be > updated (and tested). > I might give it a shot to update it, but I'm afraid it will need a > full set of Jakarta EE 9 dependencies available as well. > - https://hibernate.atlassian.net/browse/HHH-13951 > > Yoann, great idea about the platform agnostic testrunner. We should > keep that in mind, hopefully we'll be able to make it happen > eventually. > > Thanks, > Sanne > > > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole wrote: > > > > Considering the changes in WildFly, I also think we should just drop > hibernate-orm-modules. > > > > For 6.0 I will definitely do this. I also think removing it is good for > 5.5. > > > > Not sure it is even worth the hassle for earlier releases however. > > > > > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero > wrote: > >> > >> As we're working to upgrade to Jakarta EE 9, our feature packs for > >> Wildfly are not going to be functional for a while at least. > >> > >> Not only do we have to upgrade to JPA 3, but we also need to upgrade > >> our integrations with a different Validator, a different CDI - none of > >> these are provided by WildFly yet. > >> > >> I see several options: > >> A] I could disable the feature pack generation and its integration > tests. > >> B] Keep generating and releasing a knowingly broken feature pack, > >> disable its integration tests, document this is work in progress. > >> C] Delete all this stuff > >> > >> Frankly it's tempting to just delete it all: WildFly has switched to a > >> new model which replaces the "feature pack" notion we have, so even if > >> Wildfly were to provide an Jakarta EE 9 build for us to run > >> integration tests sometimes soon I'm sadly quite certain that we'll > >> have to rethink how these packs are generated, and if it's still worth > >> for us doing this. > >> > >> Any thoughts? > >> > >> Thanks, > >> Sanne > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
Agreed, I'll remove it. Thanks Steve and Yoann! I'll remove them from 5.5 soon, you can then merge the removal in 6.0 or do it differently if that's easier. This is the JIRA: - https://hibernate.atlassian.net/browse/HHH-13952 Regarding OSGi (which Yoann raised): I agree we shouldn't spend significant amounts of time on it, but as long as tests still work and it doesn't get in the way I'll leave them be. I have a related JIRA for OSGi as well: the tutorial is using very old (unmaintained?) dependency versions, so it will either need to be removed (people can always read the older tutorial), or it should be updated (and tested). I might give it a shot to update it, but I'm afraid it will need a full set of Jakarta EE 9 dependencies available as well. - https://hibernate.atlassian.net/browse/HHH-13951 Yoann, great idea about the platform agnostic testrunner. We should keep that in mind, hopefully we'll be able to make it happen eventually. Thanks, Sanne On Thu, 16 Apr 2020 at 13:46, Steve Ebersole wrote: > > Considering the changes in WildFly, I also think we should just drop > hibernate-orm-modules. > > For 6.0 I will definitely do this. I also think removing it is good for 5.5. > > Not sure it is even worth the hassle for earlier releases however. > > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero wrote: >> >> As we're working to upgrade to Jakarta EE 9, our feature packs for >> Wildfly are not going to be functional for a while at least. >> >> Not only do we have to upgrade to JPA 3, but we also need to upgrade >> our integrations with a different Validator, a different CDI - none of >> these are provided by WildFly yet. >> >> I see several options: >> A] I could disable the feature pack generation and its integration tests. >> B] Keep generating and releasing a knowingly broken feature pack, >> disable its integration tests, document this is work in progress. >> C] Delete all this stuff >> >> Frankly it's tempting to just delete it all: WildFly has switched to a >> new model which replaces the "feature pack" notion we have, so even if >> Wildfly were to provide an Jakarta EE 9 build for us to run >> integration tests sometimes soon I'm sadly quite certain that we'll >> have to rethink how these packs are generated, and if it's still worth >> for us doing this. >> >> Any thoughts? >> >> Thanks, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
Considering the changes in WildFly, I also think we should just drop hibernate-orm-modules. For 6.0 I will definitely do this. I also think removing it is good for 5.5. Not sure it is even worth the hassle for earlier releases however. On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero wrote: > As we're working to upgrade to Jakarta EE 9, our feature packs for > Wildfly are not going to be functional for a while at least. > > Not only do we have to upgrade to JPA 3, but we also need to upgrade > our integrations with a different Validator, a different CDI - none of > these are provided by WildFly yet. > > I see several options: > A] I could disable the feature pack generation and its integration tests. > B] Keep generating and releasing a knowingly broken feature pack, > disable its integration tests, document this is work in progress. > C] Delete all this stuff > > Frankly it's tempting to just delete it all: WildFly has switched to a > new model which replaces the "feature pack" notion we have, so even if > Wildfly were to provide an Jakarta EE 9 build for us to run > integration tests sometimes soon I'm sadly quite certain that we'll > have to rethink how these packs are generated, and if it's still worth > for us doing this. > > Any thoughts? > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
Hello, As far as I know, the feature packs are here for two reasons: 1. To test compatibility of ORM with WildFly while still developing it. 2. To provide non-official (wrt. WildFly) ways to upgrade ORM to the latest version within WildFly. #1 does not look *that* important for 5.5, since we only run a handful of tests, not the whole test suite, and I expect the JPA 3 migration will require extensive testing in WildFly's master branch anyway. #2 looks pointless for 5.5 at the moment as JPA3 is unlikely to work in older versions of WildFly (for the reasons you mentioned, and probably also because of Jipijapa). So, +1 to drop it for now. I assume you'll do the same for OSGi? If we end up doing this, I'll do the same for Hibernate Search 5.12 (which I haven't started yet - please ping me when you think it's worth working on?) As to the future... We've talked about running the whole (huge) test suite in various environments, perhaps through Arquillian or some custom framework. It looks like a lot of work, and I'm not sure we'll ever manage to do that completely, but if we ever restore WildFly tests, I'd feel safer if we go that route than just write a few tests targeting WildFly specifically. Maybe at that point we'll have the testing framework already in place and that will be easy? A man can dream :) Yoann Rodière Hibernate Team yo...@hibernate.org On Thu, 16 Apr 2020 at 00:03, Sanne Grinovero wrote: > As we're working to upgrade to Jakarta EE 9, our feature packs for > Wildfly are not going to be functional for a while at least. > > Not only do we have to upgrade to JPA 3, but we also need to upgrade > our integrations with a different Validator, a different CDI - none of > these are provided by WildFly yet. > > I see several options: > A] I could disable the feature pack generation and its integration tests. > B] Keep generating and releasing a knowingly broken feature pack, > disable its integration tests, document this is work in progress. > C] Delete all this stuff > > Frankly it's tempting to just delete it all: WildFly has switched to a > new model which replaces the "feature pack" notion we have, so even if > Wildfly were to provide an Jakarta EE 9 build for us to run > integration tests sometimes soon I'm sadly quite certain that we'll > have to rethink how these packs are generated, and if it's still worth > for us doing this. > > Any thoughts? > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?
As we're working to upgrade to Jakarta EE 9, our feature packs for Wildfly are not going to be functional for a while at least. Not only do we have to upgrade to JPA 3, but we also need to upgrade our integrations with a different Validator, a different CDI - none of these are provided by WildFly yet. I see several options: A] I could disable the feature pack generation and its integration tests. B] Keep generating and releasing a knowingly broken feature pack, disable its integration tests, document this is work in progress. C] Delete all this stuff Frankly it's tempting to just delete it all: WildFly has switched to a new model which replaces the "feature pack" notion we have, so even if Wildfly were to provide an Jakarta EE 9 build for us to run integration tests sometimes soon I'm sadly quite certain that we'll have to rethink how these packs are generated, and if it's still worth for us doing this. Any thoughts? Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
