Re: [hibernate-dev] Stride
I think the problem here is about how we're choosing to migrate to another tool. We are basically moving to Stride because Atlassian is being uncooperative with updating HipChat, even though Stride is still not fully functional. Atlassian made HipChat, and we're not happy with HipChat. Atlassian made Stride too, so let's not trust them blindly? Sure, we can always move to another platform after moving to Stride, but it'll be a waste of time for everyone. Let's see what our options really are, first! I don't think we have many needs, and frankly I don't care which tool we'll be using. I'd rather it be open source, but I'll just use whatever we pick in the end, as long as I can write messages and receive messages. But I want people to be on this platform: both the team, and ideally community members. So let's just make sure everyone is at least comfortable with our choice. Sure some features are not useful to everybody, but in the end it's a matter of taste and personal workflow, and we can't argue about that without enforcing a standardized workflow. I think it would be more useful to just list what we want, then see which platforms fit best, then pick one, compromising as needed. I started a document to compare various solutions, feel free to add anything you think is relevant: https://docs.google.com/spreadsheets/d/1oiI_SO4O5OwTx7Fd8_lvhOvVcIIYLbnSY1MAqemz-JI/edit?usp=sharing ... But I think the one criteria that will make us pick Stride is free hosting. Most other platforms either do not have a free plan, or do not provide all of their features to free plan users. Zulip apparently removes OAuth authentication in its free plan, for instance. The Infinispan team has OAuth authentication enabled though... Do they pay for their Zulip instance? Of course if we could host it ourselves it would be another story, but I doubt anyone wants to add that to the list of tools we currently maintain. On Mon, 21 May 2018 at 14:02 Guillaume Smet wrote: > Hi, > > On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole > wrote: > > > You can't "do your job" without yet another way to get notified of CI job > > status? I'm confused - did Jenkins remove all of its other forms of > > notification? ;) Seriously though, I've never understood this desire > to > > have yet another communications "inbox" spammed by automated > notifications > > - and its even worse in Hip Cat because I can never hide them. So it is > > hard for me to incorporate this into the argument against moving. > > > > Typically, for the websites builds, I like to have the notifications on > HipChat. Not vital but it's something I appreciate. > > > > Y'all really wanted to move to Hip Chat in the first place even though to > > me it always felt (and feels) half-baked itself. > > > > I wasn't part of the team at that point. > > > > And if the web client is as good as the native client, I assume you use > > the web client instead? > > > > Yes. I have a pinned tab for it. Desktop notifications from the browser are > well integrated now. > > > > So to me it really comes down to what are the blockers to not making this > > move now. So far I hear: > > > >1. No Jenkins notifications - see above > >2. Guest access - meh - If having to have an account to join the > >discussion is bad then we should immediately make our forums > >guest-accessible again as well ;) > > > > As mentioned in my email, I don't mind not having guest access if we have > some sort of external auth integration (Github/Twitter/Google). This way, > it avoids creating yet another account. That's what we have on our new > forums. > > Maybe Stride has it, I don't know, but I would like our next chat system to > have that. > > I took a look at several accounts we have on our forums and most of them > are from GitHub or Google (I took seven randomly and 1 had an account > specific to our forums - no better statistics sorry). > > > > >1. There may be better options out there - at some point can we just > >pick one and use it? Is one "inbox" really that much better than > another > >"inbox"? And clearly I am not even tied to Hip Chat - I was one of > the > >people wanting to not move there. Radim, what makes Zulip so amazing? > >2. "Coordination tool"? Not really sure what this one is about. Is > >this back to Jenkins notifications? If you mean a communications > tool, of > >course it works. They are largely the same. Andrea, Sanne and I have > >played with it, so we in fact do have some idea if it will (spoiler: > it > >does) > >3. We should go where WildFly goes (?). > > > > My main point is that we have no idea if Stride is stable at the moment. > They definitely don't want to massively migrate the HipChat users and I > found at least one comment of a person who has migrated there and is not > happy at all (not saying it makes all the migrated users unhappy, just > saying that it might be a bad move if we do it now). > > So again,
Re: [hibernate-dev] Stride
I see it much simpler. We're moving to Stride because that's how HipChat evolved. On Tue, 22 May 2018, 09:34 Yoann Rodiere, wrote: > I think the problem here is about how we're choosing to migrate to another > tool. We are basically moving to Stride because Atlassian is being > uncooperative with updating HipChat, even though Stride is still not fully > functional. > Atlassian made HipChat, and we're not happy with HipChat. Atlassian made > Stride too, so let's not trust them blindly? Sure, we can always move to > another platform after moving to Stride, but it'll be a waste of time for > everyone. Let's see what our options really are, first! > > I don't think we have many needs, and frankly I don't care which tool we'll > be using. I'd rather it be open source, but I'll just use whatever we pick > in the end, as long as I can write messages and receive messages. But I > want people to be on this platform: both the team, and ideally community > members. So let's just make sure everyone is at least comfortable with our > choice. > Sure some features are not useful to everybody, but in the end it's a > matter of taste and personal workflow, and we can't argue about that > without enforcing a standardized workflow. I think it would be more useful > to just list what we want, then see which platforms fit best, then pick > one, compromising as needed. > > I started a document to compare various solutions, feel free to add > anything you think is relevant: > > https://docs.google.com/spreadsheets/d/1oiI_SO4O5OwTx7Fd8_lvhOvVcIIYLbnSY1MAqemz-JI/edit?usp=sharing > > ... But I think the one criteria that will make us pick Stride is free > hosting. Most other platforms either do not have a free plan, or do not > provide all of their features to free plan users. Zulip apparently removes > OAuth authentication in its free plan, for instance. The Infinispan team > has OAuth authentication enabled though... Do they pay for their Zulip > instance? > > Of course if we could host it ourselves it would be another story, but I > doubt anyone wants to add that to the list of tools we currently maintain. > > > On Mon, 21 May 2018 at 14:02 Guillaume Smet > wrote: > > > Hi, > > > > On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole > > wrote: > > > > > You can't "do your job" without yet another way to get notified of CI > job > > > status? I'm confused - did Jenkins remove all of its other forms of > > > notification? ;) Seriously though, I've never understood this desire > > to > > > have yet another communications "inbox" spammed by automated > > notifications > > > - and its even worse in Hip Cat because I can never hide them. So it > is > > > hard for me to incorporate this into the argument against moving. > > > > > > > Typically, for the websites builds, I like to have the notifications on > > HipChat. Not vital but it's something I appreciate. > > > > > > > Y'all really wanted to move to Hip Chat in the first place even though > to > > > me it always felt (and feels) half-baked itself. > > > > > > > I wasn't part of the team at that point. > > > > > > > And if the web client is as good as the native client, I assume you use > > > the web client instead? > > > > > > > Yes. I have a pinned tab for it. Desktop notifications from the browser > are > > well integrated now. > > > > > > > So to me it really comes down to what are the blockers to not making > this > > > move now. So far I hear: > > > > > >1. No Jenkins notifications - see above > > >2. Guest access - meh - If having to have an account to join the > > >discussion is bad then we should immediately make our forums > > >guest-accessible again as well ;) > > > > > > As mentioned in my email, I don't mind not having guest access if we > have > > some sort of external auth integration (Github/Twitter/Google). This way, > > it avoids creating yet another account. That's what we have on our new > > forums. > > > > Maybe Stride has it, I don't know, but I would like our next chat system > to > > have that. > > > > I took a look at several accounts we have on our forums and most of them > > are from GitHub or Google (I took seven randomly and 1 had an account > > specific to our forums - no better statistics sorry). > > > > > > > >1. There may be better options out there - at some point can we just > > >pick one and use it? Is one "inbox" really that much better than > > another > > >"inbox"? And clearly I am not even tied to Hip Chat - I was one of > > the > > >people wanting to not move there. Radim, what makes Zulip so > amazing? > > >2. "Coordination tool"? Not really sure what this one is about. Is > > >this back to Jenkins notifications? If you mean a communications > > tool, of > > >course it works. They are largely the same. Andrea, Sanne and I > have > > >played with it, so we in fact do have some idea if it will (spoiler: > > it > > >does) > > >3. We should go where WildFly goes (?). > > >
[hibernate-dev] Disallow uncategorized topics
Hi, We've seen a few posts on discourse lately without any category. More often than not, these are about ORM (which makes sense since most posts are about ORM). This is a bit annoying since it makes it hard to configure Discourse to only receive notifications about topics we want to actively monitor. Would anyone object to disallowing uncategorized topics? I can create a "Miscellaneous" category if you want, but I'd really like people to pick a category when they create a topic. -- Yoann Rodiere yo...@hibernate.org / yrodi...@redhat.com Software Engineer Hibernate NoORM team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Stride
On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere wrote: > ... But I think the one criteria that will make us pick Stride is free > hosting. Most other platforms either do not have a free plan, or do not > provide all of their features to free plan users. Zulip apparently removes > OAuth authentication in its free plan, for instance. The Infinispan team > has OAuth authentication enabled though... Do they pay for their Zulip > instance? > Quote: "Zulip Cloud Premium is free for open source projects and a wide variety of non-commercial entities" What bugged me first was the capped archives of the free offer. HipChat is doing a very similar thing. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Disallow uncategorized topics
+1 to encourage people to set a category but I wouldn't require strict rules, it's not like we're flooded with notifications? In particular, I see no value in a "Miscellaneous" category; it's not like people are going to think "cool, Miscellaneous is exactly what I was looking for". On 22 May 2018 at 09:43, Yoann Rodiere wrote: > Hi, > > We've seen a few posts on discourse lately without any category. More often > than not, these are about ORM (which makes sense since most posts are about > ORM). > > This is a bit annoying since it makes it hard to configure Discourse to > only receive notifications about topics we want to actively monitor. > > Would anyone object to disallowing uncategorized topics? I can create a > "Miscellaneous" category if you want, but I'd really like people to pick a > category when they create a topic. > -- > Yoann Rodiere > yo...@hibernate.org / yrodi...@redhat.com > Software Engineer > Hibernate NoORM team > ___ > 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] Disallow uncategorized topics
I counted at least 3 mis-categorized topics just this weekend, and beyond the notification we also have to categorize them ourselves. Unfortunately I can't "encourage" without enforcing a strict rule. Discourse only has an option to force people to chose a category, not an option to make it more obvious that people should chose a category. That's why I suggested the "Miscellaneous" category: they will be forced to pick a category, but if nothing fits they can always pick "Miscellaneous". Obviously I don't imagine that people will think "Miscellaneous" will fit their needs exactly, that's a last resort. On Tue, 22 May 2018 at 11:06 Sanne Grinovero wrote: > +1 to encourage people to set a category > > but I wouldn't require strict rules, it's not like we're flooded with > notifications? > > In particular, I see no value in a "Miscellaneous" category; it's not > like people are going to think "cool, Miscellaneous is exactly what I > was looking for". > > On 22 May 2018 at 09:43, Yoann Rodiere wrote: > > Hi, > > > > We've seen a few posts on discourse lately without any category. More > often > > than not, these are about ORM (which makes sense since most posts are > about > > ORM). > > > > This is a bit annoying since it makes it hard to configure Discourse to > > only receive notifications about topics we want to actively monitor. > > > > Would anyone object to disallowing uncategorized topics? I can create a > > "Miscellaneous" category if you want, but I'd really like people to pick > a > > category when they create a topic. > > -- > > Yoann Rodiere > > yo...@hibernate.org / yrodi...@redhat.com > > Software Engineer > > Hibernate NoORM team > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Yoann Rodiere yo...@hibernate.org / yrodi...@redhat.com Software Engineer Hibernate NoORM team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Disallow uncategorized topics
Hi, On Tue, May 22, 2018 at 10:43 AM, Yoann Rodiere wrote: > Would anyone object to disallowing uncategorized topics? I can create a > "Miscellaneous" category if you want, but I'd really like people to pick a > category when they create a topic. Sure, let's do it if we can. I don't think we need a Misc. category. I just categorized all the uncategorized posts and they all fit somewhere. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Disallow uncategorized topics
I can create a category named " " and force users to pick something explicitly, but it will render poorly, especially on the home page. What's wrong with "Miscellaneous"? I can use another name if you want. "Cannot categorize" or something like that. I can even try naming it "Uncategorized", but there's already a "system" category with this name (only enabled if we don't enforce categories), so I'm not sure if Discourse will allow that. On Tue, 22 May 2018 at 11:22 Sanne Grinovero wrote: > On 22 May 2018 at 10:15, Yoann Rodiere wrote: > > I counted at least 3 mis-categorized topics just this weekend, and beyond > > the notification we also have to categorize them ourselves. > > > > Unfortunately I can't "encourage" without enforcing a strict rule. > Discourse > > only has an option to force people to chose a category, not an option to > > make it more obvious that people should chose a category. > > That's why I suggested the "Miscellaneous" category: they will be forced > to > > pick a category, but if nothing fits they can always pick > "Miscellaneous". > > Obviously I don't imagine that people will think "Miscellaneous" will fit > > their needs exactly, that's a last resort. > > Ah. What about a "" category ? Maybe that will encourage people to > stop a second and think about it, yet have the option to go ahead? > > > > > On Tue, 22 May 2018 at 11:06 Sanne Grinovero > wrote: > >> > >> +1 to encourage people to set a category > >> > >> but I wouldn't require strict rules, it's not like we're flooded with > >> notifications? > >> > >> In particular, I see no value in a "Miscellaneous" category; it's not > >> like people are going to think "cool, Miscellaneous is exactly what I > >> was looking for". > >> > >> On 22 May 2018 at 09:43, Yoann Rodiere wrote: > >> > Hi, > >> > > >> > We've seen a few posts on discourse lately without any category. More > >> > often > >> > than not, these are about ORM (which makes sense since most posts are > >> > about > >> > ORM). > >> > > >> > This is a bit annoying since it makes it hard to configure Discourse > to > >> > only receive notifications about topics we want to actively monitor. > >> > > >> > Would anyone object to disallowing uncategorized topics? I can create > a > >> > "Miscellaneous" category if you want, but I'd really like people to > pick > >> > a > >> > category when they create a topic. > >> > -- > >> > Yoann Rodiere > >> > yo...@hibernate.org / yrodi...@redhat.com > >> > Software Engineer > >> > Hibernate NoORM team > >> > ___ > >> > hibernate-dev mailing list > >> > hibernate-dev@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > -- > > Yoann Rodiere > > yo...@hibernate.org / yrodi...@redhat.com > > Software Engineer > > Hibernate NoORM team > -- Yoann Rodiere yo...@hibernate.org / yrodi...@redhat.com Software Engineer Hibernate NoORM team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Disallow uncategorized topics
On 22 May 2018 at 10:15, Yoann Rodiere wrote: > I counted at least 3 mis-categorized topics just this weekend, and beyond > the notification we also have to categorize them ourselves. > > Unfortunately I can't "encourage" without enforcing a strict rule. Discourse > only has an option to force people to chose a category, not an option to > make it more obvious that people should chose a category. > That's why I suggested the "Miscellaneous" category: they will be forced to > pick a category, but if nothing fits they can always pick "Miscellaneous". > Obviously I don't imagine that people will think "Miscellaneous" will fit > their needs exactly, that's a last resort. Ah. What about a "" category ? Maybe that will encourage people to stop a second and think about it, yet have the option to go ahead? > > On Tue, 22 May 2018 at 11:06 Sanne Grinovero wrote: >> >> +1 to encourage people to set a category >> >> but I wouldn't require strict rules, it's not like we're flooded with >> notifications? >> >> In particular, I see no value in a "Miscellaneous" category; it's not >> like people are going to think "cool, Miscellaneous is exactly what I >> was looking for". >> >> On 22 May 2018 at 09:43, Yoann Rodiere wrote: >> > Hi, >> > >> > We've seen a few posts on discourse lately without any category. More >> > often >> > than not, these are about ORM (which makes sense since most posts are >> > about >> > ORM). >> > >> > This is a bit annoying since it makes it hard to configure Discourse to >> > only receive notifications about topics we want to actively monitor. >> > >> > Would anyone object to disallowing uncategorized topics? I can create a >> > "Miscellaneous" category if you want, but I'd really like people to pick >> > a >> > category when they create a topic. >> > -- >> > Yoann Rodiere >> > yo...@hibernate.org / yrodi...@redhat.com >> > Software Engineer >> > Hibernate NoORM team >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > Yoann Rodiere > yo...@hibernate.org / yrodi...@redhat.com > Software Engineer > Hibernate NoORM team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Disallow uncategorized topics
On 22 May 2018 at 10:30, Yoann Rodiere wrote: > I can create a category named " " and force users to pick something > explicitly, but it will render poorly, especially on the home page. Just a joke. More seriously I was wondering if there was some way. > What's wrong with "Miscellaneous"? I can use another name if you want. > "Cannot categorize" or something like that. I can even try naming it > "Uncategorized", but there's already a "system" category with this name > (only enabled if we don't enforce categories), so I'm not sure if Discourse > will allow that. Nothing decidedly wrong with it. Just my last preference; IMO I'd prefer keeping things as they are, but no strong feeling. Thanks > > On Tue, 22 May 2018 at 11:22 Sanne Grinovero wrote: >> >> On 22 May 2018 at 10:15, Yoann Rodiere wrote: >> > I counted at least 3 mis-categorized topics just this weekend, and >> > beyond >> > the notification we also have to categorize them ourselves. >> > >> > Unfortunately I can't "encourage" without enforcing a strict rule. >> > Discourse >> > only has an option to force people to chose a category, not an option to >> > make it more obvious that people should chose a category. >> > That's why I suggested the "Miscellaneous" category: they will be forced >> > to >> > pick a category, but if nothing fits they can always pick >> > "Miscellaneous". >> > Obviously I don't imagine that people will think "Miscellaneous" will >> > fit >> > their needs exactly, that's a last resort. >> >> Ah. What about a "" category ? Maybe that will encourage people to >> stop a second and think about it, yet have the option to go ahead? >> >> > >> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero >> > wrote: >> >> >> >> +1 to encourage people to set a category >> >> >> >> but I wouldn't require strict rules, it's not like we're flooded with >> >> notifications? >> >> >> >> In particular, I see no value in a "Miscellaneous" category; it's not >> >> like people are going to think "cool, Miscellaneous is exactly what I >> >> was looking for". >> >> >> >> On 22 May 2018 at 09:43, Yoann Rodiere wrote: >> >> > Hi, >> >> > >> >> > We've seen a few posts on discourse lately without any category. More >> >> > often >> >> > than not, these are about ORM (which makes sense since most posts are >> >> > about >> >> > ORM). >> >> > >> >> > This is a bit annoying since it makes it hard to configure Discourse >> >> > to >> >> > only receive notifications about topics we want to actively monitor. >> >> > >> >> > Would anyone object to disallowing uncategorized topics? I can create >> >> > a >> >> > "Miscellaneous" category if you want, but I'd really like people to >> >> > pick >> >> > a >> >> > category when they create a topic. >> >> > -- >> >> > Yoann Rodiere >> >> > yo...@hibernate.org / yrodi...@redhat.com >> >> > Software Engineer >> >> > Hibernate NoORM team >> >> > ___ >> >> > hibernate-dev mailing list >> >> > hibernate-dev@lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > -- >> > Yoann Rodiere >> > yo...@hibernate.org / yrodi...@redhat.com >> > Software Engineer >> > Hibernate NoORM team > > -- > Yoann Rodiere > yo...@hibernate.org / yrodi...@redhat.com > Software Engineer > Hibernate NoORM team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Disallow uncategorized topics
Done: users must now choose a category, and may use "Miscellaneous" if their topic really doesn't fit any category. On Tue, 22 May 2018 at 11:48 Sanne Grinovero wrote: > On 22 May 2018 at 10:30, Yoann Rodiere wrote: > > I can create a category named " " and force users to pick something > > explicitly, but it will render poorly, especially on the home page. > > Just a joke. More seriously I was wondering if there was some way. > > > What's wrong with "Miscellaneous"? I can use another name if you want. > > "Cannot categorize" or something like that. I can even try naming it > > "Uncategorized", but there's already a "system" category with this name > > (only enabled if we don't enforce categories), so I'm not sure if > Discourse > > will allow that. > > Nothing decidedly wrong with it. Just my last preference; IMO I'd > prefer keeping things as they are, but no strong feeling. > > Thanks > > > > > On Tue, 22 May 2018 at 11:22 Sanne Grinovero > wrote: > >> > >> On 22 May 2018 at 10:15, Yoann Rodiere wrote: > >> > I counted at least 3 mis-categorized topics just this weekend, and > >> > beyond > >> > the notification we also have to categorize them ourselves. > >> > > >> > Unfortunately I can't "encourage" without enforcing a strict rule. > >> > Discourse > >> > only has an option to force people to chose a category, not an option > to > >> > make it more obvious that people should chose a category. > >> > That's why I suggested the "Miscellaneous" category: they will be > forced > >> > to > >> > pick a category, but if nothing fits they can always pick > >> > "Miscellaneous". > >> > Obviously I don't imagine that people will think "Miscellaneous" will > >> > fit > >> > their needs exactly, that's a last resort. > >> > >> Ah. What about a "" category ? Maybe that will encourage people to > >> stop a second and think about it, yet have the option to go ahead? > >> > >> > > >> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero > >> > wrote: > >> >> > >> >> +1 to encourage people to set a category > >> >> > >> >> but I wouldn't require strict rules, it's not like we're flooded with > >> >> notifications? > >> >> > >> >> In particular, I see no value in a "Miscellaneous" category; it's not > >> >> like people are going to think "cool, Miscellaneous is exactly what I > >> >> was looking for". > >> >> > >> >> On 22 May 2018 at 09:43, Yoann Rodiere wrote: > >> >> > Hi, > >> >> > > >> >> > We've seen a few posts on discourse lately without any category. > More > >> >> > often > >> >> > than not, these are about ORM (which makes sense since most posts > are > >> >> > about > >> >> > ORM). > >> >> > > >> >> > This is a bit annoying since it makes it hard to configure > Discourse > >> >> > to > >> >> > only receive notifications about topics we want to actively > monitor. > >> >> > > >> >> > Would anyone object to disallowing uncategorized topics? I can > create > >> >> > a > >> >> > "Miscellaneous" category if you want, but I'd really like people to > >> >> > pick > >> >> > a > >> >> > category when they create a topic. > >> >> > -- > >> >> > Yoann Rodiere > >> >> > yo...@hibernate.org / yrodi...@redhat.com > >> >> > Software Engineer > >> >> > Hibernate NoORM team > >> >> > ___ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev@lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> > -- > >> > Yoann Rodiere > >> > yo...@hibernate.org / yrodi...@redhat.com > >> > Software Engineer > >> > Hibernate NoORM team > > > > -- > > Yoann Rodiere > > yo...@hibernate.org / yrodi...@redhat.com > > Software Engineer > > Hibernate NoORM team > -- Yoann Rodiere yo...@hibernate.org / yrodi...@redhat.com Software Engineer Hibernate NoORM team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] WildFly 14 requirements for Hibernate libraries
Hi all, good news first: WildFly 13 will include our latest Hibernate libraries, in addition to the existing ones. When booting WildFly 13 with the "-Dee8.preview.mode=true" property set, it will use: - Hibernate ORM 5.3 - Hibernate Search 5.10 - Hibernate Validator 6.0 (Validator 6 was available also in WildFly 12) By default, for users not setting this preview mode, it will use the older versions which were included in previous WildFly releases - providing JPA 2.1 and EE7 compatibility only. We're getting some requirements for WildFly 14 though, which needs to be ready within 3 months. In particular: A] EE8 will be the only mode So while today users have the ability to opt-in or ORM 5.3 and companions, this will be enforced as the older libraries are removed. Not much we need to do, other than further ensuring that people will not have trouble. It's also an opportunity to get rid of unnecessary dependencies. B] we need to finish some backward compatibility work. We did quite some work to ensure ORM 5.3 would be great at backward compatibility but we left some pending work, e.g. the Compatibility Transformer that David proposed is not available yet and it needs some more details from us, such as a definitive list of the transformations it will need to perform. Also, the QE team didn't have a chance to review the work in detail yet; I'm confident we did most of the work already but they might raise the bar further or just have some questions, we will need to work with them. I also hope we'll get more familiar with them and their processes as clearly this isn't a one-off, we can all benefit from working more closely with them for all future releases. C] WildFly 14 is expected to work on both JDK8 and JDK11 Most work to support new JDKs has been done but we need to finish the last details. - CI jobs still not entirely working on JDK11 - Javassist might stay as an option but we need to make sure no feature relies on it, as I don't think Javassist will be supportable on JDK11 - consequentially, the Byte Buddy based alternative needs to be great (some issues have been raised) - some code to work on JDK11 will need to invoke APIs which were not available in JDK8: are we going to release "multi-release jars"? - resume the work on modernizing the XML parsers? In particular, Byte Buddy on JDK11 will need access to the classloader via VarHandles to enhance entities; I didn't investigate this thoroughly yet but I believe I won't be able to give these references to BB while relying exclusively on JDK8 APIs. If we manage to improve anything by the 28th we can still include micro-fixes in WildFly 13; in particular, if you are aware of any blocker let's fix them now so that people can give us more detailed feedback by actually using the EE8 preview mode. (This includes possibly planning for some micro releases within a week) Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?
On 05/20/2018 08:48 AM, Sanne Grinovero wrote: > Hi Scott, > > could you explain what you mean by "tradeoff" in this context? Hi Sanne, Sure, see below for more details. > > Thanks! > > > On 20 May 2018 at 12:06, Scott Marlow wrote: >> There is a tradeoff in WF deployment, between Hibernate bytecode (runtime) >> enhancing class transformers, being registered before CDI deployment, reads >> the entity classes. To explain what I mean by the "tradeoff", I will first explain some ordering rules based on the current WildFly/Hibernate deployment scheme. 1. The first "must happen before" rule is that the Hibernate ORM bytecode enhancer must register via PersistenceUnitInfo.addTransformer(ClassTransformer) [1], before any application classes are loaded/defined by the application classloader. 2. Another "must happen before" rule is that the DataSource [2] must be available before the first Hibernate ORM (persistence unit) bootstrap phase (in the case of applications using the two-phase bootstrap). For applications using the single phase PU bootstrap, the DataSource must be available before the call to Persistence.createEntityManagerFactory(). 3. Another "must happen before" rule, is that CDI handling (WF) deployer unit processing code must read the application classes and transform application classes as part of CDI deployment, in order to meet the CDI requirements. The first Hibernate ORM pu bootstrap phrase, must currently register its class transformer [1] before CDI reads/transforms application classes, or the Hibernate entity class transformer, will be ignored (note, there is no deployment failure for this, nor can there be currently). 4. Another "must happen before" rule, is that WildFly @DataSourceDefinitions, do not become available until very late deployment phases, when application classes, will already have been read. Hibernate can also start its first Hibernate ORM pu bootstrap phrase, very late as well but again, the Hibernate entity class will be ignored (since application classes are already defined before Hibernate starts deployment). If applications want entity classes to be enhanced, the first Hibernate ORM pu bootstrap phrase, must run early enough but that cannot happen if the pu depends on a @DataSourceDefinition. There are some WildFly pu hints that influence the ordering but currently, apps have to decide what they really want to work: jboss.as.jpa.classtransformer - defaults to true but if false, WildFly does not try to register the entity class transformers early. wildfly.jpa.twophasebootstrap - defaults to true but if false, WildFly does not try to use two phase persistence unit bootstrap (currently only supported for Hibernate). Steve Ebersole and I have talked about adding additional phases to the PU bootstrap, but that was so long ago, I forget if it was about registering the ORM class transformer [1] earlier. If ORM 5.3 or 6.0, is depending on [1] to work correctly in order to implement the ORM features, we need to take some action. In the past, I recall someone mentioning that lazy loading or dirty flag handling, would depend on bytecode enhancing. If that happened or will happen, we should discuss what the fallback solution is for when bytecode enhancing is not working. Another subject, is how should a user find out that bytecode enhancing is actually updating application entity classes. Should that operation have trace logging and should that be at the WF or ORM level? Scott [1] https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer- [2] https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html >> >> There is also the tradeoff between Hibernate bytecode (runtime) enhancing >> class transformers being registered too late because the persistent unit >> uses a datasourcedefinition. >> >> I asked Gail's question for 5.1.x and the answer was no. >> >> Now, for 5.3, I don't understand the answers yet. >> >> Anyway, wanted to mention the above, to share more info with all, as to why >> we are asking. >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] NoORM IRC meeting minutes
Hi, Here are the minutes of our NoORM IRC meeting: 15:38 < jbott> Meeting ended Tue May 22 13:37:54 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:38 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.html 15:38 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.txt 15:38 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.log.html Have a nice day. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
