From mihalcea.vlad at gmail.com Fri Sep 1 01:25:42 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 1 Sep 2017 08:25:42 +0300 Subject: [hibernate-dev] Unresolved issues targeting 5.2.11 In-Reply-To: References: Message-ID: Hi Gail, My issues have Pull Requests that need to be reviewed. However, there are around 8 PRs which I'd like someone to review so that we can include them in 5.2.11: https://github.com/hibernate/hibernate-orm/pulls?q=is%3Aopen+is%3Apr+author%3Avladmihalcea+label%3A%22Ready+for+review%22 Thanks, Vlad On Fri, Sep 1, 2017 at 6:37 AM, Gail Badner wrote: > Unless something critical comes up, I plan release 5.2.11 next week. There > are currently 24 unresolved issues. [1] > > I am CC'ing everyone that is assigned issues that are still unresolved. > Please take a moment to move any issues that you know will not be ready for > 5.2.11 to 5.2.12. > > There are also 7 issues that are unassigned. If you are familiar with > those, then please take a look and move to 5.2.12 if they will not be > finished. > > Thanks, > Gail > > [1] https://hibernate.atlassian.net/projects/HHH/versions/ > 28600/tab/release-report-todo > From gbadner at redhat.com Fri Sep 1 02:19:01 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 31 Aug 2017 23:19:01 -0700 Subject: [hibernate-dev] Unresolved issues targeting 5.2.11 In-Reply-To: References: Message-ID: Hi Vlad, Thanks for letting me know. I'll take a look tomorrow. Regards, Gail On Thu, Aug 31, 2017 at 10:25 PM, Vlad Mihalcea wrote: > Hi Gail, > > My issues have Pull Requests that need to be reviewed. > > However, there are around 8 PRs which I'd like someone to review so that > we can include them in 5.2.11: > > https://github.com/hibernate/hibernate-orm/pulls?q=is% > 3Aopen+is%3Apr+author%3Avladmihalcea+label%3A%22Ready+for+review%22 > > Thanks, > Vlad > > On Fri, Sep 1, 2017 at 6:37 AM, Gail Badner wrote: > >> Unless something critical comes up, I plan release 5.2.11 next week. >> There are currently 24 unresolved issues. [1] >> >> I am CC'ing everyone that is assigned issues that are still unresolved. >> Please take a moment to move any issues that you know will not be ready for >> 5.2.11 to 5.2.12. >> >> There are also 7 issues that are unassigned. If you are familiar with >> those, then please take a look and move to 5.2.12 if they will not be >> finished. >> >> Thanks, >> Gail >> >> [1] https://hibernate.atlassian.net/projects/HHH/versions/28600/ >> tab/release-report-todo >> > > From mihalcea.vlad at gmail.com Fri Sep 1 02:23:03 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 1 Sep 2017 09:23:03 +0300 Subject: [hibernate-dev] Unresolved issues targeting 5.2.11 In-Reply-To: References: Message-ID: Much appreciated, Vlad On Fri, Sep 1, 2017 at 9:19 AM, Gail Badner wrote: > Hi Vlad, > > Thanks for letting me know. I'll take a look tomorrow. > > Regards, > Gail > > On Thu, Aug 31, 2017 at 10:25 PM, Vlad Mihalcea > wrote: > >> Hi Gail, >> >> My issues have Pull Requests that need to be reviewed. >> >> However, there are around 8 PRs which I'd like someone to review so that >> we can include them in 5.2.11: >> >> https://github.com/hibernate/hibernate-orm/pulls?q=is%3Aopen >> +is%3Apr+author%3Avladmihalcea+label%3A%22Ready+for+review%22 >> >> Thanks, >> Vlad >> >> On Fri, Sep 1, 2017 at 6:37 AM, Gail Badner wrote: >> >>> Unless something critical comes up, I plan release 5.2.11 next week. >>> There are currently 24 unresolved issues. [1] >>> >>> I am CC'ing everyone that is assigned issues that are still unresolved. >>> Please take a moment to move any issues that you know will not be ready for >>> 5.2.11 to 5.2.12. >>> >>> There are also 7 issues that are unassigned. If you are familiar with >>> those, then please take a look and move to 5.2.12 if they will not be >>> finished. >>> >>> Thanks, >>> Gail >>> >>> [1] https://hibernate.atlassian.net/projects/HHH/versions/28600/ >>> tab/release-report-todo >>> >> >> > From gbadner at redhat.com Fri Sep 1 14:11:23 2017 From: gbadner at redhat.com (Gail Badner) Date: Fri, 1 Sep 2017 11:11:23 -0700 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: I have a better understanding after discussing further with Scott, so I agree with Steve now. I have some ideas about how to fix this. Sanne, you mentioned getting a failure using an integration test. Please provide details for reproducing this. On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole wrote: > The whole purpose of ExtendedBeanManager is cases where the BeanManager is > not available when Hibernate boots (in other words when Hibernate is told > which to use) . This is a way to give Hibernate a callback when the > BeanManager is available. IMO this ExtendedBeanManager implementing > BeanManager is inaccurate. But would certainly like to hear Scott's > opinion as well. > > Technically this situation is non-JPA compliant as JPA requires that the > BeanManager passed to be available at boot-time. > > On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero > wrote: > >> Hi Gail, >> >> no I haven't opened a WFLY issue as I'm not sure if this is an issue. >> >> There seems to be some inconsistency and it certainly breaks some >> Hibernate Search tests but we could of course adapt things to the new >> reality.. if this is how it's meant to be. >> >> The source code of the ExtendedBeanManager which you didn't find is >> located in the WildFly source code; it's part of JipiJapa: >> - https://github.com/wildfly/wildfly/blob/master/jpa/ >> hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/ >> HibernateExtendedBeanManager.java >> >> As you also noticed, it no longer implement the standard BeanManager >> interface. I agree with you that I'd expect it to still implement it, >> but clearly this was changed intentionally so I hope someone (Scott >> possibly?) can clarify - or revert. >> >> In case this is intentionally no longer implementing the standard >> interface we should at least clarify the javadocs if this >> configuration property. >> >> The missing javax.el.ELResolver and javax.el.ExpressionFactory is >> unfortunate. I'd hope we could do better than just add them back, >> maybe it requires a dedicated module? Having too many dependencies - >> in this case half of Weld - slows down our bootstrap significantly and >> users have been complaining about that. >> >> Thanks, >> Sanne >> >> On 30 August 2017 at 06:58, Gail Badner wrote: >> > Hi Sanne, >> > >> > Do you have a WFLY issue for this? >> > >> > I've tentatively created a branch and pushed a commit to my fork that >> > reproduces this issue. [1] >> > >> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT. >> > >> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an >> > implementation, ExtendedBeanManagerImpl [2], that implements both >> > BeanManager, ExtendedBeanManager. >> > >> > I don't see this test in 5.2, and I don't see any implementation of >> > ExtendedBeanManager in 5.2. I do see tests in >> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to look >> at >> > those yet. >> > >> > I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >> > should implement javax.enterprise.inject.spi.BeanManager as well. I >> tried >> > making this change, and having BeanManager methods delegate to >> > HibernateExtendedBeanManager#beanManager, but it looks like a >> dependency is >> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory are >> > unresolved. >> > >> > Please let me know if I'm on the right (or wrong) track. I'll pick this >> up >> > tomorrow. >> > >> > Regards, >> > Gail >> > >> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >> > [2] >> > https://github.com/hibernate/hibernate-orm/blob/5.1/ >> hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ >> ExtendedBeanManagerCdiTest.java#L195 >> > >> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero >> > wrote: >> >> >> >> Hi all, >> >> >> >> In Hibernate Search we have a snippet of code doing: >> >> >> >> private static BeanManager getBeanManager(Map >> configurationValues) { >> >> return (BeanManager) configurationValues.get( >> >> AvailableSettings.CDI_BEAN_MANAGER ); >> >> } >> >> >> >> This used to work on WildFly 10 - even if we were to override the >> >> Hibernate ORM version to 5.2. >> >> >> >> By runnning the same integration test on WildFly 11 I'm now getting a >> >> ClassCastException as the returned instance is of type >> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does >> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but >> >> does not implement the standard >> >> `javax.enterprise.inject.spi.BeanManager` interface. >> >> >> >> I'm unsure if this is a bug in the Search code or a misunderstanding >> >> between the WildFly / ORM integration? >> >> >> >> This javadoc seems relevant: >> >> >> >> /** >> >> * Used to pass along the CDI BeanManager, if any, to be used. >> >> */ >> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >> >> >> >> or should I interpret this property as meant only for "write" purposes >> >> into the ORM configuration? I suppose it's unexpected that we attempt >> >> to retrieve this as well. >> >> >> >> Thanks, >> >> Sanne >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Sat Sep 2 11:47:24 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 02 Sep 2017 15:47:24 +0000 Subject: [hibernate-dev] Question.. In-Reply-To: References: Message-ID: I don't have the original email to reply to. So I'll reply here. Overall, I had not really considered the primitive attribute case, but yeah that's clearly an issue. My mistake. A) I agree that the con here is huge. Not the best option B) Is close to better. We could certainly check this and throw an error. A better logical option is to do similar to what we do for ids and versions... on startup instantiate one of these and grab/store its initial state when freshly instantiated. We can later use those values to perform the empty check. This is more logical, but not sure how "practical" it is given that we do not really have a good place to keep this relative to an embeddable, nor relative to an embedded, aside from CompositeType, but that does not feel right. This is better in 6 as we have an actual runtime model representation of the embedded and embeddable - but of course that does not help us in 5 C) I really hate exposing `ComponentType` on a new SPI interface considering the type system is completely revamped in 6. This would be (1) a very short lived contract in this form and therefore (2) means yet another pain point for user upgrading 5->6. Ultimately I think this is the most promising solution moving forward (possibly coupled with the "expanded" B option).. However, that said, I am not sure we have a choice prior to 6 if we want to go this route - we'd have to expose the CompositeType.. There is no good singular thing prior to 6 to describe a embedded/embeddable. To clarify what sounds like a misunderstanding though, CompositeType is unique to each embedded usage, not embeddable. The CompositeType however does not expose its "role", so not sure if that distinction helps here. To make sure I understand your (D)... you mean to allow users to disable this option globally but to allow this option per specific embedded? Longer term (6) I think this is something else we ought to support as well as the inverse (globally opt-in, but allowing a local opt-out). That's not necessarily a strategy though for dealing with embeddeds that are "opted-in" that happen to use primitives. Yes, it allows the user to more actively and selectively manage that themselves, but if they happen to opt-in an embedded which contains primitives we have the same issue to deal with. Longer term I see allowing a mix of (B) (expanded), (C) and (D). For the short term (5), I think a the (possibly expanded) (B) option is the best. I say that because (a) I prefer to not add a new contract like this for a bug-fix release and (b) the concern about the immediate contract change in 6. If we all deem that this is acceptable, I's be fine with (C) as well. On Fri, Sep 1, 2017 at 4:14 PM Gail Badner wrote: > Hi Steve, > > No, I didn't hear back from you. > > I asked for a response to an email sent to hibernate-dev mailing list with > subject, "HHH-11898: more "empty" composite issues". > > You can ignore the first message and just read the 2nd one. > > Thanks, > Gail > > On Fri, Sep 1, 2017 at 12:53 PM, Steve Ebersole > wrote: > >> You asked me to comment on an email, I'm sorry but I don't remember if I >> did. Did I respond to you? > > > From guillaume.smet at gmail.com Mon Sep 4 08:23:13 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 4 Sep 2017 14:23:13 +0200 Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release? In-Reply-To: References: Message-ID: Gail, Thanks for your insight. Yoann confirmed it's a Search issue previously hidden by the previous ORM behavior. He's working on a fix. On my side, I submitted all the PRs I had in mind for 5.2.11. There is still https://github.com/hibernate/hibernate-orm/pull/1998 that should be reviewed (I think it's really nice to have for the users so that they don't face weird deprecation warnings on things that shouldn't be deprecated). -- Guillaume On Thu, Aug 31, 2017 at 8:44 PM, Gail Badner wrote: > Guillaume and Yoann, > > FYI, I took a look and added a comment to https://hibernate. > atlassian.net/browse/HSEARCH-2865. > > Regards, > Gail > > On Thu, Aug 31, 2017 at 9:07 AM, Guillaume Smet > wrote: > >> Gail, >> >> FWIW, I also discovered https://hibernate.atlassian.ne >> t/browse/HSEARCH-2865 today. Let's be sure it's not an ORM issue before >> releasing 5.2.11.Final. >> >> Yoann is going to take a look at it on Monday so we should be fixed soon. >> >> -- >> Guillaume >> >> On Wed, Aug 30, 2017 at 4:48 PM, Guillaume Smet > > wrote: >> >>> Hi, >>> >>> FYI, I posted the last PR of the OGM series today: >>> https://github.com/hibernate/hibernate-orm/pull/1997 . >>> >>> I expect some discussion about it in the next few days as it's not that >>> straightforward. >>> >>> -- >>> Guillaume >>> >>> On Fri, Aug 25, 2017 at 7:24 PM, Gail Badner wrote: >>> >>>> That's fine. I can wait for you to finish. Let me know when you're done >>>> with what you need to do. >>>> >>>> On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet < >>>> guillaume.smet at gmail.com> wrote: >>>> >>>>> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner >>>>> wrote: >>>>> >>>>>> I can do it next week. I've tentatively set the release date for >>>>>> Wednesday, 8/30. >>>>>> >>>>>> Guillaume, does that give you enough time to make your changes? >>>>>> >>>>> >>>>> I'm expecting discussions on one of the patch I want to submit so not >>>>> sure we'll be able to cut it off on Wednesday. >>>>> >>>>> Still struggling with getting all our OGM tests to pass but I have >>>>> good hope I will be able to send the ORM patches soon. >>>>> >>>>> -- >>>>> Guillaume >>>>> >>>>> >>>> >>> >> > From yoann at hibernate.org Mon Sep 4 11:45:40 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 4 Sep 2017 17:45:40 +0200 Subject: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release? In-Reply-To: References: Message-ID: Hi Gail, We have a fix on the Hibernate Search side and I confirmed the fix should not involve any retro-compatibility issue, so we can treat this issue as non-blocking for the ORM release. Thanks, Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 4 September 2017 at 14:23, Guillaume Smet wrote: > Gail, > > Thanks for your insight. Yoann confirmed it's a Search issue previously > hidden by the previous ORM behavior. > > He's working on a fix. > > On my side, I submitted all the PRs I had in mind for 5.2.11. There is > still https://github.com/hibernate/hibernate-orm/pull/1998 that should be > reviewed (I think it's really nice to have for the users so that they don't > face weird deprecation warnings on things that shouldn't be deprecated). > > -- > Guillaume > > On Thu, Aug 31, 2017 at 8:44 PM, Gail Badner wrote: > >> Guillaume and Yoann, >> >> FYI, I took a look and added a comment to https://hibernate.atlassia >> n.net/browse/HSEARCH-2865. >> >> Regards, >> Gail >> >> On Thu, Aug 31, 2017 at 9:07 AM, Guillaume Smet > > wrote: >> >>> Gail, >>> >>> FWIW, I also discovered https://hibernate.atlassian.ne >>> t/browse/HSEARCH-2865 today. Let's be sure it's not an ORM issue before >>> releasing 5.2.11.Final. >>> >>> Yoann is going to take a look at it on Monday so we should be fixed soon. >>> >>> -- >>> Guillaume >>> >>> On Wed, Aug 30, 2017 at 4:48 PM, Guillaume Smet < >>> guillaume.smet at gmail.com> wrote: >>> >>>> Hi, >>>> >>>> FYI, I posted the last PR of the OGM series today: >>>> https://github.com/hibernate/hibernate-orm/pull/1997 . >>>> >>>> I expect some discussion about it in the next few days as it's not that >>>> straightforward. >>>> >>>> -- >>>> Guillaume >>>> >>>> On Fri, Aug 25, 2017 at 7:24 PM, Gail Badner >>>> wrote: >>>> >>>>> That's fine. I can wait for you to finish. Let me know when you're >>>>> done with what you need to do. >>>>> >>>>> On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet < >>>>> guillaume.smet at gmail.com> wrote: >>>>> >>>>>> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner >>>>>> wrote: >>>>>> >>>>>>> I can do it next week. I've tentatively set the release date for >>>>>>> Wednesday, 8/30. >>>>>>> >>>>>>> Guillaume, does that give you enough time to make your changes? >>>>>>> >>>>>> >>>>>> I'm expecting discussions on one of the patch I want to submit so not >>>>>> sure we'll be able to cut it off on Wednesday. >>>>>> >>>>>> Still struggling with getting all our OGM tests to pass but I have >>>>>> good hope I will be able to send the ORM patches soon. >>>>>> >>>>>> -- >>>>>> Guillaume >>>>>> >>>>>> >>>>> >>>> >>> >> > From emmanuel at hibernate.org Wed Sep 6 03:21:15 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 6 Sep 2017 09:21:15 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release Message-ID: Hey all, I was trying to answer the following question, what is roughly new between 5.6, 5.7 and 5.8 (minor releases)? My first reflex was to go to http://hibernate.org/search/downloads/ to read about the onliner per release. Except it?s a onliner per micro release and ?minor adjustments? for 5.6.3.Final gave me literally no info whatsoever. My second reflex was to go to http://hibernate.org/search/roadmap/ to find a historical entry about older versions and the main changes in bullet points. No luck. It only talks about the future. My third reflex was to go to http://in.relation.to/hibernate-search/ I ended up giving up midway page 2 of the list of blog entries. It?s a mix of simultaneous parallel releases with what?s new since the last CR or the last micro kind of reports and gave up in dismay at the energy I would have to spend to extract what?s new for a full minor release. I did exaggerate a bit the third point but I did give up. We need somewhere a summary page of what?s new per minor releases. I think the roadmap page could be the host. Likewise, we might need a oneliner entry in the download section (per release) that points to this minor release summary. Thoughts? Speaking of roadmap: - HV roadmap is massively out of date - OGM is lying a bit on the future but at least has the past summary I was talking about - Search has a good future roadmap but no past Emmanuek From yoann at hibernate.org Wed Sep 6 03:37:34 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 6 Sep 2017 09:37:34 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Hey, About Search, true, the information is somewhat hidden in many blog posts. I'm not sure the roadmap is the right place, though, since we probably want the format to be different for past and future releases: information for past releases is typically more precise and more verbose, with code examples and so on. See for instance this blog post: http://in.relation.to/ 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future roadmap would be drowned in the past releases. I was thinking about another problem: we don't have a compatibility matrix. We only have a few dependencies (mainly ORM and Lucene), but it's really hard to know which versions of the dependencies to use with which version of Search, and users frequently use the wrong versions. With that in mind, I would rather see a "Versions" page, with a summary at the top (including a one-liner for each minor and the compatibilty matrix), and one section for each minor (with anchors, so that we can link to them from other pages such as the downloads). Or maybe even one page for the detail of each minor, if there's too much text. I think it would make sense to have all that information gathered in a single place, because all of that is needed for users to pick the version they want: they need to know the benefits of upgrading (features) but also the constraints (compatibility matrix). Maybe I can give it a try at the end of the week? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 6 September 2017 at 09:21, Emmanuel Bernard wrote: > Hey all, > > I was trying to answer the following question, what is roughly new between > 5.6, 5.7 and 5.8 (minor releases)? > > My first reflex was to go to http://hibernate.org/search/downloads/ < > http://hibernate.org/search/downloads/> to read about the onliner per > release. Except it?s a onliner per micro release and ?minor adjustments? > for 5.6.3.Final gave me literally no info whatsoever. > > My second reflex was to go to http://hibernate.org/search/roadmap/ < > http://hibernate.org/search/roadmap/> to find a historical entry about > older versions and the main changes in bullet points. No luck. It only > talks about the future. > > My third reflex was to go to http://in.relation.to/hibernate-search/ < > http://in.relation.to/hibernate-search/> I ended up giving up midway page > 2 of the list of blog entries. It?s a mix of simultaneous parallel releases > with what?s new since the last CR or the last micro kind of reports and > gave up in dismay at the energy I would have to spend to extract what?s new > for a full minor release. > > I did exaggerate a bit the third point but I did give up. We need > somewhere a summary page of what?s new per minor releases. I think the > roadmap page could be the host. > Likewise, we might need a oneliner entry in the download section (per > release) that points to this minor release summary. > > Thoughts? > > Speaking of roadmap: > - HV roadmap is massively out of date > - OGM is lying a bit on the future but at least has the past summary I was > talking about > - Search has a good future roadmap but no past > > Emmanuek > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From marko.prykladna at gmail.com Wed Sep 6 03:55:52 2017 From: marko.prykladna at gmail.com (Marko Bekhta) Date: Wed, 6 Sep 2017 09:55:52 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Hi Emmanuel, I did some updates to HV roadmap with this PR [1]. There's also some updates to HV contribute page. Maybe somebody could check those changes and if needed add more to what is present, if what is already there is fine. Have a nice day, Marko [1] https://github.com/hibernate/hibernate.org/pull/123. 2017-09-06 9:37 GMT+02:00 Yoann Rodiere : > Hey, > > About Search, true, the information is somewhat hidden in many blog posts. > I'm not sure the roadmap is the right place, though, since we probably want > the format to be different for past and future releases: information for > past releases is typically more precise and more verbose, with code > examples and so on. See for instance this blog post: > http://in.relation.to/ > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future roadmap > would be drowned in the past releases. > > I was thinking about another problem: we don't have a compatibility matrix. > We only have a few dependencies (mainly ORM and Lucene), but it's really > hard to know which versions of the dependencies to use with which version > of Search, and users frequently use the wrong versions. > With that in mind, I would rather see a "Versions" page, with a summary at > the top (including a one-liner for each minor and the compatibilty matrix), > and one section for each minor (with anchors, so that we can link to them > from other pages such as the downloads). Or maybe even one page for the > detail of each minor, if there's too much text. > I think it would make sense to have all that information gathered in a > single place, because all of that is needed for users to pick the version > they want: they need to know the benefits of upgrading (features) but also > the constraints (compatibility matrix). > Maybe I can give it a try at the end of the week? > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 6 September 2017 at 09:21, Emmanuel Bernard > wrote: > > > Hey all, > > > > I was trying to answer the following question, what is roughly new > between > > 5.6, 5.7 and 5.8 (minor releases)? > > > > My first reflex was to go to http://hibernate.org/search/downloads/ < > > http://hibernate.org/search/downloads/> to read about the onliner per > > release. Except it?s a onliner per micro release and ?minor adjustments? > > for 5.6.3.Final gave me literally no info whatsoever. > > > > My second reflex was to go to http://hibernate.org/search/roadmap/ < > > http://hibernate.org/search/roadmap/> to find a historical entry about > > older versions and the main changes in bullet points. No luck. It only > > talks about the future. > > > > My third reflex was to go to http://in.relation.to/hibernate-search/ < > > http://in.relation.to/hibernate-search/> I ended up giving up midway > page > > 2 of the list of blog entries. It?s a mix of simultaneous parallel > releases > > with what?s new since the last CR or the last micro kind of reports and > > gave up in dismay at the energy I would have to spend to extract what?s > new > > for a full minor release. > > > > I did exaggerate a bit the third point but I did give up. We need > > somewhere a summary page of what?s new per minor releases. I think the > > roadmap page could be the host. > > Likewise, we might need a oneliner entry in the download section (per > > release) that points to this minor release summary. > > > > Thoughts? > > > > Speaking of roadmap: > > - HV roadmap is massively out of date > > - OGM is lying a bit on the future but at least has the past summary I > was > > talking about > > - Search has a good future roadmap but no past > > > > Emmanuek > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Sep 6 04:12:33 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 6 Sep 2017 10:12:33 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: @Marko, Yes, I plan to review them this week and add additional things to it! On Wed, Sep 6, 2017 at 9:55 AM, Marko Bekhta wrote: > Hi Emmanuel, > > I did some updates to HV roadmap with this PR [1]. There's also some > updates to > HV contribute page. Maybe somebody could check those changes and if needed > add > more to what is present, if what is already there is fine. > > Have a nice day, > Marko > > [1] https://github.com/hibernate/hibernate.org/pull/123. > > 2017-09-06 9:37 GMT+02:00 Yoann Rodiere : > > > Hey, > > > > About Search, true, the information is somewhat hidden in many blog > posts. > > I'm not sure the roadmap is the right place, though, since we probably > want > > the format to be different for past and future releases: information for > > past releases is typically more precise and more verbose, with code > > examples and so on. See for instance this blog post: > > http://in.relation.to/ > > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future roadmap > > would be drowned in the past releases. > > > > I was thinking about another problem: we don't have a compatibility > matrix. > > We only have a few dependencies (mainly ORM and Lucene), but it's really > > hard to know which versions of the dependencies to use with which version > > of Search, and users frequently use the wrong versions. > > With that in mind, I would rather see a "Versions" page, with a summary > at > > the top (including a one-liner for each minor and the compatibilty > matrix), > > and one section for each minor (with anchors, so that we can link to them > > from other pages such as the downloads). Or maybe even one page for the > > detail of each minor, if there's too much text. > > I think it would make sense to have all that information gathered in a > > single place, because all of that is needed for users to pick the version > > they want: they need to know the benefits of upgrading (features) but > also > > the constraints (compatibility matrix). > > Maybe I can give it a try at the end of the week? > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 6 September 2017 at 09:21, Emmanuel Bernard > > wrote: > > > > > Hey all, > > > > > > I was trying to answer the following question, what is roughly new > > between > > > 5.6, 5.7 and 5.8 (minor releases)? > > > > > > My first reflex was to go to http://hibernate.org/search/downloads/ < > > > http://hibernate.org/search/downloads/> to read about the onliner per > > > release. Except it?s a onliner per micro release and ?minor > adjustments? > > > for 5.6.3.Final gave me literally no info whatsoever. > > > > > > My second reflex was to go to http://hibernate.org/search/roadmap/ < > > > http://hibernate.org/search/roadmap/> to find a historical entry about > > > older versions and the main changes in bullet points. No luck. It only > > > talks about the future. > > > > > > My third reflex was to go to http://in.relation.to/hibernate-search/ < > > > http://in.relation.to/hibernate-search/> I ended up giving up midway > > page > > > 2 of the list of blog entries. It?s a mix of simultaneous parallel > > releases > > > with what?s new since the last CR or the last micro kind of reports and > > > gave up in dismay at the energy I would have to spend to extract what?s > > new > > > for a full minor release. > > > > > > I did exaggerate a bit the third point but I did give up. We need > > > somewhere a summary page of what?s new per minor releases. I think the > > > roadmap page could be the host. > > > Likewise, we might need a oneliner entry in the download section (per > > > release) that points to this minor release summary. > > > > > > Thoughts? > > > > > > Speaking of roadmap: > > > - HV roadmap is massively out of date > > > - OGM is lying a bit on the future but at least has the past summary I > > was > > > talking about > > > - Search has a good future roadmap but no past > > > > > > Emmanuek > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Sep 6 05:17:08 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 6 Sep 2017 10:17:08 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Thanks for that Emmanuel. I'll fix the one-liner describing the release, I believe we had already noticed this in the past: they need to describe the whole minor not the micro update. The Search roadmap actually also needs a little re-touch, I'll propose a PR for that too. Regarding past roadmaps: I don't like to clutter the roadmap page with the previous copies, especially as they should have a different nature of not being a plan but being a record of what was actually done. Also, we did agree in past meetings to remove all the old ones. e.g. we never ported the release notes for version 3.x and 4.x as back then we decided this was no place for that. Happy to revisit this decision but let's separate them: What about a "past releases" page at the same level of roadmap, and linking to it both from the main Search menu and the roadmap? +1 for Yoann's proposal to re-introduce the compatibility matrix (there was one ~6 years ago). I also had proposed to reintroduce it more recently, and was not done on the grounds that it gets out of date quickly. Still users badly need it so unless someone has a better idea, let's agree on trying to keep it up to date manually. Let's try structure it in such a way that it won't need to be updated for every single release. Thanks, Sanne On 6 September 2017 at 08:37, Yoann Rodiere wrote: > Hey, > > About Search, true, the information is somewhat hidden in many blog posts. > I'm not sure the roadmap is the right place, though, since we probably want > the format to be different for past and future releases: information for > past releases is typically more precise and more verbose, with code > examples and so on. See for instance this blog post: http://in.relation.to/ > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future roadmap > would be drowned in the past releases. > > I was thinking about another problem: we don't have a compatibility matrix. > We only have a few dependencies (mainly ORM and Lucene), but it's really > hard to know which versions of the dependencies to use with which version > of Search, and users frequently use the wrong versions. > With that in mind, I would rather see a "Versions" page, with a summary at > the top (including a one-liner for each minor and the compatibilty matrix), > and one section for each minor (with anchors, so that we can link to them > from other pages such as the downloads). Or maybe even one page for the > detail of each minor, if there's too much text. > I think it would make sense to have all that information gathered in a > single place, because all of that is needed for users to pick the version > they want: they need to know the benefits of upgrading (features) but also > the constraints (compatibility matrix). > Maybe I can give it a try at the end of the week? > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 6 September 2017 at 09:21, Emmanuel Bernard > wrote: > >> Hey all, >> >> I was trying to answer the following question, what is roughly new between >> 5.6, 5.7 and 5.8 (minor releases)? >> >> My first reflex was to go to http://hibernate.org/search/downloads/ < >> http://hibernate.org/search/downloads/> to read about the onliner per >> release. Except it?s a onliner per micro release and ?minor adjustments? >> for 5.6.3.Final gave me literally no info whatsoever. >> >> My second reflex was to go to http://hibernate.org/search/roadmap/ < >> http://hibernate.org/search/roadmap/> to find a historical entry about >> older versions and the main changes in bullet points. No luck. It only >> talks about the future. >> >> My third reflex was to go to http://in.relation.to/hibernate-search/ < >> http://in.relation.to/hibernate-search/> I ended up giving up midway page >> 2 of the list of blog entries. It?s a mix of simultaneous parallel releases >> with what?s new since the last CR or the last micro kind of reports and >> gave up in dismay at the energy I would have to spend to extract what?s new >> for a full minor release. >> >> I did exaggerate a bit the third point but I did give up. We need >> somewhere a summary page of what?s new per minor releases. I think the >> roadmap page could be the host. >> Likewise, we might need a oneliner entry in the download section (per >> release) that points to this minor release summary. >> >> Thoughts? >> >> Speaking of roadmap: >> - HV roadmap is massively out of date >> - OGM is lying a bit on the future but at least has the past summary I was >> talking about >> - Search has a good future roadmap but no past >> >> Emmanuek >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Sep 6 11:16:41 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 06 Sep 2017 15:16:41 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: This is something I brought up ages ago wrt ORM. I wanted something (although ideally integrated with the "more version friendly" hibernate.org design) similar to what I did atm on the ORM GitHub wiki. For example, for 5.2 we have: - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 - https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 The format could be better and some of this information could be combined (release notes and migration guide e.g.). But bear in mind that this was just what I put together to illustrate what I was wanted to do, generally speaking - so its a bit "rough" On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero wrote: > Thanks for that Emmanuel. > > I'll fix the one-liner describing the release, I believe we had > already noticed this in the past: they need to describe the whole > minor not the micro update. > The Search roadmap actually also needs a little re-touch, I'll propose > a PR for that too. > > Regarding past roadmaps: I don't like to clutter the roadmap page with > the previous copies, especially as they should have a different nature > of not being a plan but being a record of what was actually done. > Also, we did agree in past meetings to remove all the old ones. e.g. > we never ported the release notes for version 3.x and 4.x as back then > we decided this was no place for that. Happy to revisit this decision > but let's separate them: > > What about a "past releases" page at the same level of roadmap, and > linking to it both from the main Search menu and the roadmap? > > +1 for Yoann's proposal to re-introduce the compatibility matrix > (there was one ~6 years ago). I also had proposed to reintroduce it > more recently, and was not done on the grounds that it gets out of > date quickly. > Still users badly need it so unless someone has a better idea, let's > agree on trying to keep it up to date manually. Let's try structure it > in such a way that it won't need to be updated for every single > release. > > Thanks, > Sanne > > > On 6 September 2017 at 08:37, Yoann Rodiere wrote: > > Hey, > > > > About Search, true, the information is somewhat hidden in many blog > posts. > > I'm not sure the roadmap is the right place, though, since we probably > want > > the format to be different for past and future releases: information for > > past releases is typically more precise and more verbose, with code > > examples and so on. See for instance this blog post: > http://in.relation.to/ > > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future roadmap > > would be drowned in the past releases. > > > > I was thinking about another problem: we don't have a compatibility > matrix. > > We only have a few dependencies (mainly ORM and Lucene), but it's really > > hard to know which versions of the dependencies to use with which version > > of Search, and users frequently use the wrong versions. > > With that in mind, I would rather see a "Versions" page, with a summary > at > > the top (including a one-liner for each minor and the compatibilty > matrix), > > and one section for each minor (with anchors, so that we can link to them > > from other pages such as the downloads). Or maybe even one page for the > > detail of each minor, if there's too much text. > > I think it would make sense to have all that information gathered in a > > single place, because all of that is needed for users to pick the version > > they want: they need to know the benefits of upgrading (features) but > also > > the constraints (compatibility matrix). > > Maybe I can give it a try at the end of the week? > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 6 September 2017 at 09:21, Emmanuel Bernard > > wrote: > > > >> Hey all, > >> > >> I was trying to answer the following question, what is roughly new > between > >> 5.6, 5.7 and 5.8 (minor releases)? > >> > >> My first reflex was to go to http://hibernate.org/search/downloads/ < > >> http://hibernate.org/search/downloads/> to read about the onliner per > >> release. Except it?s a onliner per micro release and ?minor adjustments? > >> for 5.6.3.Final gave me literally no info whatsoever. > >> > >> My second reflex was to go to http://hibernate.org/search/roadmap/ < > >> http://hibernate.org/search/roadmap/> to find a historical entry about > >> older versions and the main changes in bullet points. No luck. It only > >> talks about the future. > >> > >> My third reflex was to go to http://in.relation.to/hibernate-search/ < > >> http://in.relation.to/hibernate-search/> I ended up giving up midway > page > >> 2 of the list of blog entries. It?s a mix of simultaneous parallel > releases > >> with what?s new since the last CR or the last micro kind of reports and > >> gave up in dismay at the energy I would have to spend to extract what?s > new > >> for a full minor release. > >> > >> I did exaggerate a bit the third point but I did give up. We need > >> somewhere a summary page of what?s new per minor releases. I think the > >> roadmap page could be the host. > >> Likewise, we might need a oneliner entry in the download section (per > >> release) that points to this minor release summary. > >> > >> Thoughts? > >> > >> Speaking of roadmap: > >> - HV roadmap is massively out of date > >> - OGM is lying a bit on the future but at least has the past summary I > was > >> talking about > >> - Search has a good future roadmap but no past > >> > >> Emmanuek > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Sep 6 17:19:31 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 6 Sep 2017 22:19:31 +0100 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: Hi Gail, the failing test is CDIInjectionIT from my personal branch of Hibernate Search called "WildFly11" : https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java It is an Arquillian test and it requires you to build Hibernate ORM master first, as I switched the dependencies to use Hibernate ORM 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires HHH-11950 Thanks, Sanne On 1 September 2017 at 19:11, Gail Badner wrote: > I have a better understanding after discussing further with Scott, so I > agree with Steve now. > > I have some ideas about how to fix this. > > Sanne, you mentioned getting a failure using an integration test. Please > provide details for reproducing this. > > On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole > wrote: >> >> The whole purpose of ExtendedBeanManager is cases where the BeanManager is >> not available when Hibernate boots (in other words when Hibernate is told >> which to use) . This is a way to give Hibernate a callback when the >> BeanManager is available. IMO this ExtendedBeanManager implementing >> BeanManager is inaccurate. But would certainly like to hear Scott's opinion >> as well. >> >> Technically this situation is non-JPA compliant as JPA requires that the >> BeanManager passed to be available at boot-time. >> >> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero >> wrote: >>> >>> Hi Gail, >>> >>> no I haven't opened a WFLY issue as I'm not sure if this is an issue. >>> >>> There seems to be some inconsistency and it certainly breaks some >>> Hibernate Search tests but we could of course adapt things to the new >>> reality.. if this is how it's meant to be. >>> >>> The source code of the ExtendedBeanManager which you didn't find is >>> located in the WildFly source code; it's part of JipiJapa: >>> - >>> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java >>> >>> As you also noticed, it no longer implement the standard BeanManager >>> interface. I agree with you that I'd expect it to still implement it, >>> but clearly this was changed intentionally so I hope someone (Scott >>> possibly?) can clarify - or revert. >>> >>> In case this is intentionally no longer implementing the standard >>> interface we should at least clarify the javadocs if this >>> configuration property. >>> >>> The missing javax.el.ELResolver and javax.el.ExpressionFactory is >>> unfortunate. I'd hope we could do better than just add them back, >>> maybe it requires a dedicated module? Having too many dependencies - >>> in this case half of Weld - slows down our bootstrap significantly and >>> users have been complaining about that. >>> >>> Thanks, >>> Sanne >>> >>> On 30 August 2017 at 06:58, Gail Badner wrote: >>> > Hi Sanne, >>> > >>> > Do you have a WFLY issue for this? >>> > >>> > I've tentatively created a branch and pushed a commit to my fork that >>> > reproduces this issue. [1] >>> > >>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT. >>> > >>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an >>> > implementation, ExtendedBeanManagerImpl [2], that implements both >>> > BeanManager, ExtendedBeanManager. >>> > >>> > I don't see this test in 5.2, and I don't see any implementation of >>> > ExtendedBeanManager in 5.2. I do see tests in >>> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to look >>> > at >>> > those yet. >>> > >>> > I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >>> > should implement javax.enterprise.inject.spi.BeanManager as well. I >>> > tried >>> > making this change, and having BeanManager methods delegate to >>> > HibernateExtendedBeanManager#beanManager, but it looks like a >>> > dependency is >>> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory are >>> > unresolved. >>> > >>> > Please let me know if I'm on the right (or wrong) track. I'll pick this >>> > up >>> > tomorrow. >>> > >>> > Regards, >>> > Gail >>> > >>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >>> > [2] >>> > >>> > https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195 >>> > >>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero >>> > wrote: >>> >> >>> >> Hi all, >>> >> >>> >> In Hibernate Search we have a snippet of code doing: >>> >> >>> >> private static BeanManager getBeanManager(Map >>> >> configurationValues) { >>> >> return (BeanManager) configurationValues.get( >>> >> AvailableSettings.CDI_BEAN_MANAGER ); >>> >> } >>> >> >>> >> This used to work on WildFly 10 - even if we were to override the >>> >> Hibernate ORM version to 5.2. >>> >> >>> >> By runnning the same integration test on WildFly 11 I'm now getting a >>> >> ClassCastException as the returned instance is of type >>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does >>> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but >>> >> does not implement the standard >>> >> `javax.enterprise.inject.spi.BeanManager` interface. >>> >> >>> >> I'm unsure if this is a bug in the Search code or a misunderstanding >>> >> between the WildFly / ORM integration? >>> >> >>> >> This javadoc seems relevant: >>> >> >>> >> /** >>> >> * Used to pass along the CDI BeanManager, if any, to be used. >>> >> */ >>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >>> >> >>> >> or should I interpret this property as meant only for "write" purposes >>> >> into the ORM configuration? I suppose it's unexpected that we attempt >>> >> to retrieve this as well. >>> >> >>> >> Thanks, >>> >> Sanne >>> >> _______________________________________________ >>> >> hibernate-dev mailing list >>> >> hibernate-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From rory.odonnell at oracle.com Thu Sep 7 05:35:49 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 7 Sep 2017 10:35:49 +0100 Subject: [hibernate-dev] Moving Java Forward Faster Message-ID: Hi Sanne, Oracle is proposing a rapid release model for Java SE going-forward. The high points are highlighted below, details of the changes can be found on Mark Reinhold?s blog [1] , OpenJDK discussion email list [2]. Under the proposed release model, after JDK 9, we will adopt a strict, time-based model with a new major release every six months, update releases every quarter, and a long-term support release every three years. The new JDK Project will run a bit differently than the past "JDK $N" Projects: - The main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished. The main line will be Feature Complete [3] at all times. - We'll continue to use the JEP Process [4] for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration. The JDK Updates Project will run in much the same way as the past "JDK $N" Updates Projects, though update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Related to this proposal, we intend to make a few changes in what we do: - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to make it easier for developers to deploy Java applications to cloud environments. We'll initially publish OpenJDK builds for Linux/x64, followed later by builds for macOS/x64 and Windows/x64. - We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" [6] such as Java Flight Recorder and Mission Control [7], under a click-through binary-code license [8]. Oracle will continue to offer paid support for these builds. - After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable. - Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK. Questions , comments, feedback to OpenJDK discuss mailing list [2] Rgds,Rory [1]https://mreinhold.org/blog/forward-faster [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [4]http://openjdk.java.net/jeps/0 [5]http://openjdk.java.net/legal/gplv2+ce.html [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html From sanne at hibernate.org Thu Sep 7 06:22:21 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 7 Sep 2017 11:22:21 +0100 Subject: [hibernate-dev] Moving Java Forward Faster In-Reply-To: References: Message-ID: Hi Rory, thank you very much for this heads up! Opening up the build-and-test infrastructure and the commercial components sounds like an amazing development. Some early thoughts. The methodology of faster release cycles is very welcome, yet the proposed versioning I saw mentioned on twitter to be "year based" is a bit puzzling: in our experience it's nice to be able to clearly differentiate a non-backwards compatible version from a backwards compatible version, and yet be in control of when an "incompatibility event" happens: that can't be time boxed as generally we all try to avoid it but sometimes innovation requires to. I guess we could agree that technically no changed software is fully backwards compatible from all perspectives, but people are aware of this and yet benefit from knowing the maintainer's intent. This seems to map to the "long term support" editions but then those LTS versions only become the "version" in people's perspective. Specifically my concern would be that different versions would be perceived as a significant migration risk even though such an update might be relatively much simpler than others. It's possible that in practice Java 10 already had some breaking changes planned so this concern wouldn't apply right now, but with such numbering you'll never be able to benefit from it even in future releases. I'd welcome faster innovation cycles but libraries like Hibernate can't drop support for JVMs still largely in use, so unless people get comfortable in adopting new JVM versions by removing any such mental barriers we won't be able to adopt new versions as fast as we'd all like. On the other hand if the suggestion is that libraries should generally target "long term support" platforms, then it becomes painfully slow: as in other OSS projects - like Fedora - practical needs dictate that you at least support the two latest platforms so that would force us to support 6+ years old JVMs and slow innovation down rather than speeding it up. (Fedora supports the last two releases but a new release appears every 6 months). We'll think about this in the team and see if it's worth sharing some more thoughts on the OpenJDK mailing list. Regards, Sanne On 7 September 2017 at 10:35, Rory O'Donnell wrote: > Hi Sanne, > > Oracle is proposing a rapid release model for Java SE going-forward. > > The high points are highlighted below, details of the changes can be > found on Mark Reinhold?s blog [1] , OpenJDK discussion email list [2]. > > Under the proposed release model, after JDK 9, we will adopt a strict, > time-based model with a new major release every six months, update > releases every quarter, and a long-term support release every three years. > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The main > line will be Feature Complete [3] at all times. > > - We'll continue to use the JEP Process [4] for new features and other > significant changes. The bar to target a JEP to a specific release will, > however, be higher since the work must be Feature Complete in order to > go in. Owners of large or risky features will be strongly encouraged to > split such features up into smaller and safer parts, to integrate > earlier in the release cycle, and to publish separate lines of > early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK > $N" Updates Projects, though update releases will be strictly limited to > fixes of security issues, regressions, and bugs in newer features. > > Related to this proposal, we intend to make a few changes in what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [6] such as Java Flight Recorder and Mission > Control [7], under a click-through binary-code license [8]. Oracle will > continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to make > the OpenJDK builds more attractive to developers and to reduce the > differences between those builds and the Oracle JDK. This will take some > time, but the ultimate goal is to make OpenJDK and Oracle JDK builds > completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make it > easier to publish early-access builds for features in development, and > eventually make it possible for the OpenJDK Community itself to publish > authoritative builds of the JDK. > > Questions , comments, feedback to OpenJDK discuss mailing list [2] > > Rgds,Rory > > [1]https://mreinhold.org/blog/forward-faster > [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [4]http://openjdk.java.net/jeps/0 > [5]http://openjdk.java.net/legal/gplv2+ce.html > [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html > [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Thu Sep 7 06:26:43 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 7 Sep 2017 11:26:43 +0100 Subject: [hibernate-dev] Moving Java Forward Faster In-Reply-To: References: Message-ID: <58e6e0ea-8d43-9487-756a-f1ee0fec0655@oracle.com> Hi Sanne, Please do share your thoughts on the OpenJDK mailing list. Rgds,Rory On 07/09/2017 11:22, Sanne Grinovero wrote: > Hi Rory, > > thank you very much for this heads up! Opening up the build-and-test > infrastructure and the commercial components sounds like an amazing > development. > > Some early thoughts. The methodology of faster release cycles is very > welcome, yet the proposed versioning I saw mentioned on twitter to be > "year based" is a bit puzzling: in our experience it's nice to be able > to clearly differentiate a non-backwards compatible version from a > backwards compatible version, and yet be in control of when an > "incompatibility event" happens: that can't be time boxed as generally > we all try to avoid it but sometimes innovation requires to. > > I guess we could agree that technically no changed software is fully > backwards compatible from all perspectives, but people are aware of > this and yet benefit from knowing the maintainer's intent. This seems > to map to the "long term support" editions but then those LTS versions > only become the "version" in people's perspective. Specifically my > concern would be that different versions would be perceived as a > significant migration risk even though such an update might be > relatively much simpler than others. It's possible that in practice > Java 10 already had some breaking changes planned so this concern > wouldn't apply right now, but with such numbering you'll never be able > to benefit from it even in future releases. > I'd welcome faster innovation cycles but libraries like Hibernate > can't drop support for JVMs still largely in use, so unless people get > comfortable in adopting new JVM versions by removing any such mental > barriers we won't be able to adopt new versions as fast as we'd all > like. On the other hand if the suggestion is that libraries should > generally target "long term support" platforms, then it becomes > painfully slow: as in other OSS projects - like Fedora - practical > needs dictate that you at least support the two latest platforms so > that would force us to support 6+ years old JVMs and slow innovation > down rather than speeding it up. (Fedora supports the last two > releases but a new release appears every 6 months). > > We'll think about this in the team and see if it's worth sharing some > more thoughts on the OpenJDK mailing list. > > Regards, > Sanne > > > > On 7 September 2017 at 10:35, Rory O'Donnell wrote: >> Hi Sanne, >> >> Oracle is proposing a rapid release model for Java SE going-forward. >> >> The high points are highlighted below, details of the changes can be >> found on Mark Reinhold?s blog [1] , OpenJDK discussion email list [2]. >> >> Under the proposed release model, after JDK 9, we will adopt a strict, >> time-based model with a new major release every six months, update >> releases every quarter, and a long-term support release every three years. >> >> The new JDK Project will run a bit differently than the past "JDK $N" >> Projects: >> >> - The main development line will always be open but fixes, enhancements, >> and features will be merged only when they're nearly finished. The main >> line will be Feature Complete [3] at all times. >> >> - We'll continue to use the JEP Process [4] for new features and other >> significant changes. The bar to target a JEP to a specific release will, >> however, be higher since the work must be Feature Complete in order to >> go in. Owners of large or risky features will be strongly encouraged to >> split such features up into smaller and safer parts, to integrate >> earlier in the release cycle, and to publish separate lines of >> early-access builds prior to integration. >> >> The JDK Updates Project will run in much the same way as the past "JDK >> $N" Updates Projects, though update releases will be strictly limited to >> fixes of security issues, regressions, and bugs in newer features. >> >> Related to this proposal, we intend to make a few changes in what we do: >> >> - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to >> make it easier for developers to deploy Java applications to cloud >> environments. We'll initially publish OpenJDK builds for Linux/x64, >> followed later by builds for macOS/x64 and Windows/x64. >> >> - We'll continue to ship proprietary "Oracle JDK" builds, which include >> "commercial features" [6] such as Java Flight Recorder and Mission >> Control [7], under a click-through binary-code license [8]. Oracle will >> continue to offer paid support for these builds. >> >> - After JDK 9 we'll open-source the commercial features in order to make >> the OpenJDK builds more attractive to developers and to reduce the >> differences between those builds and the Oracle JDK. This will take some >> time, but the ultimate goal is to make OpenJDK and Oracle JDK builds >> completely interchangeable. >> >> - Finally, for the long term we'll work with other OpenJDK contributors >> to establish an open build-and-test infrastructure. This will make it >> easier to publish early-access builds for features in development, and >> eventually make it possible for the OpenJDK Community itself to publish >> authoritative builds of the JDK. >> >> Questions , comments, feedback to OpenJDK discuss mailing list [2] >> >> Rgds,Rory >> >> [1]https://mreinhold.org/blog/forward-faster >> [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html >> [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete >> [4]http://openjdk.java.net/jeps/0 >> [5]http://openjdk.java.net/legal/gplv2+ce.html >> [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html >> [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html >> [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Thu Sep 7 13:36:31 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 7 Sep 2017 18:36:31 +0100 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: I had a chat with Steve about this and I understand better now why the WildFly/JipiJapa/HibernateORM does what it does. We'll update the Hibernate Search integration test and move on! Thanks, Sanne On 6 September 2017 at 22:19, Sanne Grinovero wrote: > Hi Gail, > > the failing test is CDIInjectionIT from my personal branch of > Hibernate Search called "WildFly11" : > > https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java > > It is an Arquillian test and it requires you to build Hibernate ORM > master first, as I switched the dependencies to use Hibernate ORM > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires > HHH-11950 > > Thanks, > Sanne > > > On 1 September 2017 at 19:11, Gail Badner wrote: >> I have a better understanding after discussing further with Scott, so I >> agree with Steve now. >> >> I have some ideas about how to fix this. >> >> Sanne, you mentioned getting a failure using an integration test. Please >> provide details for reproducing this. >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole >> wrote: >>> >>> The whole purpose of ExtendedBeanManager is cases where the BeanManager is >>> not available when Hibernate boots (in other words when Hibernate is told >>> which to use) . This is a way to give Hibernate a callback when the >>> BeanManager is available. IMO this ExtendedBeanManager implementing >>> BeanManager is inaccurate. But would certainly like to hear Scott's opinion >>> as well. >>> >>> Technically this situation is non-JPA compliant as JPA requires that the >>> BeanManager passed to be available at boot-time. >>> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero >>> wrote: >>>> >>>> Hi Gail, >>>> >>>> no I haven't opened a WFLY issue as I'm not sure if this is an issue. >>>> >>>> There seems to be some inconsistency and it certainly breaks some >>>> Hibernate Search tests but we could of course adapt things to the new >>>> reality.. if this is how it's meant to be. >>>> >>>> The source code of the ExtendedBeanManager which you didn't find is >>>> located in the WildFly source code; it's part of JipiJapa: >>>> - >>>> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java >>>> >>>> As you also noticed, it no longer implement the standard BeanManager >>>> interface. I agree with you that I'd expect it to still implement it, >>>> but clearly this was changed intentionally so I hope someone (Scott >>>> possibly?) can clarify - or revert. >>>> >>>> In case this is intentionally no longer implementing the standard >>>> interface we should at least clarify the javadocs if this >>>> configuration property. >>>> >>>> The missing javax.el.ELResolver and javax.el.ExpressionFactory is >>>> unfortunate. I'd hope we could do better than just add them back, >>>> maybe it requires a dedicated module? Having too many dependencies - >>>> in this case half of Weld - slows down our bootstrap significantly and >>>> users have been complaining about that. >>>> >>>> Thanks, >>>> Sanne >>>> >>>> On 30 August 2017 at 06:58, Gail Badner wrote: >>>> > Hi Sanne, >>>> > >>>> > Do you have a WFLY issue for this? >>>> > >>>> > I've tentatively created a branch and pushed a commit to my fork that >>>> > reproduces this issue. [1] >>>> > >>>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT. >>>> > >>>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an >>>> > implementation, ExtendedBeanManagerImpl [2], that implements both >>>> > BeanManager, ExtendedBeanManager. >>>> > >>>> > I don't see this test in 5.2, and I don't see any implementation of >>>> > ExtendedBeanManager in 5.2. I do see tests in >>>> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to look >>>> > at >>>> > those yet. >>>> > >>>> > I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >>>> > should implement javax.enterprise.inject.spi.BeanManager as well. I >>>> > tried >>>> > making this change, and having BeanManager methods delegate to >>>> > HibernateExtendedBeanManager#beanManager, but it looks like a >>>> > dependency is >>>> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory are >>>> > unresolved. >>>> > >>>> > Please let me know if I'm on the right (or wrong) track. I'll pick this >>>> > up >>>> > tomorrow. >>>> > >>>> > Regards, >>>> > Gail >>>> > >>>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >>>> > [2] >>>> > >>>> > https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195 >>>> > >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero >>>> > wrote: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> In Hibernate Search we have a snippet of code doing: >>>> >> >>>> >> private static BeanManager getBeanManager(Map >>>> >> configurationValues) { >>>> >> return (BeanManager) configurationValues.get( >>>> >> AvailableSettings.CDI_BEAN_MANAGER ); >>>> >> } >>>> >> >>>> >> This used to work on WildFly 10 - even if we were to override the >>>> >> Hibernate ORM version to 5.2. >>>> >> >>>> >> By runnning the same integration test on WildFly 11 I'm now getting a >>>> >> ClassCastException as the returned instance is of type >>>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does >>>> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but >>>> >> does not implement the standard >>>> >> `javax.enterprise.inject.spi.BeanManager` interface. >>>> >> >>>> >> I'm unsure if this is a bug in the Search code or a misunderstanding >>>> >> between the WildFly / ORM integration? >>>> >> >>>> >> This javadoc seems relevant: >>>> >> >>>> >> /** >>>> >> * Used to pass along the CDI BeanManager, if any, to be used. >>>> >> */ >>>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >>>> >> >>>> >> or should I interpret this property as meant only for "write" purposes >>>> >> into the ORM configuration? I suppose it's unexpected that we attempt >>>> >> to retrieve this as well. >>>> >> >>>> >> Thanks, >>>> >> Sanne >>>> >> _______________________________________________ >>>> >> hibernate-dev mailing list >>>> >> hibernate-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> From gbadner at redhat.com Thu Sep 7 17:38:53 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 7 Sep 2017 14:38:53 -0700 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: Are you saying that you don't need a fix for this? On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero wrote: > I had a chat with Steve about this and I understand better now why the > WildFly/JipiJapa/HibernateORM does what it does. > > We'll update the Hibernate Search integration test and move on! > > Thanks, > Sanne > > > On 6 September 2017 at 22:19, Sanne Grinovero wrote: > > Hi Gail, > > > > the failing test is CDIInjectionIT from my personal branch of > > Hibernate Search called "WildFly11" : > > > > https://github.com/Sanne/hibernate-search/blob/ > WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/ > integration/wildfly/cdi/CDIInjectionIT.java > > > > It is an Arquillian test and it requires you to build Hibernate ORM > > master first, as I switched the dependencies to use Hibernate ORM > > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires > > HHH-11950 > > > > Thanks, > > Sanne > > > > > > On 1 September 2017 at 19:11, Gail Badner wrote: > >> I have a better understanding after discussing further with Scott, so I > >> agree with Steve now. > >> > >> I have some ideas about how to fix this. > >> > >> Sanne, you mentioned getting a failure using an integration test. Please > >> provide details for reproducing this. > >> > >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole > >> wrote: > >>> > >>> The whole purpose of ExtendedBeanManager is cases where the > BeanManager is > >>> not available when Hibernate boots (in other words when Hibernate is > told > >>> which to use) . This is a way to give Hibernate a callback when the > >>> BeanManager is available. IMO this ExtendedBeanManager implementing > >>> BeanManager is inaccurate. But would certainly like to hear Scott's > opinion > >>> as well. > >>> > >>> Technically this situation is non-JPA compliant as JPA requires that > the > >>> BeanManager passed to be available at boot-time. > >>> > >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero > >>> wrote: > >>>> > >>>> Hi Gail, > >>>> > >>>> no I haven't opened a WFLY issue as I'm not sure if this is an issue. > >>>> > >>>> There seems to be some inconsistency and it certainly breaks some > >>>> Hibernate Search tests but we could of course adapt things to the new > >>>> reality.. if this is how it's meant to be. > >>>> > >>>> The source code of the ExtendedBeanManager which you didn't find is > >>>> located in the WildFly source code; it's part of JipiJapa: > >>>> - > >>>> https://github.com/wildfly/wildfly/blob/master/jpa/ > hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/ > HibernateExtendedBeanManager.java > >>>> > >>>> As you also noticed, it no longer implement the standard BeanManager > >>>> interface. I agree with you that I'd expect it to still implement it, > >>>> but clearly this was changed intentionally so I hope someone (Scott > >>>> possibly?) can clarify - or revert. > >>>> > >>>> In case this is intentionally no longer implementing the standard > >>>> interface we should at least clarify the javadocs if this > >>>> configuration property. > >>>> > >>>> The missing javax.el.ELResolver and javax.el.ExpressionFactory is > >>>> unfortunate. I'd hope we could do better than just add them back, > >>>> maybe it requires a dedicated module? Having too many dependencies - > >>>> in this case half of Weld - slows down our bootstrap significantly and > >>>> users have been complaining about that. > >>>> > >>>> Thanks, > >>>> Sanne > >>>> > >>>> On 30 August 2017 at 06:58, Gail Badner wrote: > >>>> > Hi Sanne, > >>>> > > >>>> > Do you have a WFLY issue for this? > >>>> > > >>>> > I've tentatively created a branch and pushed a commit to my fork > that > >>>> > reproduces this issue. [1] > >>>> > > >>>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT. > >>>> > > >>>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses > an > >>>> > implementation, ExtendedBeanManagerImpl [2], that implements both > >>>> > BeanManager, ExtendedBeanManager. > >>>> > > >>>> > I don't see this test in 5.2, and I don't see any implementation of > >>>> > ExtendedBeanManager in 5.2. I do see tests in > >>>> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to > look > >>>> > at > >>>> > those yet. > >>>> > > >>>> > I suspect that org.jboss.as.jpa.hibernate5. > HibernateExtendedBeanManager > >>>> > should implement javax.enterprise.inject.spi.BeanManager as well. I > >>>> > tried > >>>> > making this change, and having BeanManager methods delegate to > >>>> > HibernateExtendedBeanManager#beanManager, but it looks like a > >>>> > dependency is > >>>> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory > are > >>>> > unresolved. > >>>> > > >>>> > Please let me know if I'm on the right (or wrong) track. I'll pick > this > >>>> > up > >>>> > tomorrow. > >>>> > > >>>> > Regards, > >>>> > Gail > >>>> > > >>>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug > >>>> > [2] > >>>> > > >>>> > https://github.com/hibernate/hibernate-orm/blob/5.1/ > hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ > ExtendedBeanManagerCdiTest.java#L195 > >>>> > > >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero < > sanne at hibernate.org> > >>>> > wrote: > >>>> >> > >>>> >> Hi all, > >>>> >> > >>>> >> In Hibernate Search we have a snippet of code doing: > >>>> >> > >>>> >> private static BeanManager getBeanManager(Map > >>>> >> configurationValues) { > >>>> >> return (BeanManager) configurationValues.get( > >>>> >> AvailableSettings.CDI_BEAN_MANAGER ); > >>>> >> } > >>>> >> > >>>> >> This used to work on WildFly 10 - even if we were to override the > >>>> >> Hibernate ORM version to 5.2. > >>>> >> > >>>> >> By runnning the same integration test on WildFly 11 I'm now > getting a > >>>> >> ClassCastException as the returned instance is of type > >>>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which > does > >>>> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` > but > >>>> >> does not implement the standard > >>>> >> `javax.enterprise.inject.spi.BeanManager` interface. > >>>> >> > >>>> >> I'm unsure if this is a bug in the Search code or a > misunderstanding > >>>> >> between the WildFly / ORM integration? > >>>> >> > >>>> >> This javadoc seems relevant: > >>>> >> > >>>> >> /** > >>>> >> * Used to pass along the CDI BeanManager, if any, to be used. > >>>> >> */ > >>>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; > >>>> >> > >>>> >> or should I interpret this property as meant only for "write" > purposes > >>>> >> into the ORM configuration? I suppose it's unexpected that we > attempt > >>>> >> to retrieve this as well. > >>>> >> > >>>> >> Thanks, > >>>> >> Sanne > >>>> >> _______________________________________________ > >>>> >> hibernate-dev mailing list > >>>> >> hibernate-dev at lists.jboss.org > >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> hibernate-dev mailing list > >>>> hibernate-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > From sanne at hibernate.org Thu Sep 7 17:59:40 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 7 Sep 2017 22:59:40 +0100 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: On 7 September 2017 at 22:38, Gail Badner wrote: > Are you saying that you don't need a fix for this? I'm going to need fixing the Hibernate Search code, but besides that yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa) nor Hibernate ORM. Thanks, Sanne > > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero > wrote: >> >> I had a chat with Steve about this and I understand better now why the >> WildFly/JipiJapa/HibernateORM does what it does. >> >> We'll update the Hibernate Search integration test and move on! >> >> Thanks, >> Sanne >> >> >> On 6 September 2017 at 22:19, Sanne Grinovero wrote: >> > Hi Gail, >> > >> > the failing test is CDIInjectionIT from my personal branch of >> > Hibernate Search called "WildFly11" : >> > >> > >> > https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java >> > >> > It is an Arquillian test and it requires you to build Hibernate ORM >> > master first, as I switched the dependencies to use Hibernate ORM >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires >> > HHH-11950 >> > >> > Thanks, >> > Sanne >> > >> > >> > On 1 September 2017 at 19:11, Gail Badner wrote: >> >> I have a better understanding after discussing further with Scott, so I >> >> agree with Steve now. >> >> >> >> I have some ideas about how to fix this. >> >> >> >> Sanne, you mentioned getting a failure using an integration test. >> >> Please >> >> provide details for reproducing this. >> >> >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole >> >> wrote: >> >>> >> >>> The whole purpose of ExtendedBeanManager is cases where the >> >>> BeanManager is >> >>> not available when Hibernate boots (in other words when Hibernate is >> >>> told >> >>> which to use) . This is a way to give Hibernate a callback when the >> >>> BeanManager is available. IMO this ExtendedBeanManager implementing >> >>> BeanManager is inaccurate. But would certainly like to hear Scott's >> >>> opinion >> >>> as well. >> >>> >> >>> Technically this situation is non-JPA compliant as JPA requires that >> >>> the >> >>> BeanManager passed to be available at boot-time. >> >>> >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero >> >>> wrote: >> >>>> >> >>>> Hi Gail, >> >>>> >> >>>> no I haven't opened a WFLY issue as I'm not sure if this is an issue. >> >>>> >> >>>> There seems to be some inconsistency and it certainly breaks some >> >>>> Hibernate Search tests but we could of course adapt things to the new >> >>>> reality.. if this is how it's meant to be. >> >>>> >> >>>> The source code of the ExtendedBeanManager which you didn't find is >> >>>> located in the WildFly source code; it's part of JipiJapa: >> >>>> - >> >>>> >> >>>> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java >> >>>> >> >>>> As you also noticed, it no longer implement the standard BeanManager >> >>>> interface. I agree with you that I'd expect it to still implement it, >> >>>> but clearly this was changed intentionally so I hope someone (Scott >> >>>> possibly?) can clarify - or revert. >> >>>> >> >>>> In case this is intentionally no longer implementing the standard >> >>>> interface we should at least clarify the javadocs if this >> >>>> configuration property. >> >>>> >> >>>> The missing javax.el.ELResolver and javax.el.ExpressionFactory is >> >>>> unfortunate. I'd hope we could do better than just add them back, >> >>>> maybe it requires a dedicated module? Having too many dependencies - >> >>>> in this case half of Weld - slows down our bootstrap significantly >> >>>> and >> >>>> users have been complaining about that. >> >>>> >> >>>> Thanks, >> >>>> Sanne >> >>>> >> >>>> On 30 August 2017 at 06:58, Gail Badner wrote: >> >>>> > Hi Sanne, >> >>>> > >> >>>> > Do you have a WFLY issue for this? >> >>>> > >> >>>> > I've tentatively created a branch and pushed a commit to my fork >> >>>> > that >> >>>> > reproduces this issue. [1] >> >>>> > >> >>>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT. >> >>>> > >> >>>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses >> >>>> > an >> >>>> > implementation, ExtendedBeanManagerImpl [2], that implements both >> >>>> > BeanManager, ExtendedBeanManager. >> >>>> > >> >>>> > I don't see this test in 5.2, and I don't see any implementation of >> >>>> > ExtendedBeanManager in 5.2. I do see tests in >> >>>> > org.hibernate.jpa.test.cdi.extended, but have not had a chance to >> >>>> > look >> >>>> > at >> >>>> > those yet. >> >>>> > >> >>>> > I suspect that >> >>>> > org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >> >>>> > should implement javax.enterprise.inject.spi.BeanManager as well. I >> >>>> > tried >> >>>> > making this change, and having BeanManager methods delegate to >> >>>> > HibernateExtendedBeanManager#beanManager, but it looks like a >> >>>> > dependency is >> >>>> > missing, because javax.el.ELResolver and javax.el.ExpressionFactory >> >>>> > are >> >>>> > unresolved. >> >>>> > >> >>>> > Please let me know if I'm on the right (or wrong) track. I'll pick >> >>>> > this >> >>>> > up >> >>>> > tomorrow. >> >>>> > >> >>>> > Regards, >> >>>> > Gail >> >>>> > >> >>>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >> >>>> > [2] >> >>>> > >> >>>> > >> >>>> > https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195 >> >>>> > >> >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero >> >>>> > >> >>>> > wrote: >> >>>> >> >> >>>> >> Hi all, >> >>>> >> >> >>>> >> In Hibernate Search we have a snippet of code doing: >> >>>> >> >> >>>> >> private static BeanManager getBeanManager(Map >> >>>> >> configurationValues) { >> >>>> >> return (BeanManager) configurationValues.get( >> >>>> >> AvailableSettings.CDI_BEAN_MANAGER ); >> >>>> >> } >> >>>> >> >> >>>> >> This used to work on WildFly 10 - even if we were to override the >> >>>> >> Hibernate ORM version to 5.2. >> >>>> >> >> >>>> >> By runnning the same integration test on WildFly 11 I'm now >> >>>> >> getting a >> >>>> >> ClassCastException as the returned instance is of type >> >>>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which >> >>>> >> does >> >>>> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` >> >>>> >> but >> >>>> >> does not implement the standard >> >>>> >> `javax.enterprise.inject.spi.BeanManager` interface. >> >>>> >> >> >>>> >> I'm unsure if this is a bug in the Search code or a >> >>>> >> misunderstanding >> >>>> >> between the WildFly / ORM integration? >> >>>> >> >> >>>> >> This javadoc seems relevant: >> >>>> >> >> >>>> >> /** >> >>>> >> * Used to pass along the CDI BeanManager, if any, to be used. >> >>>> >> */ >> >>>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >> >>>> >> >> >>>> >> or should I interpret this property as meant only for "write" >> >>>> >> purposes >> >>>> >> into the ORM configuration? I suppose it's unexpected that we >> >>>> >> attempt >> >>>> >> to retrieve this as well. >> >>>> >> >> >>>> >> Thanks, >> >>>> >> Sanne >> >>>> >> _______________________________________________ >> >>>> >> hibernate-dev mailing list >> >>>> >> hibernate-dev at lists.jboss.org >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>> > >> >>>> > >> >>>> _______________________________________________ >> >>>> hibernate-dev mailing list >> >>>> hibernate-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> > > From gbadner at redhat.com Thu Sep 7 18:38:03 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 7 Sep 2017 15:38:03 -0700 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: OK, sounds good. Did Steve suggest how to fix it in HSearch? If he didn't, I have kind of a hacky idea. On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero wrote: > On 7 September 2017 at 22:38, Gail Badner wrote: > > Are you saying that you don't need a fix for this? > > I'm going to need fixing the Hibernate Search code, but besides that > yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa) > nor Hibernate ORM. > > Thanks, > Sanne > > > > > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero > > wrote: > >> > >> I had a chat with Steve about this and I understand better now why the > >> WildFly/JipiJapa/HibernateORM does what it does. > >> > >> We'll update the Hibernate Search integration test and move on! > >> > >> Thanks, > >> Sanne > >> > >> > >> On 6 September 2017 at 22:19, Sanne Grinovero > wrote: > >> > Hi Gail, > >> > > >> > the failing test is CDIInjectionIT from my personal branch of > >> > Hibernate Search called "WildFly11" : > >> > > >> > > >> > https://github.com/Sanne/hibernate-search/blob/ > WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/ > integration/wildfly/cdi/CDIInjectionIT.java > >> > > >> > It is an Arquillian test and it requires you to build Hibernate ORM > >> > master first, as I switched the dependencies to use Hibernate ORM > >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires > >> > HHH-11950 > >> > > >> > Thanks, > >> > Sanne > >> > > >> > > >> > On 1 September 2017 at 19:11, Gail Badner wrote: > >> >> I have a better understanding after discussing further with Scott, > so I > >> >> agree with Steve now. > >> >> > >> >> I have some ideas about how to fix this. > >> >> > >> >> Sanne, you mentioned getting a failure using an integration test. > >> >> Please > >> >> provide details for reproducing this. > >> >> > >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole < > steve at hibernate.org> > >> >> wrote: > >> >>> > >> >>> The whole purpose of ExtendedBeanManager is cases where the > >> >>> BeanManager is > >> >>> not available when Hibernate boots (in other words when Hibernate is > >> >>> told > >> >>> which to use) . This is a way to give Hibernate a callback when the > >> >>> BeanManager is available. IMO this ExtendedBeanManager implementing > >> >>> BeanManager is inaccurate. But would certainly like to hear Scott's > >> >>> opinion > >> >>> as well. > >> >>> > >> >>> Technically this situation is non-JPA compliant as JPA requires that > >> >>> the > >> >>> BeanManager passed to be available at boot-time. > >> >>> > >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero < > sanne at hibernate.org> > >> >>> wrote: > >> >>>> > >> >>>> Hi Gail, > >> >>>> > >> >>>> no I haven't opened a WFLY issue as I'm not sure if this is an > issue. > >> >>>> > >> >>>> There seems to be some inconsistency and it certainly breaks some > >> >>>> Hibernate Search tests but we could of course adapt things to the > new > >> >>>> reality.. if this is how it's meant to be. > >> >>>> > >> >>>> The source code of the ExtendedBeanManager which you didn't find is > >> >>>> located in the WildFly source code; it's part of JipiJapa: > >> >>>> - > >> >>>> > >> >>>> https://github.com/wildfly/wildfly/blob/master/jpa/ > hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/ > HibernateExtendedBeanManager.java > >> >>>> > >> >>>> As you also noticed, it no longer implement the standard > BeanManager > >> >>>> interface. I agree with you that I'd expect it to still implement > it, > >> >>>> but clearly this was changed intentionally so I hope someone (Scott > >> >>>> possibly?) can clarify - or revert. > >> >>>> > >> >>>> In case this is intentionally no longer implementing the standard > >> >>>> interface we should at least clarify the javadocs if this > >> >>>> configuration property. > >> >>>> > >> >>>> The missing javax.el.ELResolver and javax.el.ExpressionFactory is > >> >>>> unfortunate. I'd hope we could do better than just add them back, > >> >>>> maybe it requires a dedicated module? Having too many dependencies > - > >> >>>> in this case half of Weld - slows down our bootstrap significantly > >> >>>> and > >> >>>> users have been complaining about that. > >> >>>> > >> >>>> Thanks, > >> >>>> Sanne > >> >>>> > >> >>>> On 30 August 2017 at 06:58, Gail Badner > wrote: > >> >>>> > Hi Sanne, > >> >>>> > > >> >>>> > Do you have a WFLY issue for this? > >> >>>> > > >> >>>> > I've tentatively created a branch and pushed a commit to my fork > >> >>>> > that > >> >>>> > reproduces this issue. [1] > >> >>>> > > >> >>>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and > 5.2.11-SNAPSHOT. > >> >>>> > > >> >>>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest > uses > >> >>>> > an > >> >>>> > implementation, ExtendedBeanManagerImpl [2], that implements both > >> >>>> > BeanManager, ExtendedBeanManager. > >> >>>> > > >> >>>> > I don't see this test in 5.2, and I don't see any implementation > of > >> >>>> > ExtendedBeanManager in 5.2. I do see tests in > >> >>>> > org.hibernate.jpa.test.cdi.extended, but have not had a chance > to > >> >>>> > look > >> >>>> > at > >> >>>> > those yet. > >> >>>> > > >> >>>> > I suspect that > >> >>>> > org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager > >> >>>> > should implement javax.enterprise.inject.spi.BeanManager as > well. I > >> >>>> > tried > >> >>>> > making this change, and having BeanManager methods delegate to > >> >>>> > HibernateExtendedBeanManager#beanManager, but it looks like a > >> >>>> > dependency is > >> >>>> > missing, because javax.el.ELResolver and > javax.el.ExpressionFactory > >> >>>> > are > >> >>>> > unresolved. > >> >>>> > > >> >>>> > Please let me know if I'm on the right (or wrong) track. I'll > pick > >> >>>> > this > >> >>>> > up > >> >>>> > tomorrow. > >> >>>> > > >> >>>> > Regards, > >> >>>> > Gail > >> >>>> > > >> >>>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug > >> >>>> > [2] > >> >>>> > > >> >>>> > > >> >>>> > https://github.com/hibernate/hibernate-orm/blob/5.1/ > hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ > ExtendedBeanManagerCdiTest.java#L195 > >> >>>> > > >> >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero > >> >>>> > > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> Hi all, > >> >>>> >> > >> >>>> >> In Hibernate Search we have a snippet of code doing: > >> >>>> >> > >> >>>> >> private static BeanManager getBeanManager(Map > >> >>>> >> configurationValues) { > >> >>>> >> return (BeanManager) configurationValues.get( > >> >>>> >> AvailableSettings.CDI_BEAN_MANAGER ); > >> >>>> >> } > >> >>>> >> > >> >>>> >> This used to work on WildFly 10 - even if we were to override > the > >> >>>> >> Hibernate ORM version to 5.2. > >> >>>> >> > >> >>>> >> By runnning the same integration test on WildFly 11 I'm now > >> >>>> >> getting a > >> >>>> >> ClassCastException as the returned instance is of type > >> >>>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, > which > >> >>>> >> does > >> >>>> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` > >> >>>> >> but > >> >>>> >> does not implement the standard > >> >>>> >> `javax.enterprise.inject.spi.BeanManager` interface. > >> >>>> >> > >> >>>> >> I'm unsure if this is a bug in the Search code or a > >> >>>> >> misunderstanding > >> >>>> >> between the WildFly / ORM integration? > >> >>>> >> > >> >>>> >> This javadoc seems relevant: > >> >>>> >> > >> >>>> >> /** > >> >>>> >> * Used to pass along the CDI BeanManager, if any, to be used. > >> >>>> >> */ > >> >>>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; > >> >>>> >> > >> >>>> >> or should I interpret this property as meant only for "write" > >> >>>> >> purposes > >> >>>> >> into the ORM configuration? I suppose it's unexpected that we > >> >>>> >> attempt > >> >>>> >> to retrieve this as well. > >> >>>> >> > >> >>>> >> Thanks, > >> >>>> >> Sanne > >> >>>> >> _______________________________________________ > >> >>>> >> hibernate-dev mailing list > >> >>>> >> hibernate-dev at lists.jboss.org > >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>> > > >> >>>> > > >> >>>> _______________________________________________ > >> >>>> hibernate-dev mailing list > >> >>>> hibernate-dev at lists.jboss.org > >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > >> >> > > > > > From steve at hibernate.org Thu Sep 7 19:28:34 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 07 Sep 2017 23:28:34 +0000 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: My suggestion to Sanne (not sure if he was going to take this approach) was to essentially copy the way I handle this in 6 : https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi/spi/ManagedBeanRegistry.java On Thu, Sep 7, 2017, 5:38 PM Gail Badner wrote: > OK, sounds good. Did Steve suggest how to fix it in HSearch? If he didn't, > I have kind of a hacky idea. > > On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero > wrote: > >> On 7 September 2017 at 22:38, Gail Badner wrote: >> > Are you saying that you don't need a fix for this? >> >> I'm going to need fixing the Hibernate Search code, but besides that >> yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa) >> nor Hibernate ORM. >> >> Thanks, >> Sanne >> >> > >> > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero >> > wrote: >> >> >> >> I had a chat with Steve about this and I understand better now why the >> >> WildFly/JipiJapa/HibernateORM does what it does. >> >> >> >> We'll update the Hibernate Search integration test and move on! >> >> >> >> Thanks, >> >> Sanne >> >> >> >> >> >> On 6 September 2017 at 22:19, Sanne Grinovero >> wrote: >> >> > Hi Gail, >> >> > >> >> > the failing test is CDIInjectionIT from my personal branch of >> >> > Hibernate Search called "WildFly11" : >> >> > >> >> > >> >> > >> https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java >> >> > >> >> > It is an Arquillian test and it requires you to build Hibernate ORM >> >> > master first, as I switched the dependencies to use Hibernate ORM >> >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires >> >> > HHH-11950 >> >> > >> >> > Thanks, >> >> > Sanne >> >> > >> >> > >> >> > On 1 September 2017 at 19:11, Gail Badner >> wrote: >> >> >> I have a better understanding after discussing further with Scott, >> so I >> >> >> agree with Steve now. >> >> >> >> >> >> I have some ideas about how to fix this. >> >> >> >> >> >> Sanne, you mentioned getting a failure using an integration test. >> >> >> Please >> >> >> provide details for reproducing this. >> >> >> >> >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole < >> steve at hibernate.org> >> >> >> wrote: >> >> >>> >> >> >>> The whole purpose of ExtendedBeanManager is cases where the >> >> >>> BeanManager is >> >> >>> not available when Hibernate boots (in other words when Hibernate >> is >> >> >>> told >> >> >>> which to use) . This is a way to give Hibernate a callback when >> the >> >> >>> BeanManager is available. IMO this ExtendedBeanManager >> implementing >> >> >>> BeanManager is inaccurate. But would certainly like to hear >> Scott's >> >> >>> opinion >> >> >>> as well. >> >> >>> >> >> >>> Technically this situation is non-JPA compliant as JPA requires >> that >> >> >>> the >> >> >>> BeanManager passed to be available at boot-time. >> >> >>> >> >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero < >> sanne at hibernate.org> >> >> >>> wrote: >> >> >>>> >> >> >>>> Hi Gail, >> >> >>>> >> >> >>>> no I haven't opened a WFLY issue as I'm not sure if this is an >> issue. >> >> >>>> >> >> >>>> There seems to be some inconsistency and it certainly breaks some >> >> >>>> Hibernate Search tests but we could of course adapt things to the >> new >> >> >>>> reality.. if this is how it's meant to be. >> >> >>>> >> >> >>>> The source code of the ExtendedBeanManager which you didn't find >> is >> >> >>>> located in the WildFly source code; it's part of JipiJapa: >> >> >>>> - >> >> >>>> >> >> >>>> >> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java >> >> >>>> >> >> >>>> As you also noticed, it no longer implement the standard >> BeanManager >> >> >>>> interface. I agree with you that I'd expect it to still implement >> it, >> >> >>>> but clearly this was changed intentionally so I hope someone >> (Scott >> >> >>>> possibly?) can clarify - or revert. >> >> >>>> >> >> >>>> In case this is intentionally no longer implementing the standard >> >> >>>> interface we should at least clarify the javadocs if this >> >> >>>> configuration property. >> >> >>>> >> >> >>>> The missing javax.el.ELResolver and javax.el.ExpressionFactory is >> >> >>>> unfortunate. I'd hope we could do better than just add them back, >> >> >>>> maybe it requires a dedicated module? Having too many >> dependencies - >> >> >>>> in this case half of Weld - slows down our bootstrap significantly >> >> >>>> and >> >> >>>> users have been complaining about that. >> >> >>>> >> >> >>>> Thanks, >> >> >>>> Sanne >> >> >>>> >> >> >>>> On 30 August 2017 at 06:58, Gail Badner >> wrote: >> >> >>>> > Hi Sanne, >> >> >>>> > >> >> >>>> > Do you have a WFLY issue for this? >> >> >>>> > >> >> >>>> > I've tentatively created a branch and pushed a commit to my fork >> >> >>>> > that >> >> >>>> > reproduces this issue. [1] >> >> >>>> > >> >> >>>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and >> 5.2.11-SNAPSHOT. >> >> >>>> > >> >> >>>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest >> uses >> >> >>>> > an >> >> >>>> > implementation, ExtendedBeanManagerImpl [2], that implements >> both >> >> >>>> > BeanManager, ExtendedBeanManager. >> >> >>>> > >> >> >>>> > I don't see this test in 5.2, and I don't see any >> implementation of >> >> >>>> > ExtendedBeanManager in 5.2. I do see tests in >> >> >>>> > org.hibernate.jpa.test.cdi.extended, but have not had a chance >> to >> >> >>>> > look >> >> >>>> > at >> >> >>>> > those yet. >> >> >>>> > >> >> >>>> > I suspect that >> >> >>>> > org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >> >> >>>> > should implement javax.enterprise.inject.spi.BeanManager as >> well. I >> >> >>>> > tried >> >> >>>> > making this change, and having BeanManager methods delegate to >> >> >>>> > HibernateExtendedBeanManager#beanManager, but it looks like a >> >> >>>> > dependency is >> >> >>>> > missing, because javax.el.ELResolver and >> javax.el.ExpressionFactory >> >> >>>> > are >> >> >>>> > unresolved. >> >> >>>> > >> >> >>>> > Please let me know if I'm on the right (or wrong) track. I'll >> pick >> >> >>>> > this >> >> >>>> > up >> >> >>>> > tomorrow. >> >> >>>> > >> >> >>>> > Regards, >> >> >>>> > Gail >> >> >>>> > >> >> >>>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >> >> >>>> > [2] >> >> >>>> > >> >> >>>> > >> >> >>>> > >> https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195 >> >> >>>> > >> >> >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero >> >> >>>> > >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> Hi all, >> >> >>>> >> >> >> >>>> >> In Hibernate Search we have a snippet of code doing: >> >> >>>> >> >> >> >>>> >> private static BeanManager getBeanManager(Map >> >> >>>> >> configurationValues) { >> >> >>>> >> return (BeanManager) configurationValues.get( >> >> >>>> >> AvailableSettings.CDI_BEAN_MANAGER ); >> >> >>>> >> } >> >> >>>> >> >> >> >>>> >> This used to work on WildFly 10 - even if we were to override >> the >> >> >>>> >> Hibernate ORM version to 5.2. >> >> >>>> >> >> >> >>>> >> By runnning the same integration test on WildFly 11 I'm now >> >> >>>> >> getting a >> >> >>>> >> ClassCastException as the returned instance is of type >> >> >>>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, >> which >> >> >>>> >> does >> >> >>>> >> implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` >> >> >>>> >> but >> >> >>>> >> does not implement the standard >> >> >>>> >> `javax.enterprise.inject.spi.BeanManager` interface. >> >> >>>> >> >> >> >>>> >> I'm unsure if this is a bug in the Search code or a >> >> >>>> >> misunderstanding >> >> >>>> >> between the WildFly / ORM integration? >> >> >>>> >> >> >> >>>> >> This javadoc seems relevant: >> >> >>>> >> >> >> >>>> >> /** >> >> >>>> >> * Used to pass along the CDI BeanManager, if any, to be used. >> >> >>>> >> */ >> >> >>>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >> >> >>>> >> >> >> >>>> >> or should I interpret this property as meant only for "write" >> >> >>>> >> purposes >> >> >>>> >> into the ORM configuration? I suppose it's unexpected that we >> >> >>>> >> attempt >> >> >>>> >> to retrieve this as well. >> >> >>>> >> >> >> >>>> >> Thanks, >> >> >>>> >> Sanne >> >> >>>> >> _______________________________________________ >> >> >>>> >> hibernate-dev mailing list >> >> >>>> >> hibernate-dev at lists.jboss.org >> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >>>> > >> >> >>>> > >> >> >>>> _______________________________________________ >> >> >>>> hibernate-dev mailing list >> >> >>>> hibernate-dev at lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> >> >> > >> > >> > > From gbadner at redhat.com Fri Sep 8 01:10:06 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 7 Sep 2017 22:10:06 -0700 Subject: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing In-Reply-To: References: Message-ID: That's a better solution than what I had in mind. On Thu, Sep 7, 2017 at 4:28 PM, Steve Ebersole wrote: > My suggestion to Sanne (not sure if he was going to take this approach) > was to essentially copy the way I handle this in 6 : > https://github.com/sebersole/hibernate-core/blob/wip/6.0/ > hibernate-core/src/main/java/org/hibernate/resource/cdi/ > spi/ManagedBeanRegistry.java > > On Thu, Sep 7, 2017, 5:38 PM Gail Badner wrote: > >> OK, sounds good. Did Steve suggest how to fix it in HSearch? If he >> didn't, I have kind of a hacky idea. >> >> On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero >> wrote: >> >>> On 7 September 2017 at 22:38, Gail Badner wrote: >>> > Are you saying that you don't need a fix for this? >>> >>> I'm going to need fixing the Hibernate Search code, but besides that >>> yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa) >>> nor Hibernate ORM. >>> >>> Thanks, >>> Sanne >>> >>> > >>> > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero >>> > wrote: >>> >> >>> >> I had a chat with Steve about this and I understand better now why the >>> >> WildFly/JipiJapa/HibernateORM does what it does. >>> >> >>> >> We'll update the Hibernate Search integration test and move on! >>> >> >>> >> Thanks, >>> >> Sanne >>> >> >>> >> >>> >> On 6 September 2017 at 22:19, Sanne Grinovero >>> wrote: >>> >> > Hi Gail, >>> >> > >>> >> > the failing test is CDIInjectionIT from my personal branch of >>> >> > Hibernate Search called "WildFly11" : >>> >> > >>> >> > >>> >> > https://github.com/Sanne/hibernate-search/blob/ >>> WildFly11/integrationtest/wildfly/src/test/java/org/ >>> hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java >>> >> > >>> >> > It is an Arquillian test and it requires you to build Hibernate ORM >>> >> > master first, as I switched the dependencies to use Hibernate ORM >>> >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it >>> requires >>> >> > HHH-11950 >>> >> > >>> >> > Thanks, >>> >> > Sanne >>> >> > >>> >> > >>> >> > On 1 September 2017 at 19:11, Gail Badner >>> wrote: >>> >> >> I have a better understanding after discussing further with Scott, >>> so I >>> >> >> agree with Steve now. >>> >> >> >>> >> >> I have some ideas about how to fix this. >>> >> >> >>> >> >> Sanne, you mentioned getting a failure using an integration test. >>> >> >> Please >>> >> >> provide details for reproducing this. >>> >> >> >>> >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole < >>> steve at hibernate.org> >>> >> >> wrote: >>> >> >>> >>> >> >>> The whole purpose of ExtendedBeanManager is cases where the >>> >> >>> BeanManager is >>> >> >>> not available when Hibernate boots (in other words when Hibernate >>> is >>> >> >>> told >>> >> >>> which to use) . This is a way to give Hibernate a callback when >>> the >>> >> >>> BeanManager is available. IMO this ExtendedBeanManager >>> implementing >>> >> >>> BeanManager is inaccurate. But would certainly like to hear >>> Scott's >>> >> >>> opinion >>> >> >>> as well. >>> >> >>> >>> >> >>> Technically this situation is non-JPA compliant as JPA requires >>> that >>> >> >>> the >>> >> >>> BeanManager passed to be available at boot-time. >>> >> >>> >>> >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero < >>> sanne at hibernate.org> >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> Hi Gail, >>> >> >>>> >>> >> >>>> no I haven't opened a WFLY issue as I'm not sure if this is an >>> issue. >>> >> >>>> >>> >> >>>> There seems to be some inconsistency and it certainly breaks some >>> >> >>>> Hibernate Search tests but we could of course adapt things to >>> the new >>> >> >>>> reality.. if this is how it's meant to be. >>> >> >>>> >>> >> >>>> The source code of the ExtendedBeanManager which you didn't find >>> is >>> >> >>>> located in the WildFly source code; it's part of JipiJapa: >>> >> >>>> - >>> >> >>>> >>> >> >>>> https://github.com/wildfly/wildfly/blob/master/jpa/ >>> hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/ >>> HibernateExtendedBeanManager.java >>> >> >>>> >>> >> >>>> As you also noticed, it no longer implement the standard >>> BeanManager >>> >> >>>> interface. I agree with you that I'd expect it to still >>> implement it, >>> >> >>>> but clearly this was changed intentionally so I hope someone >>> (Scott >>> >> >>>> possibly?) can clarify - or revert. >>> >> >>>> >>> >> >>>> In case this is intentionally no longer implementing the standard >>> >> >>>> interface we should at least clarify the javadocs if this >>> >> >>>> configuration property. >>> >> >>>> >>> >> >>>> The missing javax.el.ELResolver and javax.el.ExpressionFactory >>> is >>> >> >>>> unfortunate. I'd hope we could do better than just add them back, >>> >> >>>> maybe it requires a dedicated module? Having too many >>> dependencies - >>> >> >>>> in this case half of Weld - slows down our bootstrap >>> significantly >>> >> >>>> and >>> >> >>>> users have been complaining about that. >>> >> >>>> >>> >> >>>> Thanks, >>> >> >>>> Sanne >>> >> >>>> >>> >> >>>> On 30 August 2017 at 06:58, Gail Badner >>> wrote: >>> >> >>>> > Hi Sanne, >>> >> >>>> > >>> >> >>>> > Do you have a WFLY issue for this? >>> >> >>>> > >>> >> >>>> > I've tentatively created a branch and pushed a commit to my >>> fork >>> >> >>>> > that >>> >> >>>> > reproduces this issue. [1] >>> >> >>>> > >>> >> >>>> > It reproduces using Hibernate 5.1.11-SNAPSHOT and >>> 5.2.11-SNAPSHOT. >>> >> >>>> > >>> >> >>>> > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest >>> uses >>> >> >>>> > an >>> >> >>>> > implementation, ExtendedBeanManagerImpl [2], that implements >>> both >>> >> >>>> > BeanManager, ExtendedBeanManager. >>> >> >>>> > >>> >> >>>> > I don't see this test in 5.2, and I don't see any >>> implementation of >>> >> >>>> > ExtendedBeanManager in 5.2. I do see tests in >>> >> >>>> > org.hibernate.jpa.test.cdi.extended, but have not had a >>> chance to >>> >> >>>> > look >>> >> >>>> > at >>> >> >>>> > those yet. >>> >> >>>> > >>> >> >>>> > I suspect that >>> >> >>>> > org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager >>> >> >>>> > should implement javax.enterprise.inject.spi.BeanManager as >>> well. I >>> >> >>>> > tried >>> >> >>>> > making this change, and having BeanManager methods delegate to >>> >> >>>> > HibernateExtendedBeanManager#beanManager, but it looks like a >>> >> >>>> > dependency is >>> >> >>>> > missing, because javax.el.ELResolver and >>> javax.el.ExpressionFactory >>> >> >>>> > are >>> >> >>>> > unresolved. >>> >> >>>> > >>> >> >>>> > Please let me know if I'm on the right (or wrong) track. I'll >>> pick >>> >> >>>> > this >>> >> >>>> > up >>> >> >>>> > tomorrow. >>> >> >>>> > >>> >> >>>> > Regards, >>> >> >>>> > Gail >>> >> >>>> > >>> >> >>>> > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug >>> >> >>>> > [2] >>> >> >>>> > >>> >> >>>> > >>> >> >>>> > https://github.com/hibernate/hibernate-orm/blob/5.1/ >>> hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ >>> ExtendedBeanManagerCdiTest.java#L195 >>> >> >>>> > >>> >> >>>> > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero >>> >> >>>> > >>> >> >>>> > wrote: >>> >> >>>> >> >>> >> >>>> >> Hi all, >>> >> >>>> >> >>> >> >>>> >> In Hibernate Search we have a snippet of code doing: >>> >> >>>> >> >>> >> >>>> >> private static BeanManager getBeanManager(Map >>> >> >>>> >> configurationValues) { >>> >> >>>> >> return (BeanManager) configurationValues.get( >>> >> >>>> >> AvailableSettings.CDI_BEAN_MANAGER ); >>> >> >>>> >> } >>> >> >>>> >> >>> >> >>>> >> This used to work on WildFly 10 - even if we were to override >>> the >>> >> >>>> >> Hibernate ORM version to 5.2. >>> >> >>>> >> >>> >> >>>> >> By runnning the same integration test on WildFly 11 I'm now >>> >> >>>> >> getting a >>> >> >>>> >> ClassCastException as the returned instance is of type >>> >> >>>> >> `org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, >>> which >>> >> >>>> >> does >>> >> >>>> >> implement `org.hibernate.jpa.event.spi. >>> jpa.ExtendedBeanManager` >>> >> >>>> >> but >>> >> >>>> >> does not implement the standard >>> >> >>>> >> `javax.enterprise.inject.spi.BeanManager` interface. >>> >> >>>> >> >>> >> >>>> >> I'm unsure if this is a bug in the Search code or a >>> >> >>>> >> misunderstanding >>> >> >>>> >> between the WildFly / ORM integration? >>> >> >>>> >> >>> >> >>>> >> This javadoc seems relevant: >>> >> >>>> >> >>> >> >>>> >> /** >>> >> >>>> >> * Used to pass along the CDI BeanManager, if any, to be used. >>> >> >>>> >> */ >>> >> >>>> >> String CDI_BEAN_MANAGER = "javax.persistence.bean.manager"; >>> >> >>>> >> >>> >> >>>> >> or should I interpret this property as meant only for "write" >>> >> >>>> >> purposes >>> >> >>>> >> into the ORM configuration? I suppose it's unexpected that we >>> >> >>>> >> attempt >>> >> >>>> >> to retrieve this as well. >>> >> >>>> >> >>> >> >>>> >> Thanks, >>> >> >>>> >> Sanne >>> >> >>>> >> _______________________________________________ >>> >> >>>> >> hibernate-dev mailing list >>> >> >>>> >> hibernate-dev at lists.jboss.org >>> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >>>> > >>> >> >>>> > >>> >> >>>> _______________________________________________ >>> >> >>>> hibernate-dev mailing list >>> >> >>>> hibernate-dev at lists.jboss.org >>> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >>> >> >> >>> > >>> > >>> >> >> From yoann at hibernate.org Fri Sep 8 08:53:25 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Sep 2017 14:53:25 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Hey, I pushed an update to staging. I only converted the "Search" part for now. What changes: - The _data folder structured changed a bit, so that we can introduces a YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of this series and a list of integration constraints (ORM > 5.2, etc.) - The "Downloads" page is renamed to "Releases", since, well, it's about more than just downloads. See http://staging.hibernate.org/search/releases/ - The "Releases" page now includes a "Compatibilty matrix" section based on the new data I mentioned above - The "Releases" page now includes links to one page for each series ("More on the 5.8 series") - There is now one page for each series (see http://staging.hibernate.org/search/releases/series/5.8/). This page includes: - A short (one-line) summary of this series - A reminder of the integration constraints for this series - A section about the main changes in this release. I only wrote something for the 5.8 series for now, and I basically copy/pasted sections from various blog posts. - A list of all releases in this series. What I didn't do, but could make sense: - add a sub-menu element under "Releases" for each series - link to the documentation for each of the latest releases from the "Releases" page - link to the latest documentation and to the migration guides from each series' page What do you all think? Emmanuel, would this address your concerns? Steve, would this be a good fit for ORM? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 6 September 2017 at 17:16, Steve Ebersole wrote: > This is something I brought up ages ago wrt ORM. I wanted something > (although ideally integrated with the "more version friendly" > hibernate.org design) similar to what I did atm on the ORM GitHub wiki. > For example, for 5.2 we have: > > > - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 > - https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 > - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 > > > The format could be better and some of this information could be combined > (release notes and migration guide e.g.). But bear in mind that this was > just what I put together to illustrate what I was wanted to do, generally > speaking - so its a bit "rough" > > > On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero > wrote: > >> Thanks for that Emmanuel. >> >> I'll fix the one-liner describing the release, I believe we had >> already noticed this in the past: they need to describe the whole >> minor not the micro update. >> The Search roadmap actually also needs a little re-touch, I'll propose >> a PR for that too. >> >> Regarding past roadmaps: I don't like to clutter the roadmap page with >> the previous copies, especially as they should have a different nature >> of not being a plan but being a record of what was actually done. >> Also, we did agree in past meetings to remove all the old ones. e.g. >> we never ported the release notes for version 3.x and 4.x as back then >> we decided this was no place for that. Happy to revisit this decision >> but let's separate them: >> >> What about a "past releases" page at the same level of roadmap, and >> linking to it both from the main Search menu and the roadmap? >> >> +1 for Yoann's proposal to re-introduce the compatibility matrix >> (there was one ~6 years ago). I also had proposed to reintroduce it >> more recently, and was not done on the grounds that it gets out of >> date quickly. >> Still users badly need it so unless someone has a better idea, let's >> agree on trying to keep it up to date manually. Let's try structure it >> in such a way that it won't need to be updated for every single >> release. >> >> Thanks, >> Sanne >> >> >> On 6 September 2017 at 08:37, Yoann Rodiere wrote: >> > Hey, >> > >> > About Search, true, the information is somewhat hidden in many blog >> posts. >> > I'm not sure the roadmap is the right place, though, since we probably >> want >> > the format to be different for past and future releases: information for >> > past releases is typically more precise and more verbose, with code >> > examples and so on. See for instance this blog post: >> http://in.relation.to/ >> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >> roadmap >> > would be drowned in the past releases. >> > >> > I was thinking about another problem: we don't have a compatibility >> matrix. >> > We only have a few dependencies (mainly ORM and Lucene), but it's really >> > hard to know which versions of the dependencies to use with which >> version >> > of Search, and users frequently use the wrong versions. >> > With that in mind, I would rather see a "Versions" page, with a summary >> at >> > the top (including a one-liner for each minor and the compatibilty >> matrix), >> > and one section for each minor (with anchors, so that we can link to >> them >> > from other pages such as the downloads). Or maybe even one page for the >> > detail of each minor, if there's too much text. >> > I think it would make sense to have all that information gathered in a >> > single place, because all of that is needed for users to pick the >> version >> > they want: they need to know the benefits of upgrading (features) but >> also >> > the constraints (compatibility matrix). >> > Maybe I can give it a try at the end of the week? >> > >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > On 6 September 2017 at 09:21, Emmanuel Bernard >> > wrote: >> > >> >> Hey all, >> >> >> >> I was trying to answer the following question, what is roughly new >> between >> >> 5.6, 5.7 and 5.8 (minor releases)? >> >> >> >> My first reflex was to go to http://hibernate.org/search/downloads/ < >> >> http://hibernate.org/search/downloads/> to read about the onliner per >> >> release. Except it?s a onliner per micro release and ?minor >> adjustments? >> >> for 5.6.3.Final gave me literally no info whatsoever. >> >> >> >> My second reflex was to go to http://hibernate.org/search/roadmap/ < >> >> http://hibernate.org/search/roadmap/> to find a historical entry about >> >> older versions and the main changes in bullet points. No luck. It only >> >> talks about the future. >> >> >> >> My third reflex was to go to http://in.relation.to/hibernate-search/ < >> >> http://in.relation.to/hibernate-search/> I ended up giving up midway >> page >> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >> releases >> >> with what?s new since the last CR or the last micro kind of reports and >> >> gave up in dismay at the energy I would have to spend to extract >> what?s new >> >> for a full minor release. >> >> >> >> I did exaggerate a bit the third point but I did give up. We need >> >> somewhere a summary page of what?s new per minor releases. I think the >> >> roadmap page could be the host. >> >> Likewise, we might need a oneliner entry in the download section (per >> >> release) that points to this minor release summary. >> >> >> >> Thoughts? >> >> >> >> Speaking of roadmap: >> >> - HV roadmap is massively out of date >> >> - OGM is lying a bit on the future but at least has the past summary I >> was >> >> talking about >> >> - Search has a good future roadmap but no past >> >> >> >> Emmanuek >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From sanne at hibernate.org Fri Sep 8 09:11:34 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 8 Sep 2017 14:11:34 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Thanks Yoann! Looks great. Two minor suggestions: - could the two links we have for each release on search/releases/ on two separate lines? Or something else to make it clear that there are two linkes. - Regarding the "Compatibility matrix", the header line (the one in black) .. I think we need to clarify in some way that you're referring to Hibernate Search releases. Possibly just link to the page describing the family? Thanks, Sanne On 8 September 2017 at 13:53, Yoann Rodiere wrote: > Hey, > > I pushed an update to staging. I only converted the "Search" part for now. > What changes: > > The _data folder structured changed a bit, so that we can introduces a YAML > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of this > series and a list of integration constraints (ORM > 5.2, etc.) > The "Downloads" page is renamed to "Releases", since, well, it's about more > than just downloads. See http://staging.hibernate.org/search/releases/ > The "Releases" page now includes a "Compatibilty matrix" section based on > the new data I mentioned above > The "Releases" page now includes links to one page for each series ("More on > the 5.8 series") > There is now one page for each series (see > http://staging.hibernate.org/search/releases/series/5.8/). This page > includes: > > A short (one-line) summary of this series > A reminder of the integration constraints for this series > A section about the main changes in this release. I only wrote something for > the 5.8 series for now, and I basically copy/pasted sections from various > blog posts. > A list of all releases in this series. > > What I didn't do, but could make sense: > > add a sub-menu element under "Releases" for each series > link to the documentation for each of the latest releases from the > "Releases" page > link to the latest documentation and to the migration guides from each > series' page > > What do you all think? Emmanuel, would this address your concerns? Steve, > would this be a good fit for ORM? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 6 September 2017 at 17:16, Steve Ebersole wrote: >> >> This is something I brought up ages ago wrt ORM. I wanted something >> (although ideally integrated with the "more version friendly" hibernate.org >> design) similar to what I did atm on the ORM GitHub wiki. For example, for >> 5.2 we have: >> >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >> >> >> The format could be better and some of this information could be combined >> (release notes and migration guide e.g.). But bear in mind that this was >> just what I put together to illustrate what I was wanted to do, generally >> speaking - so its a bit "rough" >> >> >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >> wrote: >>> >>> Thanks for that Emmanuel. >>> >>> I'll fix the one-liner describing the release, I believe we had >>> already noticed this in the past: they need to describe the whole >>> minor not the micro update. >>> The Search roadmap actually also needs a little re-touch, I'll propose >>> a PR for that too. >>> >>> Regarding past roadmaps: I don't like to clutter the roadmap page with >>> the previous copies, especially as they should have a different nature >>> of not being a plan but being a record of what was actually done. >>> Also, we did agree in past meetings to remove all the old ones. e.g. >>> we never ported the release notes for version 3.x and 4.x as back then >>> we decided this was no place for that. Happy to revisit this decision >>> but let's separate them: >>> >>> What about a "past releases" page at the same level of roadmap, and >>> linking to it both from the main Search menu and the roadmap? >>> >>> +1 for Yoann's proposal to re-introduce the compatibility matrix >>> (there was one ~6 years ago). I also had proposed to reintroduce it >>> more recently, and was not done on the grounds that it gets out of >>> date quickly. >>> Still users badly need it so unless someone has a better idea, let's >>> agree on trying to keep it up to date manually. Let's try structure it >>> in such a way that it won't need to be updated for every single >>> release. >>> >>> Thanks, >>> Sanne >>> >>> >>> On 6 September 2017 at 08:37, Yoann Rodiere wrote: >>> > Hey, >>> > >>> > About Search, true, the information is somewhat hidden in many blog >>> > posts. >>> > I'm not sure the roadmap is the right place, though, since we probably >>> > want >>> > the format to be different for past and future releases: information >>> > for >>> > past releases is typically more precise and more verbose, with code >>> > examples and so on. See for instance this blog post: >>> > http://in.relation.to/ >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >>> > roadmap >>> > would be drowned in the past releases. >>> > >>> > I was thinking about another problem: we don't have a compatibility >>> > matrix. >>> > We only have a few dependencies (mainly ORM and Lucene), but it's >>> > really >>> > hard to know which versions of the dependencies to use with which >>> > version >>> > of Search, and users frequently use the wrong versions. >>> > With that in mind, I would rather see a "Versions" page, with a summary >>> > at >>> > the top (including a one-liner for each minor and the compatibilty >>> > matrix), >>> > and one section for each minor (with anchors, so that we can link to >>> > them >>> > from other pages such as the downloads). Or maybe even one page for the >>> > detail of each minor, if there's too much text. >>> > I think it would make sense to have all that information gathered in a >>> > single place, because all of that is needed for users to pick the >>> > version >>> > they want: they need to know the benefits of upgrading (features) but >>> > also >>> > the constraints (compatibility matrix). >>> > Maybe I can give it a try at the end of the week? >>> > >>> > >>> > Yoann Rodi?re >>> > Hibernate NoORM Team >>> > yoann at hibernate.org >>> > >>> > On 6 September 2017 at 09:21, Emmanuel Bernard >>> > wrote: >>> > >>> >> Hey all, >>> >> >>> >> I was trying to answer the following question, what is roughly new >>> >> between >>> >> 5.6, 5.7 and 5.8 (minor releases)? >>> >> >>> >> My first reflex was to go to http://hibernate.org/search/downloads/ < >>> >> http://hibernate.org/search/downloads/> to read about the onliner per >>> >> release. Except it?s a onliner per micro release and ?minor >>> >> adjustments? >>> >> for 5.6.3.Final gave me literally no info whatsoever. >>> >> >>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ < >>> >> http://hibernate.org/search/roadmap/> to find a historical entry about >>> >> older versions and the main changes in bullet points. No luck. It only >>> >> talks about the future. >>> >> >>> >> My third reflex was to go to http://in.relation.to/hibernate-search/ < >>> >> http://in.relation.to/hibernate-search/> I ended up giving up midway >>> >> page >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >>> >> releases >>> >> with what?s new since the last CR or the last micro kind of reports >>> >> and >>> >> gave up in dismay at the energy I would have to spend to extract >>> >> what?s new >>> >> for a full minor release. >>> >> >>> >> I did exaggerate a bit the third point but I did give up. We need >>> >> somewhere a summary page of what?s new per minor releases. I think the >>> >> roadmap page could be the host. >>> >> Likewise, we might need a oneliner entry in the download section (per >>> >> release) that points to this minor release summary. >>> >> >>> >> Thoughts? >>> >> >>> >> Speaking of roadmap: >>> >> - HV roadmap is massively out of date >>> >> - OGM is lying a bit on the future but at least has the past summary I >>> >> was >>> >> talking about >>> >> - Search has a good future roadmap but no past >>> >> >>> >> Emmanuek >>> >> _______________________________________________ >>> >> hibernate-dev mailing list >>> >> hibernate-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From yoann at hibernate.org Fri Sep 8 09:46:47 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Sep 2017 15:46:47 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Sanne, I addressed both your comments. Is it better? I also addressed Guillaume's comment on HipChat, and made the compatibility matrix a bit... fuzzier, so that we won't have to update it as often. We can still make it very specific if we want to, but we won't be limited by the layout anymore. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 8 September 2017 at 15:11, Sanne Grinovero wrote: > Thanks Yoann! > Looks great. > > Two minor suggestions: > - could the two links we have for each release on search/releases/ on > two separate lines? Or something else to make it clear that there are > two linkes. > - Regarding the "Compatibility matrix", the header line (the one in > black) .. I think we need to clarify in some way that you're referring > to Hibernate Search releases. Possibly just link to the page > describing the family? > > Thanks, > Sanne > > > On 8 September 2017 at 13:53, Yoann Rodiere wrote: > > Hey, > > > > I pushed an update to staging. I only converted the "Search" part for > now. > > What changes: > > > > The _data folder structured changed a bit, so that we can introduces a > YAML > > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of > this > > series and a list of integration constraints (ORM > 5.2, etc.) > > The "Downloads" page is renamed to "Releases", since, well, it's about > more > > than just downloads. See http://staging.hibernate.org/search/releases/ > > The "Releases" page now includes a "Compatibilty matrix" section based on > > the new data I mentioned above > > The "Releases" page now includes links to one page for each series > ("More on > > the 5.8 series") > > There is now one page for each series (see > > http://staging.hibernate.org/search/releases/series/5.8/). This page > > includes: > > > > A short (one-line) summary of this series > > A reminder of the integration constraints for this series > > A section about the main changes in this release. I only wrote something > for > > the 5.8 series for now, and I basically copy/pasted sections from various > > blog posts. > > A list of all releases in this series. > > > > What I didn't do, but could make sense: > > > > add a sub-menu element under "Releases" for each series > > link to the documentation for each of the latest releases from the > > "Releases" page > > link to the latest documentation and to the migration guides from each > > series' page > > > > What do you all think? Emmanuel, would this address your concerns? Steve, > > would this be a good fit for ORM? > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 6 September 2017 at 17:16, Steve Ebersole > wrote: > >> > >> This is something I brought up ages ago wrt ORM. I wanted something > >> (although ideally integrated with the "more version friendly" > hibernate.org > >> design) similar to what I did atm on the ORM GitHub wiki. For example, > for > >> 5.2 we have: > >> > >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 > >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 > >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 > >> > >> > >> The format could be better and some of this information could be > combined > >> (release notes and migration guide e.g.). But bear in mind that this > was > >> just what I put together to illustrate what I was wanted to do, > generally > >> speaking - so its a bit "rough" > >> > >> > >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero > >> wrote: > >>> > >>> Thanks for that Emmanuel. > >>> > >>> I'll fix the one-liner describing the release, I believe we had > >>> already noticed this in the past: they need to describe the whole > >>> minor not the micro update. > >>> The Search roadmap actually also needs a little re-touch, I'll propose > >>> a PR for that too. > >>> > >>> Regarding past roadmaps: I don't like to clutter the roadmap page with > >>> the previous copies, especially as they should have a different nature > >>> of not being a plan but being a record of what was actually done. > >>> Also, we did agree in past meetings to remove all the old ones. e.g. > >>> we never ported the release notes for version 3.x and 4.x as back then > >>> we decided this was no place for that. Happy to revisit this decision > >>> but let's separate them: > >>> > >>> What about a "past releases" page at the same level of roadmap, and > >>> linking to it both from the main Search menu and the roadmap? > >>> > >>> +1 for Yoann's proposal to re-introduce the compatibility matrix > >>> (there was one ~6 years ago). I also had proposed to reintroduce it > >>> more recently, and was not done on the grounds that it gets out of > >>> date quickly. > >>> Still users badly need it so unless someone has a better idea, let's > >>> agree on trying to keep it up to date manually. Let's try structure it > >>> in such a way that it won't need to be updated for every single > >>> release. > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> On 6 September 2017 at 08:37, Yoann Rodiere > wrote: > >>> > Hey, > >>> > > >>> > About Search, true, the information is somewhat hidden in many blog > >>> > posts. > >>> > I'm not sure the roadmap is the right place, though, since we > probably > >>> > want > >>> > the format to be different for past and future releases: information > >>> > for > >>> > past releases is typically more precise and more verbose, with code > >>> > examples and so on. See for instance this blog post: > >>> > http://in.relation.to/ > >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future > >>> > roadmap > >>> > would be drowned in the past releases. > >>> > > >>> > I was thinking about another problem: we don't have a compatibility > >>> > matrix. > >>> > We only have a few dependencies (mainly ORM and Lucene), but it's > >>> > really > >>> > hard to know which versions of the dependencies to use with which > >>> > version > >>> > of Search, and users frequently use the wrong versions. > >>> > With that in mind, I would rather see a "Versions" page, with a > summary > >>> > at > >>> > the top (including a one-liner for each minor and the compatibilty > >>> > matrix), > >>> > and one section for each minor (with anchors, so that we can link to > >>> > them > >>> > from other pages such as the downloads). Or maybe even one page for > the > >>> > detail of each minor, if there's too much text. > >>> > I think it would make sense to have all that information gathered in > a > >>> > single place, because all of that is needed for users to pick the > >>> > version > >>> > they want: they need to know the benefits of upgrading (features) but > >>> > also > >>> > the constraints (compatibility matrix). > >>> > Maybe I can give it a try at the end of the week? > >>> > > >>> > > >>> > Yoann Rodi?re > >>> > Hibernate NoORM Team > >>> > yoann at hibernate.org > >>> > > >>> > On 6 September 2017 at 09:21, Emmanuel Bernard < > emmanuel at hibernate.org> > >>> > wrote: > >>> > > >>> >> Hey all, > >>> >> > >>> >> I was trying to answer the following question, what is roughly new > >>> >> between > >>> >> 5.6, 5.7 and 5.8 (minor releases)? > >>> >> > >>> >> My first reflex was to go to http://hibernate.org/search/downloads/ > < > >>> >> http://hibernate.org/search/downloads/> to read about the onliner > per > >>> >> release. Except it?s a onliner per micro release and ?minor > >>> >> adjustments? > >>> >> for 5.6.3.Final gave me literally no info whatsoever. > >>> >> > >>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ > < > >>> >> http://hibernate.org/search/roadmap/> to find a historical entry > about > >>> >> older versions and the main changes in bullet points. No luck. It > only > >>> >> talks about the future. > >>> >> > >>> >> My third reflex was to go to http://in.relation.to/ > hibernate-search/ < > >>> >> http://in.relation.to/hibernate-search/> I ended up giving up > midway > >>> >> page > >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel > >>> >> releases > >>> >> with what?s new since the last CR or the last micro kind of reports > >>> >> and > >>> >> gave up in dismay at the energy I would have to spend to extract > >>> >> what?s new > >>> >> for a full minor release. > >>> >> > >>> >> I did exaggerate a bit the third point but I did give up. We need > >>> >> somewhere a summary page of what?s new per minor releases. I think > the > >>> >> roadmap page could be the host. > >>> >> Likewise, we might need a oneliner entry in the download section > (per > >>> >> release) that points to this minor release summary. > >>> >> > >>> >> Thoughts? > >>> >> > >>> >> Speaking of roadmap: > >>> >> - HV roadmap is massively out of date > >>> >> - OGM is lying a bit on the future but at least has the past > summary I > >>> >> was > >>> >> talking about > >>> >> - Search has a good future roadmap but no past > >>> >> > >>> >> Emmanuek > >>> >> _______________________________________________ > >>> >> hibernate-dev mailing list > >>> >> hibernate-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From steve at hibernate.org Fri Sep 8 10:05:25 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 08 Sep 2017 14:05:25 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: For me the real problem is that its not just Downloads/Releases that should be (need to be really) treated in this manner - our documentation is also family specific. So for ORM I had envisioned a "versions" (although "releases" works just as well) component to the url scheme. Vlad did this for documentation (see the version drop down), but we have not yet tackled this for versions - too many other more pressing tasks. Also, I am not sure yet the best overall structure for this - some of the project related information is not version-specific (FAQ, Books, Paid Support, etc) while others are. To me personally, I think the "Documentation" and Downloads/Versions/Releases should not be on the left nav. Or, leave them on the nav and have them implicitly direct to the most-recent-prod-release-family. But overall I had envisioned a release-specific page - specific to release families (5.0, 5.1, etc) as opposed to specific micro/bugfix releases (5.0.1, 5.0.2, etc). This release page would include: 1. General description - what were the main points or developments for this family? 2. Links to its documentation 3. List of all micro/bugfix releases as a sort-of simplified changelog. This part is still unclear in my head as to the best way to represent this information, but ultimately each entry in this list would need to include: 1. announcement URL 2. sysopsis of the main fixes/changes 3. link to the full changelog For the most part, the information I listed for the micro/bugfix release entries is covered in the release announcement so one option is to simply link to each announcement for that family - possibly driven by the release yaml files. This also fixes what I find to be a very confusing list of "latest" releases. I think that works much better as a single entry on the release family page. Will what you did "work" for ORM? Sure. What I describe is just what I personally think would be better in terms of ORM needs, but I have absolutely no resources to do that atm. So for now, whatever y'all deem is best is probably the best way to go. On Fri, Sep 8, 2017 at 8:11 AM Sanne Grinovero wrote: > Thanks Yoann! > Looks great. > > Two minor suggestions: > - could the two links we have for each release on search/releases/ on > two separate lines? Or something else to make it clear that there are > two linkes. > - Regarding the "Compatibility matrix", the header line (the one in > black) .. I think we need to clarify in some way that you're referring > to Hibernate Search releases. Possibly just link to the page > describing the family? > > Thanks, > Sanne > > > On 8 September 2017 at 13:53, Yoann Rodiere wrote: > > Hey, > > > > I pushed an update to staging. I only converted the "Search" part for > now. > > What changes: > > > > The _data folder structured changed a bit, so that we can introduces a > YAML > > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of > this > > series and a list of integration constraints (ORM > 5.2, etc.) > > The "Downloads" page is renamed to "Releases", since, well, it's about > more > > than just downloads. See http://staging.hibernate.org/search/releases/ > > The "Releases" page now includes a "Compatibilty matrix" section based on > > the new data I mentioned above > > The "Releases" page now includes links to one page for each series > ("More on > > the 5.8 series") > > There is now one page for each series (see > > http://staging.hibernate.org/search/releases/series/5.8/). This page > > includes: > > > > A short (one-line) summary of this series > > A reminder of the integration constraints for this series > > A section about the main changes in this release. I only wrote something > for > > the 5.8 series for now, and I basically copy/pasted sections from various > > blog posts. > > A list of all releases in this series. > > > > What I didn't do, but could make sense: > > > > add a sub-menu element under "Releases" for each series > > link to the documentation for each of the latest releases from the > > "Releases" page > > link to the latest documentation and to the migration guides from each > > series' page > > > > What do you all think? Emmanuel, would this address your concerns? Steve, > > would this be a good fit for ORM? > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 6 September 2017 at 17:16, Steve Ebersole > wrote: > >> > >> This is something I brought up ages ago wrt ORM. I wanted something > >> (although ideally integrated with the "more version friendly" > hibernate.org > >> design) similar to what I did atm on the ORM GitHub wiki. For example, > for > >> 5.2 we have: > >> > >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 > >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 > >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 > >> > >> > >> The format could be better and some of this information could be > combined > >> (release notes and migration guide e.g.). But bear in mind that this > was > >> just what I put together to illustrate what I was wanted to do, > generally > >> speaking - so its a bit "rough" > >> > >> > >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero > >> wrote: > >>> > >>> Thanks for that Emmanuel. > >>> > >>> I'll fix the one-liner describing the release, I believe we had > >>> already noticed this in the past: they need to describe the whole > >>> minor not the micro update. > >>> The Search roadmap actually also needs a little re-touch, I'll propose > >>> a PR for that too. > >>> > >>> Regarding past roadmaps: I don't like to clutter the roadmap page with > >>> the previous copies, especially as they should have a different nature > >>> of not being a plan but being a record of what was actually done. > >>> Also, we did agree in past meetings to remove all the old ones. e.g. > >>> we never ported the release notes for version 3.x and 4.x as back then > >>> we decided this was no place for that. Happy to revisit this decision > >>> but let's separate them: > >>> > >>> What about a "past releases" page at the same level of roadmap, and > >>> linking to it both from the main Search menu and the roadmap? > >>> > >>> +1 for Yoann's proposal to re-introduce the compatibility matrix > >>> (there was one ~6 years ago). I also had proposed to reintroduce it > >>> more recently, and was not done on the grounds that it gets out of > >>> date quickly. > >>> Still users badly need it so unless someone has a better idea, let's > >>> agree on trying to keep it up to date manually. Let's try structure it > >>> in such a way that it won't need to be updated for every single > >>> release. > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> On 6 September 2017 at 08:37, Yoann Rodiere > wrote: > >>> > Hey, > >>> > > >>> > About Search, true, the information is somewhat hidden in many blog > >>> > posts. > >>> > I'm not sure the roadmap is the right place, though, since we > probably > >>> > want > >>> > the format to be different for past and future releases: information > >>> > for > >>> > past releases is typically more precise and more verbose, with code > >>> > examples and so on. See for instance this blog post: > >>> > http://in.relation.to/ > >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future > >>> > roadmap > >>> > would be drowned in the past releases. > >>> > > >>> > I was thinking about another problem: we don't have a compatibility > >>> > matrix. > >>> > We only have a few dependencies (mainly ORM and Lucene), but it's > >>> > really > >>> > hard to know which versions of the dependencies to use with which > >>> > version > >>> > of Search, and users frequently use the wrong versions. > >>> > With that in mind, I would rather see a "Versions" page, with a > summary > >>> > at > >>> > the top (including a one-liner for each minor and the compatibilty > >>> > matrix), > >>> > and one section for each minor (with anchors, so that we can link to > >>> > them > >>> > from other pages such as the downloads). Or maybe even one page for > the > >>> > detail of each minor, if there's too much text. > >>> > I think it would make sense to have all that information gathered in > a > >>> > single place, because all of that is needed for users to pick the > >>> > version > >>> > they want: they need to know the benefits of upgrading (features) but > >>> > also > >>> > the constraints (compatibility matrix). > >>> > Maybe I can give it a try at the end of the week? > >>> > > >>> > > >>> > Yoann Rodi?re > >>> > Hibernate NoORM Team > >>> > yoann at hibernate.org > >>> > > >>> > On 6 September 2017 at 09:21, Emmanuel Bernard < > emmanuel at hibernate.org> > >>> > wrote: > >>> > > >>> >> Hey all, > >>> >> > >>> >> I was trying to answer the following question, what is roughly new > >>> >> between > >>> >> 5.6, 5.7 and 5.8 (minor releases)? > >>> >> > >>> >> My first reflex was to go to http://hibernate.org/search/downloads/ > < > >>> >> http://hibernate.org/search/downloads/> to read about the onliner > per > >>> >> release. Except it?s a onliner per micro release and ?minor > >>> >> adjustments? > >>> >> for 5.6.3.Final gave me literally no info whatsoever. > >>> >> > >>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ > < > >>> >> http://hibernate.org/search/roadmap/> to find a historical entry > about > >>> >> older versions and the main changes in bullet points. No luck. It > only > >>> >> talks about the future. > >>> >> > >>> >> My third reflex was to go to > http://in.relation.to/hibernate-search/ < > >>> >> http://in.relation.to/hibernate-search/> I ended up giving up > midway > >>> >> page > >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel > >>> >> releases > >>> >> with what?s new since the last CR or the last micro kind of reports > >>> >> and > >>> >> gave up in dismay at the energy I would have to spend to extract > >>> >> what?s new > >>> >> for a full minor release. > >>> >> > >>> >> I did exaggerate a bit the third point but I did give up. We need > >>> >> somewhere a summary page of what?s new per minor releases. I think > the > >>> >> roadmap page could be the host. > >>> >> Likewise, we might need a oneliner entry in the download section > (per > >>> >> release) that points to this minor release summary. > >>> >> > >>> >> Thoughts? > >>> >> > >>> >> Speaking of roadmap: > >>> >> - HV roadmap is massively out of date > >>> >> - OGM is lying a bit on the future but at least has the past > summary I > >>> >> was > >>> >> talking about > >>> >> - Search has a good future roadmap but no past > >>> >> > >>> >> Emmanuek > >>> >> _______________________________________________ > >>> >> hibernate-dev mailing list > >>> >> hibernate-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From yoann at hibernate.org Fri Sep 8 10:44:41 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Sep 2017 16:44:41 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Steve, If I understood correctly, the main difference between what I did and what you want is you don't want a "hub" pointing to different versions, you want to redirect to the page for the latest version, and from there allow to move to another version using drop-down. While I can understand you'd want that for ORM, I'm not sure it's such a good idea for projects such as Search or OGM, where the difference between two families is not only about features, but also (and in some cases, mainly) about which versions of other components it can integrate with. In this case, I'm not sure a drop-down would be enough to guide users to the correct version... As for your other concerns: - I'll try to add a links to the "documentation" page specific to each series, both in the main "releases" page and in each series-specific page. - The list of all micro/bugfix releases is already there, at the bottom of the page: http://staging.hibernate.org/search/releases/5.8/ I'll see if I can add some sort of table of contents at the top to make it more visible. - The link to the full changelog is already there, though maybe it's not very visible. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 8 September 2017 at 16:05, Steve Ebersole wrote: > For me the real problem is that its not just Downloads/Releases that > should be (need to be really) treated in this manner - our documentation is > also family specific. > > So for ORM I had envisioned a "versions" (although "releases" works just > as well) component to the url scheme. Vlad did this for documentation (see > the version drop down), but we have not yet tackled this for versions - too > many other more pressing tasks. Also, I am not sure yet the best overall > structure for this - some of the project related information is not > version-specific (FAQ, Books, Paid Support, etc) while others are. > > To me personally, I think the "Documentation" and > Downloads/Versions/Releases should not be on the left nav. Or, leave them > on the nav and have them implicitly direct to the most-recent-prod-release-family. > But overall I had envisioned a release-specific page - specific to release > families (5.0, 5.1, etc) as opposed to specific micro/bugfix releases > (5.0.1, 5.0.2, etc). This release page would include: > > 1. General description - what were the main points or developments for > this family? > 2. Links to its documentation > 3. List of all micro/bugfix releases as a sort-of simplified > changelog. This part is still unclear in my head as to the best way to > represent this information, but ultimately each entry in this list would > need to include: > 1. announcement URL > 2. sysopsis of the main fixes/changes > 3. link to the full changelog > > For the most part, the information I listed for the micro/bugfix release > entries is covered in the release announcement so one option is to simply > link to each announcement for that family - possibly driven by the release > yaml files. > > This also fixes what I find to be a very confusing list of "latest" > releases. I think that works much better as a single entry on the release > family page. > > Will what you did "work" for ORM? Sure. What I describe is just what I > personally think would be better in terms of ORM needs, but I have > absolutely no resources to do that atm. So for now, whatever y'all deem is > best is probably the best way to go. > > > On Fri, Sep 8, 2017 at 8:11 AM Sanne Grinovero > wrote: > >> Thanks Yoann! >> Looks great. >> >> Two minor suggestions: >> - could the two links we have for each release on search/releases/ on >> two separate lines? Or something else to make it clear that there are >> two linkes. >> - Regarding the "Compatibility matrix", the header line (the one in >> black) .. I think we need to clarify in some way that you're referring >> to Hibernate Search releases. Possibly just link to the page >> describing the family? >> >> Thanks, >> Sanne >> >> >> On 8 September 2017 at 13:53, Yoann Rodiere wrote: >> > Hey, >> > >> > I pushed an update to staging. I only converted the "Search" part for >> now. >> > What changes: >> > >> > The _data folder structured changed a bit, so that we can introduces a >> YAML >> > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of >> this >> > series and a list of integration constraints (ORM > 5.2, etc.) >> > The "Downloads" page is renamed to "Releases", since, well, it's about >> more >> > than just downloads. See http://staging.hibernate.org/search/releases/ >> > The "Releases" page now includes a "Compatibilty matrix" section based >> on >> > the new data I mentioned above >> > The "Releases" page now includes links to one page for each series >> ("More on >> > the 5.8 series") >> > There is now one page for each series (see >> > http://staging.hibernate.org/search/releases/series/5.8/). This page >> > includes: >> > >> > A short (one-line) summary of this series >> > A reminder of the integration constraints for this series >> > A section about the main changes in this release. I only wrote >> something for >> > the 5.8 series for now, and I basically copy/pasted sections from >> various >> > blog posts. >> > A list of all releases in this series. >> > >> > What I didn't do, but could make sense: >> > >> > add a sub-menu element under "Releases" for each series >> > link to the documentation for each of the latest releases from the >> > "Releases" page >> > link to the latest documentation and to the migration guides from each >> > series' page >> > >> > What do you all think? Emmanuel, would this address your concerns? >> Steve, >> > would this be a good fit for ORM? >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > On 6 September 2017 at 17:16, Steve Ebersole >> wrote: >> >> >> >> This is something I brought up ages ago wrt ORM. I wanted something >> >> (although ideally integrated with the "more version friendly" >> hibernate.org >> >> design) similar to what I did atm on the ORM GitHub wiki. For >> example, for >> >> 5.2 we have: >> >> >> >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >> >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >> >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >> >> >> >> >> >> The format could be better and some of this information could be >> combined >> >> (release notes and migration guide e.g.). But bear in mind that this >> was >> >> just what I put together to illustrate what I was wanted to do, >> generally >> >> speaking - so its a bit "rough" >> >> >> >> >> >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >> >> wrote: >> >>> >> >>> Thanks for that Emmanuel. >> >>> >> >>> I'll fix the one-liner describing the release, I believe we had >> >>> already noticed this in the past: they need to describe the whole >> >>> minor not the micro update. >> >>> The Search roadmap actually also needs a little re-touch, I'll propose >> >>> a PR for that too. >> >>> >> >>> Regarding past roadmaps: I don't like to clutter the roadmap page with >> >>> the previous copies, especially as they should have a different nature >> >>> of not being a plan but being a record of what was actually done. >> >>> Also, we did agree in past meetings to remove all the old ones. e.g. >> >>> we never ported the release notes for version 3.x and 4.x as back then >> >>> we decided this was no place for that. Happy to revisit this decision >> >>> but let's separate them: >> >>> >> >>> What about a "past releases" page at the same level of roadmap, and >> >>> linking to it both from the main Search menu and the roadmap? >> >>> >> >>> +1 for Yoann's proposal to re-introduce the compatibility matrix >> >>> (there was one ~6 years ago). I also had proposed to reintroduce it >> >>> more recently, and was not done on the grounds that it gets out of >> >>> date quickly. >> >>> Still users badly need it so unless someone has a better idea, let's >> >>> agree on trying to keep it up to date manually. Let's try structure it >> >>> in such a way that it won't need to be updated for every single >> >>> release. >> >>> >> >>> Thanks, >> >>> Sanne >> >>> >> >>> >> >>> On 6 September 2017 at 08:37, Yoann Rodiere >> wrote: >> >>> > Hey, >> >>> > >> >>> > About Search, true, the information is somewhat hidden in many blog >> >>> > posts. >> >>> > I'm not sure the roadmap is the right place, though, since we >> probably >> >>> > want >> >>> > the format to be different for past and future releases: information >> >>> > for >> >>> > past releases is typically more precise and more verbose, with code >> >>> > examples and so on. See for instance this blog post: >> >>> > http://in.relation.to/ >> >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >> >>> > roadmap >> >>> > would be drowned in the past releases. >> >>> > >> >>> > I was thinking about another problem: we don't have a compatibility >> >>> > matrix. >> >>> > We only have a few dependencies (mainly ORM and Lucene), but it's >> >>> > really >> >>> > hard to know which versions of the dependencies to use with which >> >>> > version >> >>> > of Search, and users frequently use the wrong versions. >> >>> > With that in mind, I would rather see a "Versions" page, with a >> summary >> >>> > at >> >>> > the top (including a one-liner for each minor and the compatibilty >> >>> > matrix), >> >>> > and one section for each minor (with anchors, so that we can link to >> >>> > them >> >>> > from other pages such as the downloads). Or maybe even one page for >> the >> >>> > detail of each minor, if there's too much text. >> >>> > I think it would make sense to have all that information gathered >> in a >> >>> > single place, because all of that is needed for users to pick the >> >>> > version >> >>> > they want: they need to know the benefits of upgrading (features) >> but >> >>> > also >> >>> > the constraints (compatibility matrix). >> >>> > Maybe I can give it a try at the end of the week? >> >>> > >> >>> > >> >>> > Yoann Rodi?re >> >>> > Hibernate NoORM Team >> >>> > yoann at hibernate.org >> >>> > >> >>> > On 6 September 2017 at 09:21, Emmanuel Bernard < >> emmanuel at hibernate.org> >> >>> > wrote: >> >>> > >> >>> >> Hey all, >> >>> >> >> >>> >> I was trying to answer the following question, what is roughly new >> >>> >> between >> >>> >> 5.6, 5.7 and 5.8 (minor releases)? >> >>> >> >> >>> >> My first reflex was to go to http://hibernate.org/search/ >> downloads/ < >> >>> >> http://hibernate.org/search/downloads/> to read about the onliner >> per >> >>> >> release. Except it?s a onliner per micro release and ?minor >> >>> >> adjustments? >> >>> >> for 5.6.3.Final gave me literally no info whatsoever. >> >>> >> >> >>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ >> < >> >>> >> http://hibernate.org/search/roadmap/> to find a historical entry >> about >> >>> >> older versions and the main changes in bullet points. No luck. It >> only >> >>> >> talks about the future. >> >>> >> >> >>> >> My third reflex was to go to http://in.relation.to/ >> hibernate-search/ < >> >>> >> http://in.relation.to/hibernate-search/> I ended up giving up >> midway >> >>> >> page >> >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >> >>> >> releases >> >>> >> with what?s new since the last CR or the last micro kind of reports >> >>> >> and >> >>> >> gave up in dismay at the energy I would have to spend to extract >> >>> >> what?s new >> >>> >> for a full minor release. >> >>> >> >> >>> >> I did exaggerate a bit the third point but I did give up. We need >> >>> >> somewhere a summary page of what?s new per minor releases. I think >> the >> >>> >> roadmap page could be the host. >> >>> >> Likewise, we might need a oneliner entry in the download section >> (per >> >>> >> release) that points to this minor release summary. >> >>> >> >> >>> >> Thoughts? >> >>> >> >> >>> >> Speaking of roadmap: >> >>> >> - HV roadmap is massively out of date >> >>> >> - OGM is lying a bit on the future but at least has the past >> summary I >> >>> >> was >> >>> >> talking about >> >>> >> - Search has a good future roadmap but no past >> >>> >> >> >>> >> Emmanuek >> >>> >> _______________________________________________ >> >>> >> hibernate-dev mailing list >> >>> >> hibernate-dev at lists.jboss.org >> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> > _______________________________________________ >> >>> > hibernate-dev mailing list >> >>> > hibernate-dev at lists.jboss.org >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> > From yoann at hibernate.org Fri Sep 8 11:54:43 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Sep 2017 17:54:43 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: Following Steve's comments, I made another few changes for the sake of usability: - Moved the series-specific pages so that the path is more consistent with ORM documentation; the series-specific page for Search 5.8, for instance, is now http://staging.hibernate.org/search/releases/5.8/ - Changed the list of releases in the "releases" page: renamed "Latest releases" to "Maintained series", and made the series version more prominent, on the left, while the latest release version is a bit less prominent, on the right. That way the list should be a bit less confusing. - Added links to the reference from the "Releases" page: http://staging.hibernate.org/search/releases/ - Added a hero-unit at the top of the series-specific pages, with a few links: http://staging.hibernate.org/search/releases/5.8/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 8 September 2017 at 16:44, Yoann Rodiere wrote: > Steve, > > If I understood correctly, the main difference between what I did and what > you want is you don't want a "hub" pointing to different versions, you want > to redirect to the page for the latest version, and from there allow to > move to another version using drop-down. > While I can understand you'd want that for ORM, I'm not sure it's such a > good idea for projects such as Search or OGM, where the difference between > two families is not only about features, but also (and in some cases, > mainly) about which versions of other components it can integrate with. In > this case, I'm not sure a drop-down would be enough to guide users to the > correct version... > > As for your other concerns: > > - I'll try to add a links to the "documentation" page specific to each > series, both in the main "releases" page and in each series-specific page. > - The list of all micro/bugfix releases is already there, at the > bottom of the page: http://staging.hibernate.org/search/releases/5.8/ > I'll see if I can add some sort of table of contents at the top to > make it more visible. > - The link to the full changelog is already there, though maybe it's > not very visible. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 8 September 2017 at 16:05, Steve Ebersole wrote: > >> For me the real problem is that its not just Downloads/Releases that >> should be (need to be really) treated in this manner - our documentation is >> also family specific. >> >> So for ORM I had envisioned a "versions" (although "releases" works just >> as well) component to the url scheme. Vlad did this for documentation (see >> the version drop down), but we have not yet tackled this for versions - too >> many other more pressing tasks. Also, I am not sure yet the best overall >> structure for this - some of the project related information is not >> version-specific (FAQ, Books, Paid Support, etc) while others are. >> >> To me personally, I think the "Documentation" and >> Downloads/Versions/Releases should not be on the left nav. Or, leave them >> on the nav and have them implicitly direct to the >> most-recent-prod-release-family. But overall I had envisioned a >> release-specific page - specific to release families (5.0, 5.1, etc) as >> opposed to specific micro/bugfix releases (5.0.1, 5.0.2, etc). This >> release page would include: >> >> 1. General description - what were the main points or developments >> for this family? >> 2. Links to its documentation >> 3. List of all micro/bugfix releases as a sort-of simplified >> changelog. This part is still unclear in my head as to the best way to >> represent this information, but ultimately each entry in this list would >> need to include: >> 1. announcement URL >> 2. sysopsis of the main fixes/changes >> 3. link to the full changelog >> >> For the most part, the information I listed for the micro/bugfix release >> entries is covered in the release announcement so one option is to simply >> link to each announcement for that family - possibly driven by the release >> yaml files. >> >> This also fixes what I find to be a very confusing list of "latest" >> releases. I think that works much better as a single entry on the release >> family page. >> >> Will what you did "work" for ORM? Sure. What I describe is just what I >> personally think would be better in terms of ORM needs, but I have >> absolutely no resources to do that atm. So for now, whatever y'all deem is >> best is probably the best way to go. >> >> >> On Fri, Sep 8, 2017 at 8:11 AM Sanne Grinovero >> wrote: >> >>> Thanks Yoann! >>> Looks great. >>> >>> Two minor suggestions: >>> - could the two links we have for each release on search/releases/ on >>> two separate lines? Or something else to make it clear that there are >>> two linkes. >>> - Regarding the "Compatibility matrix", the header line (the one in >>> black) .. I think we need to clarify in some way that you're referring >>> to Hibernate Search releases. Possibly just link to the page >>> describing the family? >>> >>> Thanks, >>> Sanne >>> >>> >>> On 8 September 2017 at 13:53, Yoann Rodiere wrote: >>> > Hey, >>> > >>> > I pushed an update to staging. I only converted the "Search" part for >>> now. >>> > What changes: >>> > >>> > The _data folder structured changed a bit, so that we can introduces a >>> YAML >>> > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary >>> of this >>> > series and a list of integration constraints (ORM > 5.2, etc.) >>> > The "Downloads" page is renamed to "Releases", since, well, it's about >>> more >>> > than just downloads. See http://staging.hibernate.org/search/releases/ >>> > The "Releases" page now includes a "Compatibilty matrix" section based >>> on >>> > the new data I mentioned above >>> > The "Releases" page now includes links to one page for each series >>> ("More on >>> > the 5.8 series") >>> > There is now one page for each series (see >>> > http://staging.hibernate.org/search/releases/series/5.8/). This page >>> > includes: >>> > >>> > A short (one-line) summary of this series >>> > A reminder of the integration constraints for this series >>> > A section about the main changes in this release. I only wrote >>> something for >>> > the 5.8 series for now, and I basically copy/pasted sections from >>> various >>> > blog posts. >>> > A list of all releases in this series. >>> > >>> > What I didn't do, but could make sense: >>> > >>> > add a sub-menu element under "Releases" for each series >>> > link to the documentation for each of the latest releases from the >>> > "Releases" page >>> > link to the latest documentation and to the migration guides from each >>> > series' page >>> > >>> > What do you all think? Emmanuel, would this address your concerns? >>> Steve, >>> > would this be a good fit for ORM? >>> > >>> > Yoann Rodi?re >>> > Hibernate NoORM Team >>> > yoann at hibernate.org >>> > >>> > On 6 September 2017 at 17:16, Steve Ebersole >>> wrote: >>> >> >>> >> This is something I brought up ages ago wrt ORM. I wanted something >>> >> (although ideally integrated with the "more version friendly" >>> hibernate.org >>> >> design) similar to what I did atm on the ORM GitHub wiki. For >>> example, for >>> >> 5.2 we have: >>> >> >>> >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >>> >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >>> >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >>> >> >>> >> >>> >> The format could be better and some of this information could be >>> combined >>> >> (release notes and migration guide e.g.). But bear in mind that this >>> was >>> >> just what I put together to illustrate what I was wanted to do, >>> generally >>> >> speaking - so its a bit "rough" >>> >> >>> >> >>> >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >>> >> wrote: >>> >>> >>> >>> Thanks for that Emmanuel. >>> >>> >>> >>> I'll fix the one-liner describing the release, I believe we had >>> >>> already noticed this in the past: they need to describe the whole >>> >>> minor not the micro update. >>> >>> The Search roadmap actually also needs a little re-touch, I'll >>> propose >>> >>> a PR for that too. >>> >>> >>> >>> Regarding past roadmaps: I don't like to clutter the roadmap page >>> with >>> >>> the previous copies, especially as they should have a different >>> nature >>> >>> of not being a plan but being a record of what was actually done. >>> >>> Also, we did agree in past meetings to remove all the old ones. e.g. >>> >>> we never ported the release notes for version 3.x and 4.x as back >>> then >>> >>> we decided this was no place for that. Happy to revisit this decision >>> >>> but let's separate them: >>> >>> >>> >>> What about a "past releases" page at the same level of roadmap, and >>> >>> linking to it both from the main Search menu and the roadmap? >>> >>> >>> >>> +1 for Yoann's proposal to re-introduce the compatibility matrix >>> >>> (there was one ~6 years ago). I also had proposed to reintroduce it >>> >>> more recently, and was not done on the grounds that it gets out of >>> >>> date quickly. >>> >>> Still users badly need it so unless someone has a better idea, let's >>> >>> agree on trying to keep it up to date manually. Let's try structure >>> it >>> >>> in such a way that it won't need to be updated for every single >>> >>> release. >>> >>> >>> >>> Thanks, >>> >>> Sanne >>> >>> >>> >>> >>> >>> On 6 September 2017 at 08:37, Yoann Rodiere >>> wrote: >>> >>> > Hey, >>> >>> > >>> >>> > About Search, true, the information is somewhat hidden in many blog >>> >>> > posts. >>> >>> > I'm not sure the roadmap is the right place, though, since we >>> probably >>> >>> > want >>> >>> > the format to be different for past and future releases: >>> information >>> >>> > for >>> >>> > past releases is typically more precise and more verbose, with code >>> >>> > examples and so on. See for instance this blog post: >>> >>> > http://in.relation.to/ >>> >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >>> >>> > roadmap >>> >>> > would be drowned in the past releases. >>> >>> > >>> >>> > I was thinking about another problem: we don't have a compatibility >>> >>> > matrix. >>> >>> > We only have a few dependencies (mainly ORM and Lucene), but it's >>> >>> > really >>> >>> > hard to know which versions of the dependencies to use with which >>> >>> > version >>> >>> > of Search, and users frequently use the wrong versions. >>> >>> > With that in mind, I would rather see a "Versions" page, with a >>> summary >>> >>> > at >>> >>> > the top (including a one-liner for each minor and the compatibilty >>> >>> > matrix), >>> >>> > and one section for each minor (with anchors, so that we can link >>> to >>> >>> > them >>> >>> > from other pages such as the downloads). Or maybe even one page >>> for the >>> >>> > detail of each minor, if there's too much text. >>> >>> > I think it would make sense to have all that information gathered >>> in a >>> >>> > single place, because all of that is needed for users to pick the >>> >>> > version >>> >>> > they want: they need to know the benefits of upgrading (features) >>> but >>> >>> > also >>> >>> > the constraints (compatibility matrix). >>> >>> > Maybe I can give it a try at the end of the week? >>> >>> > >>> >>> > >>> >>> > Yoann Rodi?re >>> >>> > Hibernate NoORM Team >>> >>> > yoann at hibernate.org >>> >>> > >>> >>> > On 6 September 2017 at 09:21, Emmanuel Bernard < >>> emmanuel at hibernate.org> >>> >>> > wrote: >>> >>> > >>> >>> >> Hey all, >>> >>> >> >>> >>> >> I was trying to answer the following question, what is roughly new >>> >>> >> between >>> >>> >> 5.6, 5.7 and 5.8 (minor releases)? >>> >>> >> >>> >>> >> My first reflex was to go to http://hibernate.org/search/do >>> wnloads/ < >>> >>> >> http://hibernate.org/search/downloads/> to read about the >>> onliner per >>> >>> >> release. Except it?s a onliner per micro release and ?minor >>> >>> >> adjustments? >>> >>> >> for 5.6.3.Final gave me literally no info whatsoever. >>> >>> >> >>> >>> >> My second reflex was to go to http://hibernate.org/search/ro >>> admap/ < >>> >>> >> http://hibernate.org/search/roadmap/> to find a historical entry >>> about >>> >>> >> older versions and the main changes in bullet points. No luck. It >>> only >>> >>> >> talks about the future. >>> >>> >> >>> >>> >> My third reflex was to go to http://in.relation.to/hibernat >>> e-search/ < >>> >>> >> http://in.relation.to/hibernate-search/> I ended up giving up >>> midway >>> >>> >> page >>> >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >>> >>> >> releases >>> >>> >> with what?s new since the last CR or the last micro kind of >>> reports >>> >>> >> and >>> >>> >> gave up in dismay at the energy I would have to spend to extract >>> >>> >> what?s new >>> >>> >> for a full minor release. >>> >>> >> >>> >>> >> I did exaggerate a bit the third point but I did give up. We need >>> >>> >> somewhere a summary page of what?s new per minor releases. I >>> think the >>> >>> >> roadmap page could be the host. >>> >>> >> Likewise, we might need a oneliner entry in the download section >>> (per >>> >>> >> release) that points to this minor release summary. >>> >>> >> >>> >>> >> Thoughts? >>> >>> >> >>> >>> >> Speaking of roadmap: >>> >>> >> - HV roadmap is massively out of date >>> >>> >> - OGM is lying a bit on the future but at least has the past >>> summary I >>> >>> >> was >>> >>> >> talking about >>> >>> >> - Search has a good future roadmap but no past >>> >>> >> >>> >>> >> Emmanuek >>> >>> >> _______________________________________________ >>> >>> >> hibernate-dev mailing list >>> >>> >> hibernate-dev at lists.jboss.org >>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> > _______________________________________________ >>> >>> > hibernate-dev mailing list >>> >>> > hibernate-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >>> >>> _______________________________________________ >>> >>> hibernate-dev mailing list >>> >>> hibernate-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> > >>> >> > From steve at hibernate.org Fri Sep 8 11:55:54 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 08 Sep 2017 15:55:54 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: On Fri, Sep 8, 2017 at 9:45 AM Yoann Rodiere wrote: > Steve, > > If I understood correctly, the main difference between what I did and what > you want is you don't want a "hub" pointing to different versions, you want > to redirect to the page for the latest version, and from there allow to > move to another version using drop-down. > That's not what I was saying. You can even see that in what the wikis I pointed to. I pointed out the drop down to illustrate that this information is all version-specific (as is release information obviously). Vlad did it that way because the way hibernate.org is currently defined made that by far easier to do this just for ORM. A real solution (which you are trying) would require much larger "infrastructure" changes than we have resources to tackle. So no, that's not my ideal set up - I've already said that my ideal set up would be that hibernate.org itself was built to just handle this because it is true for every multi-release sub-project and its silly for each sub-project to devise different ways to manage this. You obviously thought the same since that is what you are trying to do. In terms of my ideal, let's look in terms of URLs... Essentially I want to move hibernate.org/{project}/documentation and hibernate.org/{project}/downloads under a "version scheme", so hibernate.org/{project}/release/{version}. "version" here means family (5.0, 5.1, etc). There would also be 2 extra version related urls: 1. hibernate.org/{project}/release/latest - latest-stable-release 2. hibernate.org/orm/release - your "hub", similar to my wikis ( https://github.com/hibernate/hibernate-orm/wiki/Release-Notes, https://github.com/hibernate/hibernate-orm/wiki/Migration-Guides, etc) What I was saying with redirects is that we'd have the left nav links point to "hibernate.org/{project}/release/latest". IMO that matches what most people would expect. Each release's page (hibernate.org/orm/release/5.2 e.g.) would contain: 1. synopsis - the purpose of and high-level changes in the release 2. links to its documentation 3. some form of list of its specific micro releases. I never said your work did or did not have any of these specifics. As you said, most of this information is currently spread over blog post announcing the release. From sanne at hibernate.org Fri Sep 8 12:04:33 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 8 Sep 2017 17:04:33 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: On 8 September 2017 at 14:46, Yoann Rodiere wrote: > Sanne, I addressed both your comments. Is it better? I love it, definitely a step forward! But we'll need to find some compromise with the requirements of the other projects - e.g. Steve's feedback - : it should be consistent across them for people to not get confused. Minor nitpicking: the compatibility matrix isn't very visible when we have >=4 releases. > I also addressed Guillaume's comment on HipChat, and made the compatibility > matrix a bit... fuzzier, so that we won't have to update it as often. We can > still make it very specific if we want to, but we won't be limited by the > layout anymore. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 8 September 2017 at 15:11, Sanne Grinovero wrote: >> >> Thanks Yoann! >> Looks great. >> >> Two minor suggestions: >> - could the two links we have for each release on search/releases/ on >> two separate lines? Or something else to make it clear that there are >> two linkes. >> - Regarding the "Compatibility matrix", the header line (the one in >> black) .. I think we need to clarify in some way that you're referring >> to Hibernate Search releases. Possibly just link to the page >> describing the family? >> >> Thanks, >> Sanne >> >> >> On 8 September 2017 at 13:53, Yoann Rodiere wrote: >> > Hey, >> > >> > I pushed an update to staging. I only converted the "Search" part for >> > now. >> > What changes: >> > >> > The _data folder structured changed a bit, so that we can introduces a >> > YAML >> > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of >> > this >> > series and a list of integration constraints (ORM > 5.2, etc.) >> > The "Downloads" page is renamed to "Releases", since, well, it's about >> > more >> > than just downloads. See http://staging.hibernate.org/search/releases/ >> > The "Releases" page now includes a "Compatibilty matrix" section based >> > on >> > the new data I mentioned above >> > The "Releases" page now includes links to one page for each series >> > ("More on >> > the 5.8 series") >> > There is now one page for each series (see >> > http://staging.hibernate.org/search/releases/series/5.8/). This page >> > includes: >> > >> > A short (one-line) summary of this series >> > A reminder of the integration constraints for this series >> > A section about the main changes in this release. I only wrote something >> > for >> > the 5.8 series for now, and I basically copy/pasted sections from >> > various >> > blog posts. >> > A list of all releases in this series. >> > >> > What I didn't do, but could make sense: >> > >> > add a sub-menu element under "Releases" for each series >> > link to the documentation for each of the latest releases from the >> > "Releases" page >> > link to the latest documentation and to the migration guides from each >> > series' page >> > >> > What do you all think? Emmanuel, would this address your concerns? >> > Steve, >> > would this be a good fit for ORM? >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > On 6 September 2017 at 17:16, Steve Ebersole >> > wrote: >> >> >> >> This is something I brought up ages ago wrt ORM. I wanted something >> >> (although ideally integrated with the "more version friendly" >> >> hibernate.org >> >> design) similar to what I did atm on the ORM GitHub wiki. For example, >> >> for >> >> 5.2 we have: >> >> >> >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >> >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >> >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >> >> >> >> >> >> The format could be better and some of this information could be >> >> combined >> >> (release notes and migration guide e.g.). But bear in mind that this >> >> was >> >> just what I put together to illustrate what I was wanted to do, >> >> generally >> >> speaking - so its a bit "rough" >> >> >> >> >> >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >> >> wrote: >> >>> >> >>> Thanks for that Emmanuel. >> >>> >> >>> I'll fix the one-liner describing the release, I believe we had >> >>> already noticed this in the past: they need to describe the whole >> >>> minor not the micro update. >> >>> The Search roadmap actually also needs a little re-touch, I'll propose >> >>> a PR for that too. >> >>> >> >>> Regarding past roadmaps: I don't like to clutter the roadmap page with >> >>> the previous copies, especially as they should have a different nature >> >>> of not being a plan but being a record of what was actually done. >> >>> Also, we did agree in past meetings to remove all the old ones. e.g. >> >>> we never ported the release notes for version 3.x and 4.x as back then >> >>> we decided this was no place for that. Happy to revisit this decision >> >>> but let's separate them: >> >>> >> >>> What about a "past releases" page at the same level of roadmap, and >> >>> linking to it both from the main Search menu and the roadmap? >> >>> >> >>> +1 for Yoann's proposal to re-introduce the compatibility matrix >> >>> (there was one ~6 years ago). I also had proposed to reintroduce it >> >>> more recently, and was not done on the grounds that it gets out of >> >>> date quickly. >> >>> Still users badly need it so unless someone has a better idea, let's >> >>> agree on trying to keep it up to date manually. Let's try structure it >> >>> in such a way that it won't need to be updated for every single >> >>> release. >> >>> >> >>> Thanks, >> >>> Sanne >> >>> >> >>> >> >>> On 6 September 2017 at 08:37, Yoann Rodiere >> >>> wrote: >> >>> > Hey, >> >>> > >> >>> > About Search, true, the information is somewhat hidden in many blog >> >>> > posts. >> >>> > I'm not sure the roadmap is the right place, though, since we >> >>> > probably >> >>> > want >> >>> > the format to be different for past and future releases: information >> >>> > for >> >>> > past releases is typically more precise and more verbose, with code >> >>> > examples and so on. See for instance this blog post: >> >>> > http://in.relation.to/ >> >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >> >>> > roadmap >> >>> > would be drowned in the past releases. >> >>> > >> >>> > I was thinking about another problem: we don't have a compatibility >> >>> > matrix. >> >>> > We only have a few dependencies (mainly ORM and Lucene), but it's >> >>> > really >> >>> > hard to know which versions of the dependencies to use with which >> >>> > version >> >>> > of Search, and users frequently use the wrong versions. >> >>> > With that in mind, I would rather see a "Versions" page, with a >> >>> > summary >> >>> > at >> >>> > the top (including a one-liner for each minor and the compatibilty >> >>> > matrix), >> >>> > and one section for each minor (with anchors, so that we can link to >> >>> > them >> >>> > from other pages such as the downloads). Or maybe even one page for >> >>> > the >> >>> > detail of each minor, if there's too much text. >> >>> > I think it would make sense to have all that information gathered in >> >>> > a >> >>> > single place, because all of that is needed for users to pick the >> >>> > version >> >>> > they want: they need to know the benefits of upgrading (features) >> >>> > but >> >>> > also >> >>> > the constraints (compatibility matrix). >> >>> > Maybe I can give it a try at the end of the week? >> >>> > >> >>> > >> >>> > Yoann Rodi?re >> >>> > Hibernate NoORM Team >> >>> > yoann at hibernate.org >> >>> > >> >>> > On 6 September 2017 at 09:21, Emmanuel Bernard >> >>> > >> >>> > wrote: >> >>> > >> >>> >> Hey all, >> >>> >> >> >>> >> I was trying to answer the following question, what is roughly new >> >>> >> between >> >>> >> 5.6, 5.7 and 5.8 (minor releases)? >> >>> >> >> >>> >> My first reflex was to go to http://hibernate.org/search/downloads/ >> >>> >> < >> >>> >> http://hibernate.org/search/downloads/> to read about the onliner >> >>> >> per >> >>> >> release. Except it?s a onliner per micro release and ?minor >> >>> >> adjustments? >> >>> >> for 5.6.3.Final gave me literally no info whatsoever. >> >>> >> >> >>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ >> >>> >> < >> >>> >> http://hibernate.org/search/roadmap/> to find a historical entry >> >>> >> about >> >>> >> older versions and the main changes in bullet points. No luck. It >> >>> >> only >> >>> >> talks about the future. >> >>> >> >> >>> >> My third reflex was to go to >> >>> >> http://in.relation.to/hibernate-search/ < >> >>> >> http://in.relation.to/hibernate-search/> I ended up giving up >> >>> >> midway >> >>> >> page >> >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >> >>> >> releases >> >>> >> with what?s new since the last CR or the last micro kind of reports >> >>> >> and >> >>> >> gave up in dismay at the energy I would have to spend to extract >> >>> >> what?s new >> >>> >> for a full minor release. >> >>> >> >> >>> >> I did exaggerate a bit the third point but I did give up. We need >> >>> >> somewhere a summary page of what?s new per minor releases. I think >> >>> >> the >> >>> >> roadmap page could be the host. >> >>> >> Likewise, we might need a oneliner entry in the download section >> >>> >> (per >> >>> >> release) that points to this minor release summary. >> >>> >> >> >>> >> Thoughts? >> >>> >> >> >>> >> Speaking of roadmap: >> >>> >> - HV roadmap is massively out of date >> >>> >> - OGM is lying a bit on the future but at least has the past >> >>> >> summary I >> >>> >> was >> >>> >> talking about >> >>> >> - Search has a good future roadmap but no past >> >>> >> >> >>> >> Emmanuek >> >>> >> _______________________________________________ >> >>> >> hibernate-dev mailing list >> >>> >> hibernate-dev at lists.jboss.org >> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> > _______________________________________________ >> >>> > hibernate-dev mailing list >> >>> > hibernate-dev at lists.jboss.org >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > > > From guillaume.smet at gmail.com Fri Sep 8 12:26:41 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 8 Sep 2017 18:26:41 +0200 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter Message-ID: Hi, Note to Gail: this is potentially a blocking issue for 5.2.11 for the OGM upgrade (I thought it was a bug in OGM but apparently, it's an issue with ORM). In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the interceptor field directly because the field has been moved to AbstractSharedSessionContract. See for instance the change made here in afterTransactionCompletion(): https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443 I think this is an issue as getInterceptor() is not a simple getter but is: @Override public Interceptor getInterceptor() { checkTransactionSynchStatus(); return interceptor; } protected void checkTransactionSynchStatus() { pulseTransactionCoordinator(); delayedAfterCompletion(); } Thus calling the pulse() method of the TransactionCoordinator, triggering an implicit join whereas we're in the afterTransactionCompletion() phase. This is an issue for us as the pulse() method of our TransactionCoordinator creates Neo4j transactions so when the getInterceptor() method is called in afterTransactionCompletion(), we create a new Neo4j transaction. So 2 questions: - should we really call checkTransactionSynchStatus(); in getInterceptor()? If feels a bit weird. - if so, I think we should have a true protected getter (interceptor() following Steve's convention?) to avoid SessionImpl "pulsing" the transaction coordinator when accessing the interceptor. Thanks for your feedback! -- Guillaume From mark at lawinegevaar.nl Fri Sep 8 12:41:12 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Fri, 8 Sep 2017 18:41:12 +0200 Subject: [hibernate-dev] Are the tests in the documentation module expected to run on MySQL only? Message-ID: Are the tests in the documentation module expected to run on MySQL / MariaDB only? Or are they expected to run on all databases? The test org.hibernate.userguide.mapping.basic.SubselectTest is failing on Firebird, because it has the following subselect: @Subselect( "select " + " a.id as id, " + " concat(concat(c.first_name, ' '), c.last_name) as clientName, " + " sum(at.cents) as balance " + "from account a " + "join client c on c.id = a.client_id " + "join account_transaction at on a.id = at.account_id " + "group by a.id, concat(concat(c.first_name, ' '), c.last_name)" ) Firebird doesn't have a concat function. According to the version history, this test previously used the SQL standard concat operator '||', but this was changed in May with the commit comment "Fix test failing on MariaDB". I am surprised that this change wouldn't be failing on other databases either (unless most of them define a concat function next to supporting the || operator). To fix this database independently, it would need to be changed to use the JDBC concat function escape: @Subselect( "select " + " a.id as id, " + " {fn concat({fn concat(c.first_name, ' ')}, c.last_name)} as clientName, " + " sum(atr.cents) as balance " + "from account a " + "join client c on c.id = a.client_id " + "join account_transaction atr on a.id = atr.account_id " + "group by a.id, {fn concat({fn concat(c.first_name, ' ')}, c.last_name)}" ) However, JDBC function escape are (almost) never used in Hibernate tests, so I wonder if this would need to be handled elsewhere. What to do? Do I ignore the documentation tests, add an exception for Firebird or create a pull request with the above change, or something else? -- Mark Rotteveel From mihalcea.vlad at gmail.com Fri Sep 8 14:23:17 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 8 Sep 2017 21:23:17 +0300 Subject: [hibernate-dev] Are the tests in the documentation module expected to run on MySQL only? In-Reply-To: References: Message-ID: I test Hibernate with the following DBs mostly: - H2 - Oracle - SQL Server - PostgreSQL - MySQL and MariaDb For other databases, it's not guaranteed that all tests will run. Related to that function, we could other add a change, but it must work on the DBs above too. Or, you could just mark the test with @SkipForDialect. Thanks, Vlad On Fri, Sep 8, 2017 at 7:41 PM, Mark Rotteveel wrote: > Are the tests in the documentation module expected to run on MySQL / > MariaDB only? Or are they expected to run on all databases? > > The test org.hibernate.userguide.mapping.basic.SubselectTest is failing > on Firebird, because it has the following subselect: > > @Subselect( > "select " + > " a.id as id, " + > " concat(concat(c.first_name, ' '), c.last_name) as clientName, " + > " sum(at.cents) as balance " + > "from account a " + > "join client c on c.id = a.client_id " + > "join account_transaction at on a.id = at.account_id " + > "group by a.id, concat(concat(c.first_name, ' '), c.last_name)" > ) > > Firebird doesn't have a concat function. According to the version > history, this test previously used the SQL standard concat operator > '||', but this was changed in May with the commit comment "Fix test > failing on MariaDB". > > I am surprised that this change wouldn't be failing on other databases > either (unless most of them define a concat function next to supporting > the || operator). > > To fix this database independently, it would need to be changed to use > the JDBC concat function escape: > > @Subselect( > "select " + > " a.id as id, " + > " {fn concat({fn concat(c.first_name, ' ')}, c.last_name)} as > clientName, " + > " sum(atr.cents) as balance " + > "from account a " + > "join client c on c.id = a.client_id " + > "join account_transaction atr on a.id = atr.account_id " + > "group by a.id, {fn concat({fn concat(c.first_name, ' ')}, > c.last_name)}" > ) > > However, JDBC function escape are (almost) never used in Hibernate > tests, so I wonder if this would need to be handled elsewhere. > > What to do? Do I ignore the documentation tests, add an exception for > Firebird or create a pull request with the above change, or something else? > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mark at lawinegevaar.nl Fri Sep 8 15:13:54 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Fri, 08 Sep 2017 21:13:54 +0200 Subject: [hibernate-dev] Are the tests in the documentation module expected to run on MySQL only? In-Reply-To: References: Message-ID: <3018e96258a820cea6d586b0756579ec@lawinegevaar.nl> On 2017-09-08 20:23, Vlad Mihalcea wrote: > I test Hibernate with the following DBs mostly: > > - H2 > - Oracle > - SQL Server > - PostgreSQL > - MySQL and MariaDb > > For other databases, it's not guaranteed that all tests will run. > > Related to that function, we could other add a change, but it must > work on the DBs above too. > Or, you could just mark the test with @SkipForDialect. In theory all JDBC drivers should support JDBC function escapes (including the concat escape). I'll see if I can quickly verify this for those databases, and otherwise I'll just add a skip for Firebird. Mark From mark at lawinegevaar.nl Sat Sep 9 07:19:36 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 9 Sep 2017 13:19:36 +0200 Subject: [hibernate-dev] Are the tests in the documentation module expected to run on MySQL only? In-Reply-To: References: Message-ID: <68927f8b-a528-51d2-332f-1933266f251a@lawinegevaar.nl> On 8-9-2017 20:23, Vlad Mihalcea wrote: > I test Hibernate with the following DBs mostly: > > - H2 > - Oracle > - SQL Server > - PostgreSQL > - MySQL and MariaDb > > For other databases, it's not guaranteed that all tests will run. > > Related to that function, we could other add a change, but it must work > on the DBs above too. > Or, you could just mark the test with @SkipForDialect. I managed to successfully test my solution on H2, SQL Server, PostgreSQL and MySQL (did not try Oracle and MariaDB yet), but I have decided to go for @SkipForDialect instead for now. I might revisit that decision at a later date. Mark -- Mark Rotteveel From mark at lawinegevaar.nl Sun Sep 10 10:28:22 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sun, 10 Sep 2017 16:28:22 +0200 Subject: [hibernate-dev] Problems with PreparedStatementSpyConnectionProvider Message-ID: <6e9379d1-c5ce-a30f-1e29-925febd998fe@lawinegevaar.nl> I have run into a peculiar problem with PreparedStatementSpyConnectionProvider, the tests that use it fail for Firebird (and Jaybird 3) for reasons I don't understand. As far as I can tell from debugging, in tests that use this class, the statement misbehaves and instead of executing parts of its implementation, the bytecode modifications applied to the statement by PreparedStatementSpyConnectionProvider suddenly return a value from a previous execution, which then causes an exception or other invalid behavior because it is an incorrect value for the current execution path. Has anyone seen this before, and what can I do to address this? Mark -- Mark Rotteveel From mihalcea.vlad at gmail.com Sun Sep 10 10:54:18 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sun, 10 Sep 2017 17:54:18 +0300 Subject: [hibernate-dev] Problems with PreparedStatementSpyConnectionProvider In-Reply-To: <6e9379d1-c5ce-a30f-1e29-925febd998fe@lawinegevaar.nl> References: <6e9379d1-c5ce-a30f-1e29-925febd998fe@lawinegevaar.nl> Message-ID: Hi, The only time when I saw that class failing was for MariaDB because the Connection was final and we could not proxy it. That's when I switched to Mockito 2. However, the goal of that class is to allow it to run as a regular PS, but to proxy it so that any PS call invocation is recorded. Vlad On Sun, Sep 10, 2017 at 5:28 PM, Mark Rotteveel wrote: > I have run into a peculiar problem with > PreparedStatementSpyConnectionProvider, the tests that use it fail for > Firebird (and Jaybird 3) for reasons I don't understand. > > As far as I can tell from debugging, in tests that use this class, the > statement misbehaves and instead of executing parts of its > implementation, the bytecode modifications applied to the statement by > PreparedStatementSpyConnectionProvider suddenly return a value from a > previous execution, which then causes an exception or other invalid > behavior because it is an incorrect value for the current execution path. > > Has anyone seen this before, and what can I do to address this? > > Mark > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Mon Sep 11 09:54:40 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 11 Sep 2017 15:54:40 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: Message-ID: <20170911135440.GA2624@hibernate.org> Hey Yoann and all, Thanks Yoann for stepping up. This is definitely much better. Here are non ordered comments: - Releases speaks less than downloads, Where do I download Hibernate X is a question we want addressed from the top level menus - if you do downloads -> releases, you need to also write some redirect rules not to break URLs - I don't like the term maintained much, I think latest like you proposed makes it more neutral. You could even just name them Series - The migration guide should probably be referenced from each individual series page. - the matrix does not scale very well to that many versions. - in the dedicated series page, "Reference" is confusing, I'd probably replace it with documentation or main documentation Emmanuel On Fri 17-09-08 14:53, Yoann Rodiere wrote: >Hey, > >I pushed an update to staging. I only converted the "Search" part for now. >What changes: > > - The _data folder structured changed a bit, so that we can introduces a > YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary > of this series and a list of integration constraints (ORM > 5.2, etc.) > - The "Downloads" page is renamed to "Releases", since, well, it's about > more than just downloads. See > http://staging.hibernate.org/search/releases/ > - The "Releases" page now includes a "Compatibilty matrix" section based > on the new data I mentioned above > - The "Releases" page now includes links to one page for each series > ("More on the 5.8 series") > - There is now one page for each series (see > http://staging.hibernate.org/search/releases/series/5.8/). This page > includes: > - A short (one-line) summary of this series > - A reminder of the integration constraints for this series > - A section about the main changes in this release. I only wrote > something for the 5.8 series for now, and I basically >copy/pasted sections > from various blog posts. > - A list of all releases in this series. > >What I didn't do, but could make sense: > > - add a sub-menu element under "Releases" for each series > - link to the documentation for each of the latest releases from the > "Releases" page > - link to the latest documentation and to the migration guides from each > series' page > >What do you all think? Emmanuel, would this address your concerns? Steve, >would this be a good fit for ORM? > >Yoann Rodi?re >Hibernate NoORM Team >yoann at hibernate.org > >On 6 September 2017 at 17:16, Steve Ebersole wrote: > >> This is something I brought up ages ago wrt ORM. I wanted something >> (although ideally integrated with the "more version friendly" >> hibernate.org design) similar to what I did atm on the ORM GitHub wiki. >> For example, for 5.2 we have: >> >> >> - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >> - https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >> - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >> >> >> The format could be better and some of this information could be combined >> (release notes and migration guide e.g.). But bear in mind that this was >> just what I put together to illustrate what I was wanted to do, generally >> speaking - so its a bit "rough" >> >> >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >> wrote: >> >>> Thanks for that Emmanuel. >>> >>> I'll fix the one-liner describing the release, I believe we had >>> already noticed this in the past: they need to describe the whole >>> minor not the micro update. >>> The Search roadmap actually also needs a little re-touch, I'll propose >>> a PR for that too. >>> >>> Regarding past roadmaps: I don't like to clutter the roadmap page with >>> the previous copies, especially as they should have a different nature >>> of not being a plan but being a record of what was actually done. >>> Also, we did agree in past meetings to remove all the old ones. e.g. >>> we never ported the release notes for version 3.x and 4.x as back then >>> we decided this was no place for that. Happy to revisit this decision >>> but let's separate them: >>> >>> What about a "past releases" page at the same level of roadmap, and >>> linking to it both from the main Search menu and the roadmap? >>> >>> +1 for Yoann's proposal to re-introduce the compatibility matrix >>> (there was one ~6 years ago). I also had proposed to reintroduce it >>> more recently, and was not done on the grounds that it gets out of >>> date quickly. >>> Still users badly need it so unless someone has a better idea, let's >>> agree on trying to keep it up to date manually. Let's try structure it >>> in such a way that it won't need to be updated for every single >>> release. >>> >>> Thanks, >>> Sanne >>> >>> >>> On 6 September 2017 at 08:37, Yoann Rodiere wrote: >>> > Hey, >>> > >>> > About Search, true, the information is somewhat hidden in many blog >>> posts. >>> > I'm not sure the roadmap is the right place, though, since we probably >>> want >>> > the format to be different for past and future releases: information for >>> > past releases is typically more precise and more verbose, with code >>> > examples and so on. See for instance this blog post: >>> http://in.relation.to/ >>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >>> roadmap >>> > would be drowned in the past releases. >>> > >>> > I was thinking about another problem: we don't have a compatibility >>> matrix. >>> > We only have a few dependencies (mainly ORM and Lucene), but it's really >>> > hard to know which versions of the dependencies to use with which >>> version >>> > of Search, and users frequently use the wrong versions. >>> > With that in mind, I would rather see a "Versions" page, with a summary >>> at >>> > the top (including a one-liner for each minor and the compatibilty >>> matrix), >>> > and one section for each minor (with anchors, so that we can link to >>> them >>> > from other pages such as the downloads). Or maybe even one page for the >>> > detail of each minor, if there's too much text. >>> > I think it would make sense to have all that information gathered in a >>> > single place, because all of that is needed for users to pick the >>> version >>> > they want: they need to know the benefits of upgrading (features) but >>> also >>> > the constraints (compatibility matrix). >>> > Maybe I can give it a try at the end of the week? >>> > >>> > >>> > Yoann Rodi?re >>> > Hibernate NoORM Team >>> > yoann at hibernate.org >>> > >>> > On 6 September 2017 at 09:21, Emmanuel Bernard >>> > wrote: >>> > >>> >> Hey all, >>> >> >>> >> I was trying to answer the following question, what is roughly new >>> between >>> >> 5.6, 5.7 and 5.8 (minor releases)? >>> >> >>> >> My first reflex was to go to http://hibernate.org/search/downloads/ < >>> >> http://hibernate.org/search/downloads/> to read about the onliner per >>> >> release. Except it?s a onliner per micro release and ?minor >>> adjustments? >>> >> for 5.6.3.Final gave me literally no info whatsoever. >>> >> >>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ < >>> >> http://hibernate.org/search/roadmap/> to find a historical entry about >>> >> older versions and the main changes in bullet points. No luck. It only >>> >> talks about the future. >>> >> >>> >> My third reflex was to go to http://in.relation.to/hibernate-search/ < >>> >> http://in.relation.to/hibernate-search/> I ended up giving up midway >>> page >>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >>> releases >>> >> with what?s new since the last CR or the last micro kind of reports and >>> >> gave up in dismay at the energy I would have to spend to extract >>> what?s new >>> >> for a full minor release. >>> >> >>> >> I did exaggerate a bit the third point but I did give up. We need >>> >> somewhere a summary page of what?s new per minor releases. I think the >>> >> roadmap page could be the host. >>> >> Likewise, we might need a oneliner entry in the download section (per >>> >> release) that points to this minor release summary. >>> >> >>> >> Thoughts? >>> >> >>> >> Speaking of roadmap: >>> >> - HV roadmap is massively out of date >>> >> - OGM is lying a bit on the future but at least has the past summary I >>> was >>> >> talking about >>> >> - Search has a good future roadmap but no past >>> >> >>> >> Emmanuek >>> >> _______________________________________________ >>> >> hibernate-dev mailing list >>> >> hibernate-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> From guillaume.smet at gmail.com Mon Sep 11 11:14:44 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 11 Sep 2017 17:14:44 +0200 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter In-Reply-To: References: Message-ID: Hi! Any comment on this? After reading the javadoc of SharedSessionContractImplementor, I think we should probably just get rid of the `checkTransactionSynchStatus();` call in getInterceptor(). I don't think getInterceptor() should be responsible for joining the transaction. What do you all think? -- Guillaume On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet wrote: > Hi, > > Note to Gail: this is potentially a blocking issue for 5.2.11 for the OGM > upgrade (I thought it was a bug in OGM but apparently, it's an issue with > ORM). > > In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the > interceptor field directly because the field has been moved to > AbstractSharedSessionContract. > > See for instance the change made here in afterTransactionCompletion(): > https://github.com/hibernate/hibernate-orm/blame/master/ > hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443 > > I think this is an issue as getInterceptor() is not a simple getter but is: > @Override > public Interceptor getInterceptor() { > checkTransactionSynchStatus(); > return interceptor; > } > > protected void checkTransactionSynchStatus() { > pulseTransactionCoordinator(); > delayedAfterCompletion(); > } > > Thus calling the pulse() method of the TransactionCoordinator, triggering > an implicit join whereas we're in the afterTransactionCompletion() phase. > > This is an issue for us as the pulse() method of our > TransactionCoordinator creates Neo4j transactions so when the > getInterceptor() method is called in afterTransactionCompletion(), we > create a new Neo4j transaction. > > So 2 questions: > - should we really call checkTransactionSynchStatus(); in > getInterceptor()? If feels a bit weird. > - if so, I think we should have a true protected getter (interceptor() > following Steve's convention?) to avoid SessionImpl "pulsing" the > transaction coordinator when accessing the interceptor. > > Thanks for your feedback! > > -- > Guillaume > From davide at hibernate.org Mon Sep 11 11:49:41 2017 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 11 Sep 2017 16:49:41 +0100 Subject: [hibernate-dev] Hibernate OGM 5.2 Alpha1 release Message-ID: HIbernate OGM 5.2 Alpha1 is ready. The first thing you will notice in this release is that several dialects are not part of the core project anymore. We decided to focus our work on the Infinispan, Neo4j and MongoDB dialects. Highlights of the release: - Fixed bugs related to polymorphic hierarchies - Improved query performance in Neo4j - Infinispan Remote dialect via Hot Rod now supports operation grouping - Removed Fongo dialect - Support map-reduce and distinct operations in MongoDB using the MongoDB CLI query language All the details in the blog post: http://in.relation.to/2017/09/11/hibernate-ogm-5-2-Alpha1-released/ Thanks, Davide From sanne at hibernate.org Mon Sep 11 13:38:43 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 11 Sep 2017 18:38:43 +0100 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter In-Reply-To: References: Message-ID: On 11 September 2017 at 16:14, Guillaume Smet wrote: > Hi! > > Any comment on this? > > After reading the javadoc of SharedSessionContractImplementor, I think we > should probably just get rid of the `checkTransactionSynchStatus();` call > in getInterceptor(). > > I don't think getInterceptor() should be responsible for joining the > transaction. > > What do you all think? +1 > > -- > Guillaume > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet > wrote: > >> Hi, >> >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the OGM >> upgrade (I thought it was a bug in OGM but apparently, it's an issue with >> ORM). >> >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the >> interceptor field directly because the field has been moved to >> AbstractSharedSessionContract. >> >> See for instance the change made here in afterTransactionCompletion(): >> https://github.com/hibernate/hibernate-orm/blame/master/ >> hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443 >> >> I think this is an issue as getInterceptor() is not a simple getter but is: >> @Override >> public Interceptor getInterceptor() { >> checkTransactionSynchStatus(); >> return interceptor; >> } >> >> protected void checkTransactionSynchStatus() { >> pulseTransactionCoordinator(); >> delayedAfterCompletion(); >> } >> >> Thus calling the pulse() method of the TransactionCoordinator, triggering >> an implicit join whereas we're in the afterTransactionCompletion() phase. >> >> This is an issue for us as the pulse() method of our >> TransactionCoordinator creates Neo4j transactions so when the >> getInterceptor() method is called in afterTransactionCompletion(), we >> create a new Neo4j transaction. >> >> So 2 questions: >> - should we really call checkTransactionSynchStatus(); in >> getInterceptor()? If feels a bit weird. >> - if so, I think we should have a true protected getter (interceptor() >> following Steve's convention?) to avoid SessionImpl "pulsing" the >> transaction coordinator when accessing the interceptor. >> >> Thanks for your feedback! >> >> -- >> Guillaume >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Sep 11 15:20:54 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 11 Sep 2017 19:20:54 +0000 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter In-Reply-To: References: Message-ID: I'm fine with that. That method really does not fit with the paradigm which needs that pulse. On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero wrote: > On 11 September 2017 at 16:14, Guillaume Smet > wrote: > > Hi! > > > > Any comment on this? > > > > After reading the javadoc of SharedSessionContractImplementor, I think we > > should probably just get rid of the `checkTransactionSynchStatus();` call > > in getInterceptor(). > > > > I don't think getInterceptor() should be responsible for joining the > > transaction. > > > > What do you all think? > > +1 > > > > > -- > > Guillaume > > > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet > > > wrote: > > > >> Hi, > >> > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the > OGM > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue > with > >> ORM). > >> > >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the > >> interceptor field directly because the field has been moved to > >> AbstractSharedSessionContract. > >> > >> See for instance the change made here in afterTransactionCompletion(): > >> https://github.com/hibernate/hibernate-orm/blame/master/ > >> > hibernate-core/src/main/java/org/hibernate/internal/SessionImpl.java#L2443 > >> > >> I think this is an issue as getInterceptor() is not a simple getter but > is: > >> @Override > >> public Interceptor getInterceptor() { > >> checkTransactionSynchStatus(); > >> return interceptor; > >> } > >> > >> protected void checkTransactionSynchStatus() { > >> pulseTransactionCoordinator(); > >> delayedAfterCompletion(); > >> } > >> > >> Thus calling the pulse() method of the TransactionCoordinator, > triggering > >> an implicit join whereas we're in the afterTransactionCompletion() > phase. > >> > >> This is an issue for us as the pulse() method of our > >> TransactionCoordinator creates Neo4j transactions so when the > >> getInterceptor() method is called in afterTransactionCompletion(), we > >> create a new Neo4j transaction. > >> > >> So 2 questions: > >> - should we really call checkTransactionSynchStatus(); in > >> getInterceptor()? If feels a bit weird. > >> - if so, I think we should have a true protected getter (interceptor() > >> following Steve's convention?) to avoid SessionImpl "pulsing" the > >> transaction coordinator when accessing the interceptor. > >> > >> Thanks for your feedback! > >> > >> -- > >> Guillaume > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Tue Sep 12 01:52:45 2017 From: gbadner at redhat.com (Gail Badner) Date: Mon, 11 Sep 2017 22:52:45 -0700 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter In-Reply-To: References: Message-ID: OK, I'll fix it for 5.2.11. Thanks, Gail On Mon, Sep 11, 2017 at 12:20 PM, Steve Ebersole wrote: > I'm fine with that. That method really does not fit with the paradigm > which needs that pulse. > > > On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero > wrote: > > > On 11 September 2017 at 16:14, Guillaume Smet > > wrote: > > > Hi! > > > > > > Any comment on this? > > > > > > After reading the javadoc of SharedSessionContractImplementor, I > think we > > > should probably just get rid of the `checkTransactionSynchStatus();` > call > > > in getInterceptor(). > > > > > > I don't think getInterceptor() should be responsible for joining the > > > transaction. > > > > > > What do you all think? > > > > +1 > > > > > > > > -- > > > Guillaume > > > > > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet < > guillaume.smet at gmail.com > > > > > > wrote: > > > > > >> Hi, > > >> > > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the > > OGM > > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue > > with > > >> ORM). > > >> > > >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing > the > > >> interceptor field directly because the field has been moved to > > >> AbstractSharedSessionContract. > > >> > > >> See for instance the change made here in afterTransactionCompletion(): > > >> https://github.com/hibernate/hibernate-orm/blame/master/ > > >> > > hibernate-core/src/main/java/org/hibernate/internal/ > SessionImpl.java#L2443 > > >> > > >> I think this is an issue as getInterceptor() is not a simple getter > but > > is: > > >> @Override > > >> public Interceptor getInterceptor() { > > >> checkTransactionSynchStatus(); > > >> return interceptor; > > >> } > > >> > > >> protected void checkTransactionSynchStatus() { > > >> pulseTransactionCoordinator(); > > >> delayedAfterCompletion(); > > >> } > > >> > > >> Thus calling the pulse() method of the TransactionCoordinator, > > triggering > > >> an implicit join whereas we're in the afterTransactionCompletion() > > phase. > > >> > > >> This is an issue for us as the pulse() method of our > > >> TransactionCoordinator creates Neo4j transactions so when the > > >> getInterceptor() method is called in afterTransactionCompletion(), we > > >> create a new Neo4j transaction. > > >> > > >> So 2 questions: > > >> - should we really call checkTransactionSynchStatus(); in > > >> getInterceptor()? If feels a bit weird. > > >> - if so, I think we should have a true protected getter (interceptor() > > >> following Steve's convention?) to avoid SessionImpl "pulsing" the > > >> transaction coordinator when accessing the interceptor. > > >> > > >> Thanks for your feedback! > > >> > > >> -- > > >> Guillaume > > >> > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Tue Sep 12 02:10:11 2017 From: gbadner at redhat.com (Gail Badner) Date: Mon, 11 Sep 2017 23:10:11 -0700 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter In-Reply-To: References: Message-ID: I created https://hibernate.atlassian.net/browse/HHH-11982. I just committed the one-line change without a unit test. Unless I hear otherwise, I'll assume that's OK and I'll plan to release on Wednesday, 9/13. Regards, Gail On Mon, Sep 11, 2017 at 10:52 PM, Gail Badner wrote: > OK, I'll fix it for 5.2.11. > > Thanks, > Gail > > On Mon, Sep 11, 2017 at 12:20 PM, Steve Ebersole > wrote: > >> I'm fine with that. That method really does not fit with the paradigm >> which needs that pulse. >> >> >> On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero >> wrote: >> >> > On 11 September 2017 at 16:14, Guillaume Smet > > >> > wrote: >> > > Hi! >> > > >> > > Any comment on this? >> > > >> > > After reading the javadoc of SharedSessionContractImplementor, I >> think we >> > > should probably just get rid of the `checkTransactionSynchStatus();` >> call >> > > in getInterceptor(). >> > > >> > > I don't think getInterceptor() should be responsible for joining the >> > > transaction. >> > > >> > > What do you all think? >> > >> > +1 >> > >> > > >> > > -- >> > > Guillaume >> > > >> > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet < >> guillaume.smet at gmail.com >> > > >> > > wrote: >> > > >> > >> Hi, >> > >> >> > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for the >> > OGM >> > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue >> > with >> > >> ORM). >> > >> >> > >> In 5.2 SessionImpl, we now use getInterceptor() instead of accessing >> the >> > >> interceptor field directly because the field has been moved to >> > >> AbstractSharedSessionContract. >> > >> >> > >> See for instance the change made here in >> afterTransactionCompletion(): >> > >> https://github.com/hibernate/hibernate-orm/blame/master/ >> > >> >> > hibernate-core/src/main/java/org/hibernate/internal/SessionI >> mpl.java#L2443 >> > >> >> > >> I think this is an issue as getInterceptor() is not a simple getter >> but >> > is: >> > >> @Override >> > >> public Interceptor getInterceptor() { >> > >> checkTransactionSynchStatus(); >> > >> return interceptor; >> > >> } >> > >> >> > >> protected void checkTransactionSynchStatus() { >> > >> pulseTransactionCoordinator(); >> > >> delayedAfterCompletion(); >> > >> } >> > >> >> > >> Thus calling the pulse() method of the TransactionCoordinator, >> > triggering >> > >> an implicit join whereas we're in the afterTransactionCompletion() >> > phase. >> > >> >> > >> This is an issue for us as the pulse() method of our >> > >> TransactionCoordinator creates Neo4j transactions so when the >> > >> getInterceptor() method is called in afterTransactionCompletion(), we >> > >> create a new Neo4j transaction. >> > >> >> > >> So 2 questions: >> > >> - should we really call checkTransactionSynchStatus(); in >> > >> getInterceptor()? If feels a bit weird. >> > >> - if so, I think we should have a true protected getter >> (interceptor() >> > >> following Steve's convention?) to avoid SessionImpl "pulsing" the >> > >> transaction coordinator when accessing the interceptor. >> > >> >> > >> Thanks for your feedback! >> > >> >> > >> -- >> > >> Guillaume >> > >> >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Tue Sep 12 03:02:58 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 12 Sep 2017 09:02:58 +0200 Subject: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter In-Reply-To: References: Message-ID: Thanks Gail! On Tue, Sep 12, 2017 at 8:10 AM, Gail Badner wrote: > I created https://hibernate.atlassian.net/browse/HHH-11982. > > I just committed the one-line change without a unit test. Unless I hear > otherwise, I'll assume that's OK and I'll plan to release on Wednesday, > 9/13. > > Regards, > Gail > > On Mon, Sep 11, 2017 at 10:52 PM, Gail Badner wrote: > >> OK, I'll fix it for 5.2.11. >> >> Thanks, >> Gail >> >> On Mon, Sep 11, 2017 at 12:20 PM, Steve Ebersole >> wrote: >> >>> I'm fine with that. That method really does not fit with the paradigm >>> which needs that pulse. >>> >>> >>> On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero >>> wrote: >>> >>> > On 11 September 2017 at 16:14, Guillaume Smet < >>> guillaume.smet at gmail.com> >>> > wrote: >>> > > Hi! >>> > > >>> > > Any comment on this? >>> > > >>> > > After reading the javadoc of SharedSessionContractImplementor, I >>> think we >>> > > should probably just get rid of the `checkTransactionSynchStatus();` >>> call >>> > > in getInterceptor(). >>> > > >>> > > I don't think getInterceptor() should be responsible for joining the >>> > > transaction. >>> > > >>> > > What do you all think? >>> > >>> > +1 >>> > >>> > > >>> > > -- >>> > > Guillaume >>> > > >>> > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet < >>> guillaume.smet at gmail.com >>> > > >>> > > wrote: >>> > > >>> > >> Hi, >>> > >> >>> > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for >>> the >>> > OGM >>> > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue >>> > with >>> > >> ORM). >>> > >> >>> > >> In 5.2 SessionImpl, we now use getInterceptor() instead of >>> accessing the >>> > >> interceptor field directly because the field has been moved to >>> > >> AbstractSharedSessionContract. >>> > >> >>> > >> See for instance the change made here in >>> afterTransactionCompletion(): >>> > >> https://github.com/hibernate/hibernate-orm/blame/master/ >>> > >> >>> > hibernate-core/src/main/java/org/hibernate/internal/SessionI >>> mpl.java#L2443 >>> > >> >>> > >> I think this is an issue as getInterceptor() is not a simple getter >>> but >>> > is: >>> > >> @Override >>> > >> public Interceptor getInterceptor() { >>> > >> checkTransactionSynchStatus(); >>> > >> return interceptor; >>> > >> } >>> > >> >>> > >> protected void checkTransactionSynchStatus() { >>> > >> pulseTransactionCoordinator(); >>> > >> delayedAfterCompletion(); >>> > >> } >>> > >> >>> > >> Thus calling the pulse() method of the TransactionCoordinator, >>> > triggering >>> > >> an implicit join whereas we're in the afterTransactionCompletion() >>> > phase. >>> > >> >>> > >> This is an issue for us as the pulse() method of our >>> > >> TransactionCoordinator creates Neo4j transactions so when the >>> > >> getInterceptor() method is called in afterTransactionCompletion(), >>> we >>> > >> create a new Neo4j transaction. >>> > >> >>> > >> So 2 questions: >>> > >> - should we really call checkTransactionSynchStatus(); in >>> > >> getInterceptor()? If feels a bit weird. >>> > >> - if so, I think we should have a true protected getter >>> (interceptor() >>> > >> following Steve's convention?) to avoid SessionImpl "pulsing" the >>> > >> transaction coordinator when accessing the interceptor. >>> > >> >>> > >> Thanks for your feedback! >>> > >> >>> > >> -- >>> > >> Guillaume >>> > >> >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > From yoann at hibernate.org Tue Sep 12 03:42:01 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 12 Sep 2017 09:42:01 +0200 Subject: [hibernate-dev] [SEARCH] Code style - imports Message-ID: Hello all, I just noticed that our IDEA codestyle configuration files have specific rules about how to organize imports, whereas the Eclipse ones don't. The most noticeable difference: organizing imports in Eclipse puts static imports at the top, while in IDEA they end up at the bottom. But there are other differences. The Hibernate ORM codebase doesn't seem affected by these inconsistencies (probably because most people working on it use IDEA), but in Hibernate Search we've already reached the point where half of our files follow one convention, and the other half follows the other. What's annoying here is not the inconsistencies themselves (I could live with that), it's more that in the long run we'll end up with tons of unnecessary changes in our commits, due to one person using IDEA to edit a file last edited with Eclipse, and vice-versa. To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot configure Eclipse to match the IDEA style exactly. In particular, we cannot configure where the static imports must go: they will always go to the top ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). I can see two ways out, each with its own drawbacks: - Switch to the "Eclipse" style, and create a Search-specific IDEA code style configuration, with static imports at the top. We won't be consistent with Hibernate ORM, though. - Switch to the "IDEA" style, and create a Search-specific Eclipse code style configuration, as close as the IDEA style as possible. As I said above, automatic import organizing in Eclipse will never follow this style exactly, so it's likely to make organizing imports in Eclipse quite painful. We could add checkstyle rules to make sure we strictly follow the style even in Eclipse. WDYT? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From sanne at hibernate.org Tue Sep 12 05:13:06 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Sep 2017 10:13:06 +0100 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: Fundamentally no IDE will ever produce exactly the same code so you need to learn control your primal lust for perfection and remember it's not relevant. Have some decency ;) What does actually matter is that we don't keep chaging the order as it introduces conflicts on backporting, it's very annoying and time consuming in the long run. My solution is simple: I don't generally care, BUT commits containing code reformats just for the sake of making one's favourite tool happy need be rejected, especially to stop the bad habit from developing further, or anyone trying to impose its own favourite tool of the day as it was the only blessed way. It's fine if a couple of import reorg "slip in" as part as meaningful changes. The real problem is that applying a patch shouldn't conflict on import statements; ideally there should be a conflict resolution strategy able to understand it better (e.g. teach Java to git tools..) If you want to volunteer making the styles a bit more similar, I typically prefer static imports last. -1 for CheckStyle rules unless you can figure out a way to exclude existing code from failing: we're not going to reformat half the code base to satisfy aesthetics. Perhaps we could have separate sets of rules, some stricter to be applied on new modules; their impact would be limited but even having one module with strict rules would encourage people to reconfigure their IDE in "the right way". This would ensure all new code will be consistent with the rules. Sergey sent a related PR but I'm not sure what to think of it as it changes several things: - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 Thanks, Sanne On 12 September 2017 at 08:42, Yoann Rodiere wrote: > Hello all, > > I just noticed that our IDEA codestyle configuration files have specific > rules about how to organize imports, whereas the Eclipse ones don't. > The most noticeable difference: organizing imports in Eclipse puts static > imports at the top, while in IDEA they end up at the bottom. But there are > other differences. > The Hibernate ORM codebase doesn't seem affected by these inconsistencies > (probably because most people working on it use IDEA), but in Hibernate > Search we've already reached the point where half of our files follow one > convention, and the other half follows the other. > > What's annoying here is not the inconsistencies themselves (I could live > with that), it's more that in the long run we'll end up with tons of > unnecessary changes in our commits, due to one person using IDEA to edit a > file last edited with Eclipse, and vice-versa. > > To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot > configure Eclipse to match the IDEA style exactly. In particular, we cannot > configure where the static imports must go: they will always go to the top ( > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). > > I can see two ways out, each with its own drawbacks: > > - Switch to the "Eclipse" style, and create a Search-specific IDEA code > style configuration, with static imports at the top. We won't be consistent > with Hibernate ORM, though. > - Switch to the "IDEA" style, and create a Search-specific Eclipse code > style configuration, as close as the IDEA style as possible. As I said > above, automatic import organizing in Eclipse will never follow this style > exactly, so it's likely to make organizing imports in Eclipse quite > painful. We could add checkstyle rules to make sure we strictly follow the > style even in Eclipse. > > WDYT? > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Sep 12 05:31:19 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 12 Sep 2017 11:31:19 +0200 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: Hi, Yes, I had a hard time reverting the import changes in my recent patches for ORM. I was changing only a few lines per file and had a lot of import noise. I would say that it would be nice to have Eclipse and Idea rules as similar as possible. The issue with that is that, for a while, the ORM people will have a lot of import changes, considering we can't make the Eclipse rules Idea like but we can do the opposite. If we don't want to bother the ORM team with that, we should split our rules between ORM and NoORM but it won't be very underestandable for the contributors (but it's not as if we had a lot of them and very few of them find our code styles without us mentioning them). -- Guillaume On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero wrote: > Fundamentally no IDE will ever produce exactly the same code so you > need to learn control your primal lust for perfection and remember > it's not relevant. Have some decency ;) > > What does actually matter is that we don't keep chaging the order as > it introduces conflicts on backporting, it's very annoying and time > consuming in the long run. > > My solution is simple: I don't generally care, BUT commits containing > code reformats just for the sake of making one's favourite tool happy > need be rejected, especially to stop the bad habit from developing > further, or anyone trying to impose its own favourite tool of the day > as it was the only blessed way. > It's fine if a couple of import reorg "slip in" as part as meaningful > changes. > > The real problem is that applying a patch shouldn't conflict on import > statements; ideally there should be a conflict resolution strategy > able to understand it better (e.g. teach Java to git tools..) > > If you want to volunteer making the styles a bit more similar, I > typically prefer static imports last. > > -1 for CheckStyle rules unless you can figure out a way to exclude > existing code from failing: we're not going to reformat half the code > base to satisfy aesthetics. > > Perhaps we could have separate sets of rules, some stricter to be > applied on new modules; their impact would be limited but even having > one module with strict rules would encourage people to reconfigure > their IDE in "the right way". This would ensure all new code will be > consistent with the rules. > > Sergey sent a related PR but I'm not sure what to think of it as it > changes several things: > - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > > Thanks, > Sanne > > > > On 12 September 2017 at 08:42, Yoann Rodiere wrote: > > Hello all, > > > > I just noticed that our IDEA codestyle configuration files have specific > > rules about how to organize imports, whereas the Eclipse ones don't. > > The most noticeable difference: organizing imports in Eclipse puts static > > imports at the top, while in IDEA they end up at the bottom. But there > are > > other differences. > > The Hibernate ORM codebase doesn't seem affected by these inconsistencies > > (probably because most people working on it use IDEA), but in Hibernate > > Search we've already reached the point where half of our files follow one > > convention, and the other half follows the other. > > > > What's annoying here is not the inconsistencies themselves (I could live > > with that), it's more that in the long run we'll end up with tons of > > unnecessary changes in our commits, due to one person using IDEA to edit > a > > file last edited with Eclipse, and vice-versa. > > > > To make the matter worse, Eclipse is not as flexible as IDEA, and we > cannot > > configure Eclipse to match the IDEA style exactly. In particular, we > cannot > > configure where the static imports must go: they will always go to the > top ( > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). > > > > I can see two ways out, each with its own drawbacks: > > > > - Switch to the "Eclipse" style, and create a Search-specific IDEA > code > > style configuration, with static imports at the top. We won't be > consistent > > with Hibernate ORM, though. > > - Switch to the "IDEA" style, and create a Search-specific Eclipse > code > > style configuration, as close as the IDEA style as possible. As I said > > above, automatic import organizing in Eclipse will never follow this > style > > exactly, so it's likely to make organizing imports in Eclipse quite > > painful. We could add checkstyle rules to make sure we strictly > follow the > > style even in Eclipse. > > > > WDYT? > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Tue Sep 12 05:42:23 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 12 Sep 2017 11:42:23 +0200 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: > > Fundamentally no IDE will ever produce exactly the same code so you > need to learn control your primal lust for perfection and remember > it's not relevant. Have some decency ;) Sorry if that seemed "indecent", but I did mention that I could live with the inconsistencies, and that what matters is their effect on our git workflow :) If you want to volunteer making the styles a bit more similar, I > typically prefer static imports last. Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try to align the rest of the rules, though. Sergey sent a related PR but I'm not sure what to think of it as it > changes several things: > - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 Yes, it does more than what it advertises, and even the original idea (putting static imports to the top) is not a good idea: ORM already has static imports at the bottom in almost every file, so this change would lead to many more changes than necessary in commits for the ORM project for some time. I would say that it would be nice to have Eclipse and Idea rules as similar > as possible. The issue with that is that, for a while, the ORM people will > have a lot of import changes, considering we can't make the Eclipse rules > Idea like but we can do the opposite. I doubt they'll ever agree with this solution. And I can't blame them. If we don't want to bother the ORM team with that, we should split our > rules between ORM and NoORM but it won't be very underestandable for the > contributors (but it's not as if we had a lot of them and very few of them > find our code styles without us mentioning them). > Seems to be the least disruptive solution. It's not ideal, but it should improve the situation slightly and it wouldn't lead to more changes than necessary in the future git commits. @Sanne this means the imports will stay at the top, though. Ok with that? I'll try to see if I can add non-disruptive checkstyle rules too, if I have some time. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 12 September 2017 at 11:31, Guillaume Smet wrote: > Hi, > > Yes, I had a hard time reverting the import changes in my recent patches > for ORM. I was changing only a few lines per file and had a lot of import > noise. > > I would say that it would be nice to have Eclipse and Idea rules as > similar as possible. The issue with that is that, for a while, the ORM > people will have a lot of import changes, considering we can't make the > Eclipse rules Idea like but we can do the opposite. > > If we don't want to bother the ORM team with that, we should split our > rules between ORM and NoORM but it won't be very underestandable for the > contributors (but it's not as if we had a lot of them and very few of them > find our code styles without us mentioning them). > > -- > Guillaume > > > On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero > wrote: > >> Fundamentally no IDE will ever produce exactly the same code so you >> need to learn control your primal lust for perfection and remember >> it's not relevant. Have some decency ;) >> >> What does actually matter is that we don't keep chaging the order as >> it introduces conflicts on backporting, it's very annoying and time >> consuming in the long run. >> >> My solution is simple: I don't generally care, BUT commits containing >> code reformats just for the sake of making one's favourite tool happy >> need be rejected, especially to stop the bad habit from developing >> further, or anyone trying to impose its own favourite tool of the day >> as it was the only blessed way. >> It's fine if a couple of import reorg "slip in" as part as meaningful >> changes. >> >> The real problem is that applying a patch shouldn't conflict on import >> statements; ideally there should be a conflict resolution strategy >> able to understand it better (e.g. teach Java to git tools..) >> >> If you want to volunteer making the styles a bit more similar, I >> typically prefer static imports last. >> >> -1 for CheckStyle rules unless you can figure out a way to exclude >> existing code from failing: we're not going to reformat half the code >> base to satisfy aesthetics. >> >> Perhaps we could have separate sets of rules, some stricter to be >> applied on new modules; their impact would be limited but even having >> one module with strict rules would encourage people to reconfigure >> their IDE in "the right way". This would ensure all new code will be >> consistent with the rules. >> >> Sergey sent a related PR but I'm not sure what to think of it as it >> changes several things: >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 >> >> Thanks, >> Sanne >> >> >> >> On 12 September 2017 at 08:42, Yoann Rodiere wrote: >> > Hello all, >> > >> > I just noticed that our IDEA codestyle configuration files have specific >> > rules about how to organize imports, whereas the Eclipse ones don't. >> > The most noticeable difference: organizing imports in Eclipse puts >> static >> > imports at the top, while in IDEA they end up at the bottom. But there >> are >> > other differences. >> > The Hibernate ORM codebase doesn't seem affected by these >> inconsistencies >> > (probably because most people working on it use IDEA), but in Hibernate >> > Search we've already reached the point where half of our files follow >> one >> > convention, and the other half follows the other. >> > >> > What's annoying here is not the inconsistencies themselves (I could live >> > with that), it's more that in the long run we'll end up with tons of >> > unnecessary changes in our commits, due to one person using IDEA to >> edit a >> > file last edited with Eclipse, and vice-versa. >> > >> > To make the matter worse, Eclipse is not as flexible as IDEA, and we >> cannot >> > configure Eclipse to match the IDEA style exactly. In particular, we >> cannot >> > configure where the static imports must go: they will always go to the >> top ( >> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). >> > >> > I can see two ways out, each with its own drawbacks: >> > >> > - Switch to the "Eclipse" style, and create a Search-specific IDEA >> code >> > style configuration, with static imports at the top. We won't be >> consistent >> > with Hibernate ORM, though. >> > - Switch to the "IDEA" style, and create a Search-specific Eclipse >> code >> > style configuration, as close as the IDEA style as possible. As I >> said >> > above, automatic import organizing in Eclipse will never follow this >> style >> > exactly, so it's likely to make organizing imports in Eclipse quite >> > painful. We could add checkstyle rules to make sure we strictly >> follow the >> > style even in Eclipse. >> > >> > WDYT? >> > >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From sanne at hibernate.org Tue Sep 12 05:45:54 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Sep 2017 10:45:54 +0100 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: On 12 September 2017 at 10:42, Yoann Rodiere wrote: >> Fundamentally no IDE will ever produce exactly the same code so you >> need to learn control your primal lust for perfection and remember >> it's not relevant. Have some decency ;) > > > Sorry if that seemed "indecent", but I did mention that I could live with > the inconsistencies, and that what matters is their effect on our git > workflow :) > >> If you want to volunteer making the styles a bit more similar, I >> typically prefer static imports last. > > > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try to > align the rest of the rules, though. > >> Sergey sent a related PR but I'm not sure what to think of it as it >> changes several things: >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > > > Yes, it does more than what it advertises, and even the original idea > (putting static imports to the top) is not a good idea: ORM already has > static imports at the bottom in almost every file, so this change would lead > to many more changes than necessary in commits for the ORM project for some > time. > >> I would say that it would be nice to have Eclipse and Idea rules as >> similar as possible. The issue with that is that, for a while, the ORM >> people will have a lot of import changes, considering we can't make the >> Eclipse rules Idea like but we can do the opposite. > > > I doubt they'll ever agree with this solution. And I can't blame them. > >> If we don't want to bother the ORM team with that, we should split our >> rules between ORM and NoORM but it won't be very underestandable for the >> contributors (but it's not as if we had a lot of them and very few of them >> find our code styles without us mentioning them). > > > Seems to be the least disruptive solution. It's not ideal, but it should > improve the situation slightly and it wouldn't lead to more changes than > necessary in the future git commits. > @Sanne this means the imports will stay at the top, though. Ok with that? Yes I'm "ok" with that. But wouldn't it be even better to leave this level of detail undefined? At least it would allow me to make new code having them on the bottom as I like them more, and you'd save some itme :) > > I'll try to see if I can add non-disruptive checkstyle rules too, if I have > some time. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 12 September 2017 at 11:31, Guillaume Smet > wrote: >> >> Hi, >> >> Yes, I had a hard time reverting the import changes in my recent patches >> for ORM. I was changing only a few lines per file and had a lot of import >> noise. >> >> I would say that it would be nice to have Eclipse and Idea rules as >> similar as possible. The issue with that is that, for a while, the ORM >> people will have a lot of import changes, considering we can't make the >> Eclipse rules Idea like but we can do the opposite. >> >> If we don't want to bother the ORM team with that, we should split our >> rules between ORM and NoORM but it won't be very underestandable for the >> contributors (but it's not as if we had a lot of them and very few of them >> find our code styles without us mentioning them). >> >> -- >> Guillaume >> >> >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero >> wrote: >>> >>> Fundamentally no IDE will ever produce exactly the same code so you >>> need to learn control your primal lust for perfection and remember >>> it's not relevant. Have some decency ;) >>> >>> What does actually matter is that we don't keep chaging the order as >>> it introduces conflicts on backporting, it's very annoying and time >>> consuming in the long run. >>> >>> My solution is simple: I don't generally care, BUT commits containing >>> code reformats just for the sake of making one's favourite tool happy >>> need be rejected, especially to stop the bad habit from developing >>> further, or anyone trying to impose its own favourite tool of the day >>> as it was the only blessed way. >>> It's fine if a couple of import reorg "slip in" as part as meaningful >>> changes. >>> >>> The real problem is that applying a patch shouldn't conflict on import >>> statements; ideally there should be a conflict resolution strategy >>> able to understand it better (e.g. teach Java to git tools..) >>> >>> If you want to volunteer making the styles a bit more similar, I >>> typically prefer static imports last. >>> >>> -1 for CheckStyle rules unless you can figure out a way to exclude >>> existing code from failing: we're not going to reformat half the code >>> base to satisfy aesthetics. >>> >>> Perhaps we could have separate sets of rules, some stricter to be >>> applied on new modules; their impact would be limited but even having >>> one module with strict rules would encourage people to reconfigure >>> their IDE in "the right way". This would ensure all new code will be >>> consistent with the rules. >>> >>> Sergey sent a related PR but I'm not sure what to think of it as it >>> changes several things: >>> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 >>> >>> Thanks, >>> Sanne >>> >>> >>> >>> On 12 September 2017 at 08:42, Yoann Rodiere wrote: >>> > Hello all, >>> > >>> > I just noticed that our IDEA codestyle configuration files have >>> > specific >>> > rules about how to organize imports, whereas the Eclipse ones don't. >>> > The most noticeable difference: organizing imports in Eclipse puts >>> > static >>> > imports at the top, while in IDEA they end up at the bottom. But there >>> > are >>> > other differences. >>> > The Hibernate ORM codebase doesn't seem affected by these >>> > inconsistencies >>> > (probably because most people working on it use IDEA), but in Hibernate >>> > Search we've already reached the point where half of our files follow >>> > one >>> > convention, and the other half follows the other. >>> > >>> > What's annoying here is not the inconsistencies themselves (I could >>> > live >>> > with that), it's more that in the long run we'll end up with tons of >>> > unnecessary changes in our commits, due to one person using IDEA to >>> > edit a >>> > file last edited with Eclipse, and vice-versa. >>> > >>> > To make the matter worse, Eclipse is not as flexible as IDEA, and we >>> > cannot >>> > configure Eclipse to match the IDEA style exactly. In particular, we >>> > cannot >>> > configure where the static imports must go: they will always go to the >>> > top ( >>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). >>> > >>> > I can see two ways out, each with its own drawbacks: >>> > >>> > - Switch to the "Eclipse" style, and create a Search-specific IDEA >>> > code >>> > style configuration, with static imports at the top. We won't be >>> > consistent >>> > with Hibernate ORM, though. >>> > - Switch to the "IDEA" style, and create a Search-specific Eclipse >>> > code >>> > style configuration, as close as the IDEA style as possible. As I >>> > said >>> > above, automatic import organizing in Eclipse will never follow this >>> > style >>> > exactly, so it's likely to make organizing imports in Eclipse quite >>> > painful. We could add checkstyle rules to make sure we strictly >>> > follow the >>> > style even in Eclipse. >>> > >>> > WDYT? >>> > >>> > >>> > Yoann Rodi?re >>> > Hibernate NoORM Team >>> > yoann at hibernate.org >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > From yoann at hibernate.org Tue Sep 12 05:49:00 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 12 Sep 2017 11:49:00 +0200 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: Well, if you don't mind me sending PRs with those imports in a different order next time I change the file (because I don't spend time on organizing imports manually, I just use CTRL+SHIFT+O), then yes, we can leave that undefined. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 12 September 2017 at 11:45, Sanne Grinovero wrote: > On 12 September 2017 at 10:42, Yoann Rodiere wrote: > >> Fundamentally no IDE will ever produce exactly the same code so you > >> need to learn control your primal lust for perfection and remember > >> it's not relevant. Have some decency ;) > > > > > > Sorry if that seemed "indecent", but I did mention that I could live with > > the inconsistencies, and that what matters is their effect on our git > > workflow :) > > > >> If you want to volunteer making the styles a bit more similar, I > >> typically prefer static imports last. > > > > > > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try > to > > align the rest of the rules, though. > > > >> Sergey sent a related PR but I'm not sure what to think of it as it > >> changes several things: > >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > > > > > > Yes, it does more than what it advertises, and even the original idea > > (putting static imports to the top) is not a good idea: ORM already has > > static imports at the bottom in almost every file, so this change would > lead > > to many more changes than necessary in commits for the ORM project for > some > > time. > > > >> I would say that it would be nice to have Eclipse and Idea rules as > >> similar as possible. The issue with that is that, for a while, the ORM > >> people will have a lot of import changes, considering we can't make the > >> Eclipse rules Idea like but we can do the opposite. > > > > > > I doubt they'll ever agree with this solution. And I can't blame them. > > > >> If we don't want to bother the ORM team with that, we should split our > >> rules between ORM and NoORM but it won't be very underestandable for the > >> contributors (but it's not as if we had a lot of them and very few of > them > >> find our code styles without us mentioning them). > > > > > > Seems to be the least disruptive solution. It's not ideal, but it should > > improve the situation slightly and it wouldn't lead to more changes than > > necessary in the future git commits. > > @Sanne this means the imports will stay at the top, though. Ok with that? > > Yes I'm "ok" with that. But wouldn't it be even better to leave this > level of detail undefined? > > At least it would allow me to make new code having them on the bottom > as I like them more, and you'd save some itme :) > > > > > I'll try to see if I can add non-disruptive checkstyle rules too, if I > have > > some time. > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 12 September 2017 at 11:31, Guillaume Smet > > wrote: > >> > >> Hi, > >> > >> Yes, I had a hard time reverting the import changes in my recent patches > >> for ORM. I was changing only a few lines per file and had a lot of > import > >> noise. > >> > >> I would say that it would be nice to have Eclipse and Idea rules as > >> similar as possible. The issue with that is that, for a while, the ORM > >> people will have a lot of import changes, considering we can't make the > >> Eclipse rules Idea like but we can do the opposite. > >> > >> If we don't want to bother the ORM team with that, we should split our > >> rules between ORM and NoORM but it won't be very underestandable for the > >> contributors (but it's not as if we had a lot of them and very few of > them > >> find our code styles without us mentioning them). > >> > >> -- > >> Guillaume > >> > >> > >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero > >> wrote: > >>> > >>> Fundamentally no IDE will ever produce exactly the same code so you > >>> need to learn control your primal lust for perfection and remember > >>> it's not relevant. Have some decency ;) > >>> > >>> What does actually matter is that we don't keep chaging the order as > >>> it introduces conflicts on backporting, it's very annoying and time > >>> consuming in the long run. > >>> > >>> My solution is simple: I don't generally care, BUT commits containing > >>> code reformats just for the sake of making one's favourite tool happy > >>> need be rejected, especially to stop the bad habit from developing > >>> further, or anyone trying to impose its own favourite tool of the day > >>> as it was the only blessed way. > >>> It's fine if a couple of import reorg "slip in" as part as meaningful > >>> changes. > >>> > >>> The real problem is that applying a patch shouldn't conflict on import > >>> statements; ideally there should be a conflict resolution strategy > >>> able to understand it better (e.g. teach Java to git tools..) > >>> > >>> If you want to volunteer making the styles a bit more similar, I > >>> typically prefer static imports last. > >>> > >>> -1 for CheckStyle rules unless you can figure out a way to exclude > >>> existing code from failing: we're not going to reformat half the code > >>> base to satisfy aesthetics. > >>> > >>> Perhaps we could have separate sets of rules, some stricter to be > >>> applied on new modules; their impact would be limited but even having > >>> one module with strict rules would encourage people to reconfigure > >>> their IDE in "the right way". This would ensure all new code will be > >>> consistent with the rules. > >>> > >>> Sergey sent a related PR but I'm not sure what to think of it as it > >>> changes several things: > >>> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> > >>> On 12 September 2017 at 08:42, Yoann Rodiere > wrote: > >>> > Hello all, > >>> > > >>> > I just noticed that our IDEA codestyle configuration files have > >>> > specific > >>> > rules about how to organize imports, whereas the Eclipse ones don't. > >>> > The most noticeable difference: organizing imports in Eclipse puts > >>> > static > >>> > imports at the top, while in IDEA they end up at the bottom. But > there > >>> > are > >>> > other differences. > >>> > The Hibernate ORM codebase doesn't seem affected by these > >>> > inconsistencies > >>> > (probably because most people working on it use IDEA), but in > Hibernate > >>> > Search we've already reached the point where half of our files follow > >>> > one > >>> > convention, and the other half follows the other. > >>> > > >>> > What's annoying here is not the inconsistencies themselves (I could > >>> > live > >>> > with that), it's more that in the long run we'll end up with tons of > >>> > unnecessary changes in our commits, due to one person using IDEA to > >>> > edit a > >>> > file last edited with Eclipse, and vice-versa. > >>> > > >>> > To make the matter worse, Eclipse is not as flexible as IDEA, and we > >>> > cannot > >>> > configure Eclipse to match the IDEA style exactly. In particular, we > >>> > cannot > >>> > configure where the static imports must go: they will always go to > the > >>> > top ( > >>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). > >>> > > >>> > I can see two ways out, each with its own drawbacks: > >>> > > >>> > - Switch to the "Eclipse" style, and create a Search-specific IDEA > >>> > code > >>> > style configuration, with static imports at the top. We won't be > >>> > consistent > >>> > with Hibernate ORM, though. > >>> > - Switch to the "IDEA" style, and create a Search-specific Eclipse > >>> > code > >>> > style configuration, as close as the IDEA style as possible. As I > >>> > said > >>> > above, automatic import organizing in Eclipse will never follow > this > >>> > style > >>> > exactly, so it's likely to make organizing imports in Eclipse > quite > >>> > painful. We could add checkstyle rules to make sure we strictly > >>> > follow the > >>> > style even in Eclipse. > >>> > > >>> > WDYT? > >>> > > >>> > > >>> > Yoann Rodi?re > >>> > Hibernate NoORM Team > >>> > yoann at hibernate.org > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > > From guillaume.smet at gmail.com Tue Sep 12 05:49:59 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 12 Sep 2017 11:49:59 +0200 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: On Tue, Sep 12, 2017 at 11:45 AM, Sanne Grinovero wrote: > Yes I'm "ok" with that. But wouldn't it be even better to leave this > level of detail undefined? > > At least it would allow me to make new code having them on the bottom > as I like them more, and you'd save some itme :) > The issue is not you writing new code, it's us updating it and reorganizing the import with the Eclipse rules. -- Guillaume From sanne at hibernate.org Tue Sep 12 05:51:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Sep 2017 10:51:50 +0100 Subject: [hibernate-dev] [SEARCH] Code style - imports In-Reply-To: References: Message-ID: On 12 September 2017 at 10:49, Yoann Rodiere wrote: > Well, if you don't mind me sending PRs with those imports in a different > order next time I change the file (because I don't spend time on organizing > imports manually, I just use CTRL+SHIFT+O), then yes, we can leave that > undefined. That works for me too. Just please avoid compulsive CTRL+SHIFT+O'ing around when there's no significant change ;) > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 12 September 2017 at 11:45, Sanne Grinovero wrote: >> >> On 12 September 2017 at 10:42, Yoann Rodiere wrote: >> >> Fundamentally no IDE will ever produce exactly the same code so you >> >> need to learn control your primal lust for perfection and remember >> >> it's not relevant. Have some decency ;) >> > >> > >> > Sorry if that seemed "indecent", but I did mention that I could live >> > with >> > the inconsistencies, and that what matters is their effect on our git >> > workflow :) >> > >> >> If you want to volunteer making the styles a bit more similar, I >> >> typically prefer static imports last. >> > >> > >> > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try >> > to >> > align the rest of the rules, though. >> > >> >> Sergey sent a related PR but I'm not sure what to think of it as it >> >> changes several things: >> >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 >> > >> > >> > Yes, it does more than what it advertises, and even the original idea >> > (putting static imports to the top) is not a good idea: ORM already has >> > static imports at the bottom in almost every file, so this change would >> > lead >> > to many more changes than necessary in commits for the ORM project for >> > some >> > time. >> > >> >> I would say that it would be nice to have Eclipse and Idea rules as >> >> similar as possible. The issue with that is that, for a while, the ORM >> >> people will have a lot of import changes, considering we can't make the >> >> Eclipse rules Idea like but we can do the opposite. >> > >> > >> > I doubt they'll ever agree with this solution. And I can't blame them. >> > >> >> If we don't want to bother the ORM team with that, we should split our >> >> rules between ORM and NoORM but it won't be very underestandable for >> >> the >> >> contributors (but it's not as if we had a lot of them and very few of >> >> them >> >> find our code styles without us mentioning them). >> > >> > >> > Seems to be the least disruptive solution. It's not ideal, but it should >> > improve the situation slightly and it wouldn't lead to more changes than >> > necessary in the future git commits. >> > @Sanne this means the imports will stay at the top, though. Ok with >> > that? >> >> Yes I'm "ok" with that. But wouldn't it be even better to leave this >> level of detail undefined? >> >> At least it would allow me to make new code having them on the bottom >> as I like them more, and you'd save some itme :) >> >> > >> > I'll try to see if I can add non-disruptive checkstyle rules too, if I >> > have >> > some time. >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > On 12 September 2017 at 11:31, Guillaume Smet >> > wrote: >> >> >> >> Hi, >> >> >> >> Yes, I had a hard time reverting the import changes in my recent >> >> patches >> >> for ORM. I was changing only a few lines per file and had a lot of >> >> import >> >> noise. >> >> >> >> I would say that it would be nice to have Eclipse and Idea rules as >> >> similar as possible. The issue with that is that, for a while, the ORM >> >> people will have a lot of import changes, considering we can't make the >> >> Eclipse rules Idea like but we can do the opposite. >> >> >> >> If we don't want to bother the ORM team with that, we should split our >> >> rules between ORM and NoORM but it won't be very underestandable for >> >> the >> >> contributors (but it's not as if we had a lot of them and very few of >> >> them >> >> find our code styles without us mentioning them). >> >> >> >> -- >> >> Guillaume >> >> >> >> >> >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero >> >> wrote: >> >>> >> >>> Fundamentally no IDE will ever produce exactly the same code so you >> >>> need to learn control your primal lust for perfection and remember >> >>> it's not relevant. Have some decency ;) >> >>> >> >>> What does actually matter is that we don't keep chaging the order as >> >>> it introduces conflicts on backporting, it's very annoying and time >> >>> consuming in the long run. >> >>> >> >>> My solution is simple: I don't generally care, BUT commits containing >> >>> code reformats just for the sake of making one's favourite tool happy >> >>> need be rejected, especially to stop the bad habit from developing >> >>> further, or anyone trying to impose its own favourite tool of the day >> >>> as it was the only blessed way. >> >>> It's fine if a couple of import reorg "slip in" as part as meaningful >> >>> changes. >> >>> >> >>> The real problem is that applying a patch shouldn't conflict on import >> >>> statements; ideally there should be a conflict resolution strategy >> >>> able to understand it better (e.g. teach Java to git tools..) >> >>> >> >>> If you want to volunteer making the styles a bit more similar, I >> >>> typically prefer static imports last. >> >>> >> >>> -1 for CheckStyle rules unless you can figure out a way to exclude >> >>> existing code from failing: we're not going to reformat half the code >> >>> base to satisfy aesthetics. >> >>> >> >>> Perhaps we could have separate sets of rules, some stricter to be >> >>> applied on new modules; their impact would be limited but even having >> >>> one module with strict rules would encourage people to reconfigure >> >>> their IDE in "the right way". This would ensure all new code will be >> >>> consistent with the rules. >> >>> >> >>> Sergey sent a related PR but I'm not sure what to think of it as it >> >>> changes several things: >> >>> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 >> >>> >> >>> Thanks, >> >>> Sanne >> >>> >> >>> >> >>> >> >>> On 12 September 2017 at 08:42, Yoann Rodiere >> >>> wrote: >> >>> > Hello all, >> >>> > >> >>> > I just noticed that our IDEA codestyle configuration files have >> >>> > specific >> >>> > rules about how to organize imports, whereas the Eclipse ones don't. >> >>> > The most noticeable difference: organizing imports in Eclipse puts >> >>> > static >> >>> > imports at the top, while in IDEA they end up at the bottom. But >> >>> > there >> >>> > are >> >>> > other differences. >> >>> > The Hibernate ORM codebase doesn't seem affected by these >> >>> > inconsistencies >> >>> > (probably because most people working on it use IDEA), but in >> >>> > Hibernate >> >>> > Search we've already reached the point where half of our files >> >>> > follow >> >>> > one >> >>> > convention, and the other half follows the other. >> >>> > >> >>> > What's annoying here is not the inconsistencies themselves (I could >> >>> > live >> >>> > with that), it's more that in the long run we'll end up with tons of >> >>> > unnecessary changes in our commits, due to one person using IDEA to >> >>> > edit a >> >>> > file last edited with Eclipse, and vice-versa. >> >>> > >> >>> > To make the matter worse, Eclipse is not as flexible as IDEA, and we >> >>> > cannot >> >>> > configure Eclipse to match the IDEA style exactly. In particular, we >> >>> > cannot >> >>> > configure where the static imports must go: they will always go to >> >>> > the >> >>> > top ( >> >>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). >> >>> > >> >>> > I can see two ways out, each with its own drawbacks: >> >>> > >> >>> > - Switch to the "Eclipse" style, and create a Search-specific >> >>> > IDEA >> >>> > code >> >>> > style configuration, with static imports at the top. We won't be >> >>> > consistent >> >>> > with Hibernate ORM, though. >> >>> > - Switch to the "IDEA" style, and create a Search-specific >> >>> > Eclipse >> >>> > code >> >>> > style configuration, as close as the IDEA style as possible. As I >> >>> > said >> >>> > above, automatic import organizing in Eclipse will never follow >> >>> > this >> >>> > style >> >>> > exactly, so it's likely to make organizing imports in Eclipse >> >>> > quite >> >>> > painful. We could add checkstyle rules to make sure we strictly >> >>> > follow the >> >>> > style even in Eclipse. >> >>> > >> >>> > WDYT? >> >>> > >> >>> > >> >>> > Yoann Rodi?re >> >>> > Hibernate NoORM Team >> >>> > yoann at hibernate.org >> >>> > _______________________________________________ >> >>> > hibernate-dev mailing list >> >>> > hibernate-dev at lists.jboss.org >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> > > > From yoann at hibernate.org Tue Sep 12 07:50:13 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 12 Sep 2017 13:50:13 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: <20170911135440.GA2624@hibernate.org> References: <20170911135440.GA2624@hibernate.org> Message-ID: > > - Releases speaks less than downloads, Where do I download Hibernate X > is a question we want addressed from the top level menus > Always amazed that there's still people out there actually downloading JARs manually. But yes, we shouldn't forget about them. My problem with "downloads" is that, while it conveys the correct meaning for the minority (I hope) of users not using Maven/Gradle, it's really not appropriate as an entry point to pages giving information about series/releases. Let's put it that way: - To a user looking for info about a particular release (maven GAV, changelog, ...) , a "download" entry isn't even remotely relevant - To a user looking to download packages, a "releases" entry does seem a bit relevant But if you really want a "download" entry in the menu... would it be okay if it just redirected to the "releases" page? I'll do that for now. - if you do downloads -> releases, you need to also write some redirect > rules not to break URLs > I already did. Redirects don't seem to work locally for some reason, though. They work on staging. > - I don't like the term maintained much, I think latest like you > proposed makes it more neutral. You could even just name them Series > Steve found "latest releases" "confusing" (if I understood correctly). I changed it to "Series" as you suggested. > - The migration guide should probably be referenced from each individual > series page. > Done. > - the matrix does not scale very well to that many versions. > Could you be more specific? Is it that you're having trouble finding out which cell relates to which HSearch version, or which cell relates to which dependency, or about the size of columns not being the same, or... ? I'd rather know exactly what's wrong before trying to mess with the CSS, because solutions to each of these problems will probably require to use more horizontal space, and as you can see we don't have that much available. > - in the dedicated series page, "Reference" is confusing, I'd probably > replace it with documentation or main documentation Done. Since there seems to be a general agreement that it's not worse than it used to be, I'll send a PR soon. We can continue the discussion there. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 11 September 2017 at 15:54, Emmanuel Bernard wrote: > Hey Yoann and all, > > Thanks Yoann for stepping up. This is definitely much better. > Here are non ordered comments: > > - Releases speaks less than downloads, Where do I download Hibernate X > is a question we want addressed from the top level menus > - if you do downloads -> releases, you need to also write some redirect > rules not to break URLs > - I don't like the term maintained much, I think latest like you > proposed makes it more neutral. You could even just name them Series > - The migration guide should probably be referenced from each individual > series page. > - the matrix does not scale very well to that many versions. > - in the dedicated series page, "Reference" is confusing, I'd probably > replace it with documentation or main documentation > > Emmanuel > > On Fri 17-09-08 14:53, Yoann Rodiere wrote: > >> Hey, >> >> I pushed an update to staging. I only converted the "Search" part for now. >> What changes: >> >> - The _data folder structured changed a bit, so that we can introduces a >> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a >> summary >> of this series and a list of integration constraints (ORM > 5.2, etc.) >> - The "Downloads" page is renamed to "Releases", since, well, it's about >> more than just downloads. See >> http://staging.hibernate.org/search/releases/ >> - The "Releases" page now includes a "Compatibilty matrix" section based >> on the new data I mentioned above >> - The "Releases" page now includes links to one page for each series >> ("More on the 5.8 series") >> - There is now one page for each series (see >> http://staging.hibernate.org/search/releases/series/5.8/). This page >> includes: >> - A short (one-line) summary of this series >> - A reminder of the integration constraints for this series >> - A section about the main changes in this release. I only wrote >> something for the 5.8 series for now, and I basically >> copy/pasted sections >> from various blog posts. >> - A list of all releases in this series. >> >> What I didn't do, but could make sense: >> >> - add a sub-menu element under "Releases" for each series >> - link to the documentation for each of the latest releases from the >> "Releases" page >> - link to the latest documentation and to the migration guides from each >> series' page >> >> What do you all think? Emmanuel, would this address your concerns? Steve, >> would this be a good fit for ORM? >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 6 September 2017 at 17:16, Steve Ebersole wrote: >> >> This is something I brought up ages ago wrt ORM. I wanted something >>> (although ideally integrated with the "more version friendly" >>> hibernate.org design) similar to what I did atm on the ORM GitHub wiki. >>> For example, for 5.2 we have: >>> >>> >>> - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >>> - https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu >>> ide---5.2 >>> - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >>> >>> >>> >>> The format could be better and some of this information could be combined >>> (release notes and migration guide e.g.). But bear in mind that this was >>> just what I put together to illustrate what I was wanted to do, generally >>> speaking - so its a bit "rough" >>> >>> >>> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >>> wrote: >>> >>> Thanks for that Emmanuel. >>>> >>>> I'll fix the one-liner describing the release, I believe we had >>>> already noticed this in the past: they need to describe the whole >>>> minor not the micro update. >>>> The Search roadmap actually also needs a little re-touch, I'll propose >>>> a PR for that too. >>>> >>>> Regarding past roadmaps: I don't like to clutter the roadmap page with >>>> the previous copies, especially as they should have a different nature >>>> of not being a plan but being a record of what was actually done. >>>> Also, we did agree in past meetings to remove all the old ones. e.g. >>>> we never ported the release notes for version 3.x and 4.x as back then >>>> we decided this was no place for that. Happy to revisit this decision >>>> but let's separate them: >>>> >>>> What about a "past releases" page at the same level of roadmap, and >>>> linking to it both from the main Search menu and the roadmap? >>>> >>>> +1 for Yoann's proposal to re-introduce the compatibility matrix >>>> (there was one ~6 years ago). I also had proposed to reintroduce it >>>> more recently, and was not done on the grounds that it gets out of >>>> date quickly. >>>> Still users badly need it so unless someone has a better idea, let's >>>> agree on trying to keep it up to date manually. Let's try structure it >>>> in such a way that it won't need to be updated for every single >>>> release. >>>> >>>> Thanks, >>>> Sanne >>>> >>>> >>>> On 6 September 2017 at 08:37, Yoann Rodiere >>>> wrote: >>>> > Hey, >>>> > >>>> > About Search, true, the information is somewhat hidden in many blog >>>> posts. >>>> > I'm not sure the roadmap is the right place, though, since we probably >>>> want >>>> > the format to be different for past and future releases: information >>>> for >>>> > past releases is typically more precise and more verbose, with code >>>> > examples and so on. See for instance this blog post: >>>> http://in.relation.to/ >>>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >>>> roadmap >>>> > would be drowned in the past releases. >>>> > >>>> > I was thinking about another problem: we don't have a compatibility >>>> matrix. >>>> > We only have a few dependencies (mainly ORM and Lucene), but it's >>>> really >>>> > hard to know which versions of the dependencies to use with which >>>> version >>>> > of Search, and users frequently use the wrong versions. >>>> > With that in mind, I would rather see a "Versions" page, with a >>>> summary >>>> at >>>> > the top (including a one-liner for each minor and the compatibilty >>>> matrix), >>>> > and one section for each minor (with anchors, so that we can link to >>>> them >>>> > from other pages such as the downloads). Or maybe even one page for >>>> the >>>> > detail of each minor, if there's too much text. >>>> > I think it would make sense to have all that information gathered in a >>>> > single place, because all of that is needed for users to pick the >>>> version >>>> > they want: they need to know the benefits of upgrading (features) but >>>> also >>>> > the constraints (compatibility matrix). >>>> > Maybe I can give it a try at the end of the week? >>>> > >>>> > >>>> > Yoann Rodi?re >>>> > Hibernate NoORM Team >>>> > yoann at hibernate.org >>>> > >>>> > On 6 September 2017 at 09:21, Emmanuel Bernard < >>>> emmanuel at hibernate.org> >>>> > wrote: >>>> > >>>> >> Hey all, >>>> >> >>>> >> I was trying to answer the following question, what is roughly new >>>> between >>>> >> 5.6, 5.7 and 5.8 (minor releases)? >>>> >> >>>> >> My first reflex was to go to http://hibernate.org/search/downloads/ >>>> < >>>> >> http://hibernate.org/search/downloads/> to read about the onliner >>>> per >>>> >> release. Except it?s a onliner per micro release and ?minor >>>> adjustments? >>>> >> for 5.6.3.Final gave me literally no info whatsoever. >>>> >> >>>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ < >>>> >> http://hibernate.org/search/roadmap/> to find a historical entry >>>> about >>>> >> older versions and the main changes in bullet points. No luck. It >>>> only >>>> >> talks about the future. >>>> >> >>>> >> My third reflex was to go to http://in.relation.to/hibernate-search/ >>>> < >>>> >> http://in.relation.to/hibernate-search/> I ended up giving up midway >>>> page >>>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >>>> releases >>>> >> with what?s new since the last CR or the last micro kind of reports >>>> and >>>> >> gave up in dismay at the energy I would have to spend to extract >>>> what?s new >>>> >> for a full minor release. >>>> >> >>>> >> I did exaggerate a bit the third point but I did give up. We need >>>> >> somewhere a summary page of what?s new per minor releases. I think >>>> the >>>> >> roadmap page could be the host. >>>> >> Likewise, we might need a oneliner entry in the download section (per >>>> >> release) that points to this minor release summary. >>>> >> >>>> >> Thoughts? >>>> >> >>>> >> Speaking of roadmap: >>>> >> - HV roadmap is massively out of date >>>> >> - OGM is lying a bit on the future but at least has the past summary >>>> I >>>> was >>>> >> talking about >>>> >> - Search has a good future roadmap but no past >>>> >> >>>> >> Emmanuek >>>> >> _______________________________________________ >>>> >> hibernate-dev mailing list >>>> >> hibernate-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >>> From guillaume.smet at gmail.com Tue Sep 12 10:35:35 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 12 Sep 2017 16:35:35 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of the NoORM IRC meeting: 16:33 < jbott> Meeting ended Tue Sep 12 14:33:25 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:33 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-12-13.16.html 16:33 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-12-13.16.txt 16:33 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-12-13.16.log.html Have a nice day! -- Guillaume From gbadner at redhat.com Tue Sep 12 14:47:58 2017 From: gbadner at redhat.com (Gail Badner) Date: Tue, 12 Sep 2017 11:47:58 -0700 Subject: [hibernate-dev] How is LogicalConnectionImplementor#makeShareableCopy intended to be used? Message-ID: LogicalConnectionImplementor#makeShareableCopy [1] doesn't seem to be used by anything. The implemented method in LogicalConnectionManagedImpl returns null. [2] Should this method be deprecated? I'm asking because I created a PR [3] that allows passing JdbcObserver to ResourceRegistryStandardImpl so that any existing batch can be cleaned up before releasing JDBC resources. In my PR, the LogicalConnectionProvidedImpl#makeShareableCopy results in a LogicalConnectionProvidedImpl with a ResourceRegistryStandardImpl that has a null JdbcObserver. It didn't make sense to me that the original and shareable ResourceRegistryStandardImpl should both have the same JdbcObserver, but I'm really not sure about this. If LogicalConnectionImplementor#makeShareableCopy really is not used and should be deprecated, I won't worry about this. I'd like to get my PR merged for 5.2.11 tomorrow, so a quick response would be greatly appreciated. If I don't hear back, I'll push it to 5.2.12. Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/spi/LogicalConnectionImplementor.java#L61-L66 [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/internal/LogicalConnectionManagedImpl.java#L217-L223 [3] https://github.com/hibernate/hibernate-orm/pull/2004 From emmanuel at hibernate.org Wed Sep 13 05:41:01 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 13 Sep 2017 11:41:01 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> Message-ID: <20170913094101.GA12444@hibernate.org> On Tue 17-09-12 13:50, Yoann Rodiere wrote: >> >> - Releases speaks less than downloads, Where do I download Hibernate X >> is a question we want addressed from the top level menus >> > >Always amazed that there's still people out there actually downloading JARs >manually. But yes, we shouldn't forget about them. > >My problem with "downloads" is that, while it conveys the correct meaning >for the minority (I hope) of users not using Maven/Gradle, it's really not >appropriate as an entry point to pages giving information about >series/releases. >Let's put it that way: > > - To a user looking for info about a particular release (maven GAV, > changelog, ...) , a "download" entry isn't even remotely relevant > - To a user looking to download packages, a "releases" entry does seem a > bit relevant You are right on principle. But if you look around, pretty much all software websites have a download button leading to a page where you can find releases, changelog etc. People are trained. http://kafka.apache.org/downloads http://struts.apache.org/download.cgi#struts2513 http://vertx.io/download/ Spring is the exception but they have one big page for everything per project. Not what we want. And GitHub which has Releases https://github.com/google/guava I'm still not recovered from GitHub's move from Downloads to Releases to be honest. If everyone thinks Releases is clearer and more intuitive, I won't block. > >But if you really want a "download" entry in the menu... would it be okay >if it just redirected to the "releases" page? I'll do that for now. > >- if you do downloads -> releases, you need to also write some redirect >> rules not to break URLs >> > >I already did. Redirects don't seem to work locally for some reason, >though. They work on staging. > > >> - I don't like the term maintained much, I think latest like you >> proposed makes it more neutral. You could even just name them Series >> > >Steve found "latest releases" "confusing" (if I understood correctly). I >changed it to "Series" as you suggested. > > >> - The migration guide should probably be referenced from each individual >> series page. >> > >Done. > > >> - the matrix does not scale very well to that many versions. >> > >Could you be more specific? Is it that you're having trouble finding out >which cell relates to which HSearch version, or which cell relates to which >dependency, or about the size of columns not being the same, or... ? I'd >rather know exactly what's wrong before trying to mess with the CSS, >because solutions to each of these problems will probably require to use >more horizontal space, and as you can see we don't have that much available. It's more the number of columns, what if you add more version, should I scroll horizontally? Also releeases tend to be shown vertically with version in desc order. This model breaks a bit this habit. It does not work well on phones either. > > >> - in the dedicated series page, "Reference" is confusing, I'd probably >> replace it with documentation or main documentation > > >Done. > >Since there seems to be a general agreement that it's not worse than it >used to be, I'll send a PR soon. We can continue the discussion there. > > > >Yoann Rodi?re >Hibernate NoORM Team >yoann at hibernate.org > >On 11 September 2017 at 15:54, Emmanuel Bernard >wrote: > >> Hey Yoann and all, >> >> Thanks Yoann for stepping up. This is definitely much better. >> Here are non ordered comments: >> >> - Releases speaks less than downloads, Where do I download Hibernate X >> is a question we want addressed from the top level menus >> - if you do downloads -> releases, you need to also write some redirect >> rules not to break URLs >> - I don't like the term maintained much, I think latest like you >> proposed makes it more neutral. You could even just name them Series >> - The migration guide should probably be referenced from each individual >> series page. >> - the matrix does not scale very well to that many versions. >> - in the dedicated series page, "Reference" is confusing, I'd probably >> replace it with documentation or main documentation >> >> Emmanuel >> >> On Fri 17-09-08 14:53, Yoann Rodiere wrote: >> >>> Hey, >>> >>> I pushed an update to staging. I only converted the "Search" part for now. >>> What changes: >>> >>> - The _data folder structured changed a bit, so that we can introduces a >>> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a >>> summary >>> of this series and a list of integration constraints (ORM > 5.2, etc.) >>> - The "Downloads" page is renamed to "Releases", since, well, it's about >>> more than just downloads. See >>> http://staging.hibernate.org/search/releases/ >>> - The "Releases" page now includes a "Compatibilty matrix" section based >>> on the new data I mentioned above >>> - The "Releases" page now includes links to one page for each series >>> ("More on the 5.8 series") >>> - There is now one page for each series (see >>> http://staging.hibernate.org/search/releases/series/5.8/). This page >>> includes: >>> - A short (one-line) summary of this series >>> - A reminder of the integration constraints for this series >>> - A section about the main changes in this release. I only wrote >>> something for the 5.8 series for now, and I basically >>> copy/pasted sections >>> from various blog posts. >>> - A list of all releases in this series. >>> >>> What I didn't do, but could make sense: >>> >>> - add a sub-menu element under "Releases" for each series >>> - link to the documentation for each of the latest releases from the >>> "Releases" page >>> - link to the latest documentation and to the migration guides from each >>> series' page >>> >>> What do you all think? Emmanuel, would this address your concerns? Steve, >>> would this be a good fit for ORM? >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> On 6 September 2017 at 17:16, Steve Ebersole wrote: >>> >>> This is something I brought up ages ago wrt ORM. I wanted something >>>> (although ideally integrated with the "more version friendly" >>>> hibernate.org design) similar to what I did atm on the ORM GitHub wiki. >>>> For example, for 5.2 we have: >>>> >>>> >>>> - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >>>> - https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu >>>> ide---5.2 >>>> - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >>>> >>>> >>>> >>>> The format could be better and some of this information could be combined >>>> (release notes and migration guide e.g.). But bear in mind that this was >>>> just what I put together to illustrate what I was wanted to do, generally >>>> speaking - so its a bit "rough" >>>> >>>> >>>> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >>>> wrote: >>>> >>>> Thanks for that Emmanuel. >>>>> >>>>> I'll fix the one-liner describing the release, I believe we had >>>>> already noticed this in the past: they need to describe the whole >>>>> minor not the micro update. >>>>> The Search roadmap actually also needs a little re-touch, I'll propose >>>>> a PR for that too. >>>>> >>>>> Regarding past roadmaps: I don't like to clutter the roadmap page with >>>>> the previous copies, especially as they should have a different nature >>>>> of not being a plan but being a record of what was actually done. >>>>> Also, we did agree in past meetings to remove all the old ones. e.g. >>>>> we never ported the release notes for version 3.x and 4.x as back then >>>>> we decided this was no place for that. Happy to revisit this decision >>>>> but let's separate them: >>>>> >>>>> What about a "past releases" page at the same level of roadmap, and >>>>> linking to it both from the main Search menu and the roadmap? >>>>> >>>>> +1 for Yoann's proposal to re-introduce the compatibility matrix >>>>> (there was one ~6 years ago). I also had proposed to reintroduce it >>>>> more recently, and was not done on the grounds that it gets out of >>>>> date quickly. >>>>> Still users badly need it so unless someone has a better idea, let's >>>>> agree on trying to keep it up to date manually. Let's try structure it >>>>> in such a way that it won't need to be updated for every single >>>>> release. >>>>> >>>>> Thanks, >>>>> Sanne >>>>> >>>>> >>>>> On 6 September 2017 at 08:37, Yoann Rodiere >>>>> wrote: >>>>> > Hey, >>>>> > >>>>> > About Search, true, the information is somewhat hidden in many blog >>>>> posts. >>>>> > I'm not sure the roadmap is the right place, though, since we probably >>>>> want >>>>> > the format to be different for past and future releases: information >>>>> for >>>>> > past releases is typically more precise and more verbose, with code >>>>> > examples and so on. See for instance this blog post: >>>>> http://in.relation.to/ >>>>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >>>>> roadmap >>>>> > would be drowned in the past releases. >>>>> > >>>>> > I was thinking about another problem: we don't have a compatibility >>>>> matrix. >>>>> > We only have a few dependencies (mainly ORM and Lucene), but it's >>>>> really >>>>> > hard to know which versions of the dependencies to use with which >>>>> version >>>>> > of Search, and users frequently use the wrong versions. >>>>> > With that in mind, I would rather see a "Versions" page, with a >>>>> summary >>>>> at >>>>> > the top (including a one-liner for each minor and the compatibilty >>>>> matrix), >>>>> > and one section for each minor (with anchors, so that we can link to >>>>> them >>>>> > from other pages such as the downloads). Or maybe even one page for >>>>> the >>>>> > detail of each minor, if there's too much text. >>>>> > I think it would make sense to have all that information gathered in a >>>>> > single place, because all of that is needed for users to pick the >>>>> version >>>>> > they want: they need to know the benefits of upgrading (features) but >>>>> also >>>>> > the constraints (compatibility matrix). >>>>> > Maybe I can give it a try at the end of the week? >>>>> > >>>>> > >>>>> > Yoann Rodi?re >>>>> > Hibernate NoORM Team >>>>> > yoann at hibernate.org >>>>> > >>>>> > On 6 September 2017 at 09:21, Emmanuel Bernard < >>>>> emmanuel at hibernate.org> >>>>> > wrote: >>>>> > >>>>> >> Hey all, >>>>> >> >>>>> >> I was trying to answer the following question, what is roughly new >>>>> between >>>>> >> 5.6, 5.7 and 5.8 (minor releases)? >>>>> >> >>>>> >> My first reflex was to go to http://hibernate.org/search/downloads/ >>>>> < >>>>> >> http://hibernate.org/search/downloads/> to read about the onliner >>>>> per >>>>> >> release. Except it?s a onliner per micro release and ?minor >>>>> adjustments? >>>>> >> for 5.6.3.Final gave me literally no info whatsoever. >>>>> >> >>>>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ < >>>>> >> http://hibernate.org/search/roadmap/> to find a historical entry >>>>> about >>>>> >> older versions and the main changes in bullet points. No luck. It >>>>> only >>>>> >> talks about the future. >>>>> >> >>>>> >> My third reflex was to go to http://in.relation.to/hibernate-search/ >>>>> < >>>>> >> http://in.relation.to/hibernate-search/> I ended up giving up midway >>>>> page >>>>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >>>>> releases >>>>> >> with what?s new since the last CR or the last micro kind of reports >>>>> and >>>>> >> gave up in dismay at the energy I would have to spend to extract >>>>> what?s new >>>>> >> for a full minor release. >>>>> >> >>>>> >> I did exaggerate a bit the third point but I did give up. We need >>>>> >> somewhere a summary page of what?s new per minor releases. I think >>>>> the >>>>> >> roadmap page could be the host. >>>>> >> Likewise, we might need a oneliner entry in the download section (per >>>>> >> release) that points to this minor release summary. >>>>> >> >>>>> >> Thoughts? >>>>> >> >>>>> >> Speaking of roadmap: >>>>> >> - HV roadmap is massively out of date >>>>> >> - OGM is lying a bit on the future but at least has the past summary >>>>> I >>>>> was >>>>> >> talking about >>>>> >> - Search has a good future roadmap but no past >>>>> >> >>>>> >> Emmanuek >>>>> >> _______________________________________________ >>>>> >> hibernate-dev mailing list >>>>> >> hibernate-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > _______________________________________________ >>>>> > hibernate-dev mailing list >>>>> > hibernate-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >>>> From sanne at hibernate.org Wed Sep 13 05:48:42 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Sep 2017 10:48:42 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: <20170913094101.GA12444@hibernate.org> References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> Message-ID: On 13 September 2017 at 10:41, Emmanuel Bernard wrote: > On Tue 17-09-12 13:50, Yoann Rodiere wrote: >>> >>> >>> - Releases speaks less than downloads, Where do I download Hibernate X >>> is a question we want addressed from the top level menus >>> >> >> Always amazed that there's still people out there actually downloading >> JARs >> manually. But yes, we shouldn't forget about them. >> >> My problem with "downloads" is that, while it conveys the correct meaning >> for the minority (I hope) of users not using Maven/Gradle, it's really not >> appropriate as an entry point to pages giving information about >> series/releases. >> Let's put it that way: >> >> - To a user looking for info about a particular release (maven GAV, >> changelog, ...) , a "download" entry isn't even remotely relevant >> - To a user looking to download packages, a "releases" entry does seem a >> bit relevant > > > You are right on principle. But if you look around, pretty much all > software websites have a download button leading to a page where you can > find releases, changelog etc. People are trained. > > http://kafka.apache.org/downloads > http://struts.apache.org/download.cgi#struts2513 > http://vertx.io/download/ > > > Spring is the exception but they have one big page for everything per > project. Not what we want. > And GitHub which has Releases https://github.com/google/guava > > I'm still not recovered from GitHub's move from Downloads to Releases to > be honest. > > If everyone thinks Releases is clearer and more intuitive, I won't > block. - having a "Downloads" link is essential - having a "Releases" page is what we think is more useful, for many good reasons Yet we agree they are slightly different in nature. Could we ride the differences and generate them both? Especially "Releases" could be a good home for all older releases and the "Past Roadmaps" which Emmanuel suggested before we should have, yet I said they don't belong on "Roadmap". On "Downloads" we only want to promote the active branches; have some basic series descriptions but way more ecclectic than the releases descriptions. We make them cross-linked and everyone is happy? Thanks, Sanne > >> >> But if you really want a "download" entry in the menu... would it be okay >> if it just redirected to the "releases" page? I'll do that for now. >> >> - if you do downloads -> releases, you need to also write some redirect >>> >>> rules not to break URLs >>> >> >> I already did. Redirects don't seem to work locally for some reason, >> though. They work on staging. >> >> >>> - I don't like the term maintained much, I think latest like you >>> proposed makes it more neutral. You could even just name them Series >>> >> >> Steve found "latest releases" "confusing" (if I understood correctly). I >> changed it to "Series" as you suggested. >> >> >>> - The migration guide should probably be referenced from each individual >>> series page. >>> >> >> Done. >> >> >>> - the matrix does not scale very well to that many versions. >>> >> >> Could you be more specific? Is it that you're having trouble finding out >> which cell relates to which HSearch version, or which cell relates to >> which >> dependency, or about the size of columns not being the same, or... ? I'd >> rather know exactly what's wrong before trying to mess with the CSS, >> because solutions to each of these problems will probably require to use >> more horizontal space, and as you can see we don't have that much >> available. > > > It's more the number of columns, what if you add more version, should I > scroll horizontally? Also releeases tend to be shown vertically with > version in desc order. This model breaks a bit this habit. > > It does not work well on phones either. > > > >> >> >>> - in the dedicated series page, "Reference" is confusing, I'd probably >>> replace it with documentation or main documentation >> >> >> >> Done. >> >> Since there seems to be a general agreement that it's not worse than it >> used to be, I'll send a PR soon. We can continue the discussion there. >> >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 11 September 2017 at 15:54, Emmanuel Bernard >> wrote: >> >>> Hey Yoann and all, >>> >>> Thanks Yoann for stepping up. This is definitely much better. >>> Here are non ordered comments: >>> >>> - Releases speaks less than downloads, Where do I download Hibernate X >>> is a question we want addressed from the top level menus >>> - if you do downloads -> releases, you need to also write some redirect >>> rules not to break URLs >>> - I don't like the term maintained much, I think latest like you >>> proposed makes it more neutral. You could even just name them Series >>> - The migration guide should probably be referenced from each individual >>> series page. >>> - the matrix does not scale very well to that many versions. >>> - in the dedicated series page, "Reference" is confusing, I'd probably >>> replace it with documentation or main documentation >>> >>> Emmanuel >>> >>> On Fri 17-09-08 14:53, Yoann Rodiere wrote: >>> >>>> Hey, >>>> >>>> I pushed an update to staging. I only converted the "Search" part for >>>> now. >>>> What changes: >>>> >>>> - The _data folder structured changed a bit, so that we can introduces >>>> a >>>> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a >>>> summary >>>> of this series and a list of integration constraints (ORM > 5.2, etc.) >>>> - The "Downloads" page is renamed to "Releases", since, well, it's >>>> about >>>> more than just downloads. See >>>> http://staging.hibernate.org/search/releases/ >>>> - The "Releases" page now includes a "Compatibilty matrix" section >>>> based >>>> on the new data I mentioned above >>>> - The "Releases" page now includes links to one page for each series >>>> ("More on the 5.8 series") >>>> - There is now one page for each series (see >>>> http://staging.hibernate.org/search/releases/series/5.8/). This page >>>> includes: >>>> - A short (one-line) summary of this series >>>> - A reminder of the integration constraints for this series >>>> - A section about the main changes in this release. I only wrote >>>> something for the 5.8 series for now, and I basically >>>> copy/pasted sections >>>> from various blog posts. >>>> - A list of all releases in this series. >>>> >>>> What I didn't do, but could make sense: >>>> >>>> - add a sub-menu element under "Releases" for each series >>>> - link to the documentation for each of the latest releases from the >>>> "Releases" page >>>> - link to the latest documentation and to the migration guides from >>>> each >>>> series' page >>>> >>>> What do you all think? Emmanuel, would this address your concerns? >>>> Steve, >>>> would this be a good fit for ORM? >>>> >>>> Yoann Rodi?re >>>> Hibernate NoORM Team >>>> yoann at hibernate.org >>>> >>>> On 6 September 2017 at 17:16, Steve Ebersole >>>> wrote: >>>> >>>> This is something I brought up ages ago wrt ORM. I wanted something >>>>> >>>>> (although ideally integrated with the "more version friendly" >>>>> hibernate.org design) similar to what I did atm on the ORM GitHub wiki. >>>>> For example, for 5.2 we have: >>>>> >>>>> >>>>> - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >>>>> - https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu >>>>> ide---5.2 >>>>> - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >>>>> >>>>> >>>>> >>>>> The format could be better and some of this information could be >>>>> combined >>>>> (release notes and migration guide e.g.). But bear in mind that this >>>>> was >>>>> just what I put together to illustrate what I was wanted to do, >>>>> generally >>>>> speaking - so its a bit "rough" >>>>> >>>>> >>>>> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >>>>> wrote: >>>>> >>>>> Thanks for that Emmanuel. >>>>>> >>>>>> >>>>>> I'll fix the one-liner describing the release, I believe we had >>>>>> already noticed this in the past: they need to describe the whole >>>>>> minor not the micro update. >>>>>> The Search roadmap actually also needs a little re-touch, I'll propose >>>>>> a PR for that too. >>>>>> >>>>>> Regarding past roadmaps: I don't like to clutter the roadmap page with >>>>>> the previous copies, especially as they should have a different nature >>>>>> of not being a plan but being a record of what was actually done. >>>>>> Also, we did agree in past meetings to remove all the old ones. e.g. >>>>>> we never ported the release notes for version 3.x and 4.x as back then >>>>>> we decided this was no place for that. Happy to revisit this decision >>>>>> but let's separate them: >>>>>> >>>>>> What about a "past releases" page at the same level of roadmap, and >>>>>> linking to it both from the main Search menu and the roadmap? >>>>>> >>>>>> +1 for Yoann's proposal to re-introduce the compatibility matrix >>>>>> (there was one ~6 years ago). I also had proposed to reintroduce it >>>>>> more recently, and was not done on the grounds that it gets out of >>>>>> date quickly. >>>>>> Still users badly need it so unless someone has a better idea, let's >>>>>> agree on trying to keep it up to date manually. Let's try structure it >>>>>> in such a way that it won't need to be updated for every single >>>>>> release. >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> >>>>>> >>>>>> On 6 September 2017 at 08:37, Yoann Rodiere >>>>>> wrote: >>>>>> > Hey, >>>>>> > >>>>>> > About Search, true, the information is somewhat hidden in many blog >>>>>> posts. >>>>>> > I'm not sure the roadmap is the right place, though, since we >>>>>> > probably >>>>>> want >>>>>> > the format to be different for past and future releases: information >>>>>> for >>>>>> > past releases is typically more precise and more verbose, with code >>>>>> > examples and so on. See for instance this blog post: >>>>>> http://in.relation.to/ >>>>>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >>>>>> roadmap >>>>>> > would be drowned in the past releases. >>>>>> > >>>>>> > I was thinking about another problem: we don't have a compatibility >>>>>> matrix. >>>>>> > We only have a few dependencies (mainly ORM and Lucene), but it's >>>>>> really >>>>>> > hard to know which versions of the dependencies to use with which >>>>>> version >>>>>> > of Search, and users frequently use the wrong versions. >>>>>> > With that in mind, I would rather see a "Versions" page, with a >>>>>> summary >>>>>> at >>>>>> > the top (including a one-liner for each minor and the compatibilty >>>>>> matrix), >>>>>> > and one section for each minor (with anchors, so that we can link to >>>>>> them >>>>>> > from other pages such as the downloads). Or maybe even one page for >>>>>> the >>>>>> > detail of each minor, if there's too much text. >>>>>> > I think it would make sense to have all that information gathered in >>>>>> > a >>>>>> > single place, because all of that is needed for users to pick the >>>>>> version >>>>>> > they want: they need to know the benefits of upgrading (features) >>>>>> > but >>>>>> also >>>>>> > the constraints (compatibility matrix). >>>>>> > Maybe I can give it a try at the end of the week? >>>>>> > >>>>>> > >>>>>> > Yoann Rodi?re >>>>>> > Hibernate NoORM Team >>>>>> > yoann at hibernate.org >>>>>> > >>>>>> > On 6 September 2017 at 09:21, Emmanuel Bernard < >>>>>> emmanuel at hibernate.org> >>>>>> > wrote: >>>>>> > >>>>>> >> Hey all, >>>>>> >> >>>>>> >> I was trying to answer the following question, what is roughly new >>>>>> between >>>>>> >> 5.6, 5.7 and 5.8 (minor releases)? >>>>>> >> >>>>>> >> My first reflex was to go to http://hibernate.org/search/downloads/ >>>>>> < >>>>>> >> http://hibernate.org/search/downloads/> to read about the onliner >>>>>> per >>>>>> >> release. Except it?s a onliner per micro release and ?minor >>>>>> adjustments? >>>>>> >> for 5.6.3.Final gave me literally no info whatsoever. >>>>>> >> >>>>>> >> My second reflex was to go to http://hibernate.org/search/roadmap/ >>>>>> >> < >>>>>> >> http://hibernate.org/search/roadmap/> to find a historical entry >>>>>> about >>>>>> >> older versions and the main changes in bullet points. No luck. It >>>>>> only >>>>>> >> talks about the future. >>>>>> >> >>>>>> >> My third reflex was to go to >>>>>> >> http://in.relation.to/hibernate-search/ >>>>>> < >>>>>> >> http://in.relation.to/hibernate-search/> I ended up giving up >>>>>> >> midway >>>>>> page >>>>>> >> 2 of the list of blog entries. It?s a mix of simultaneous parallel >>>>>> releases >>>>>> >> with what?s new since the last CR or the last micro kind of reports >>>>>> and >>>>>> >> gave up in dismay at the energy I would have to spend to extract >>>>>> what?s new >>>>>> >> for a full minor release. >>>>>> >> >>>>>> >> I did exaggerate a bit the third point but I did give up. We need >>>>>> >> somewhere a summary page of what?s new per minor releases. I think >>>>>> the >>>>>> >> roadmap page could be the host. >>>>>> >> Likewise, we might need a oneliner entry in the download section >>>>>> >> (per >>>>>> >> release) that points to this minor release summary. >>>>>> >> >>>>>> >> Thoughts? >>>>>> >> >>>>>> >> Speaking of roadmap: >>>>>> >> - HV roadmap is massively out of date >>>>>> >> - OGM is lying a bit on the future but at least has the past >>>>>> >> summary >>>>>> I >>>>>> was >>>>>> >> talking about >>>>>> >> - Search has a good future roadmap but no past >>>>>> >> >>>>>> >> Emmanuek >>>>>> >> _______________________________________________ >>>>>> >> hibernate-dev mailing list >>>>>> >> hibernate-dev at lists.jboss.org >>>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> > _______________________________________________ >>>>>> > hibernate-dev mailing list >>>>>> > hibernate-dev at lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>>> > From yoann at hibernate.org Wed Sep 13 05:51:25 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 13 Sep 2017 11:51:25 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> Message-ID: > > It's more the number of columns, what if you add more version, should I > scroll horizontally? Also releeases tend to be shown vertically with > version in desc order. This model breaks a bit this habit. At least versions are in desc order :D More seriously, I was more worried about the number of dependencies than about the number of series. We don't want to maintain a hundred branches, so we'll probably try to keep the number of series to a minimum, but we do want to offer as much as possible to users, so we may offer many different integrations, and thus many different dependencies. Just think if the ORM team wants to display supported versions of each DBMS... So I thought showing versions horizontally would be more future-proof. I'll try to add horizontal scrolling to the table. The oldest releases may not be displayed, but then those are not the one we want to advertise, so... And in any case, we have limited horizontal space, so we have to hide *something*. About phones, I think bootstrap has something, I'll give it a try. On "Downloads" we only want to promote the active branches; have some > basic series descriptions but way more ecclectic than the releases > descriptions. We make them cross-linked and everyone is happy? Sure, we can do that. But the "downloads" page will essentially be a stripped-down version of the "releases" page. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 13 September 2017 at 11:48, Sanne Grinovero wrote: > On 13 September 2017 at 10:41, Emmanuel Bernard > wrote: > > On Tue 17-09-12 13:50, Yoann Rodiere wrote: > >>> > >>> > >>> - Releases speaks less than downloads, Where do I download Hibernate X > >>> is a question we want addressed from the top level menus > >>> > >> > >> Always amazed that there's still people out there actually downloading > >> JARs > >> manually. But yes, we shouldn't forget about them. > >> > >> My problem with "downloads" is that, while it conveys the correct > meaning > >> for the minority (I hope) of users not using Maven/Gradle, it's really > not > >> appropriate as an entry point to pages giving information about > >> series/releases. > >> Let's put it that way: > >> > >> - To a user looking for info about a particular release (maven GAV, > >> changelog, ...) , a "download" entry isn't even remotely relevant > >> - To a user looking to download packages, a "releases" entry does > seem a > >> bit relevant > > > > > > You are right on principle. But if you look around, pretty much all > > software websites have a download button leading to a page where you can > > find releases, changelog etc. People are trained. > > > > http://kafka.apache.org/downloads > > http://struts.apache.org/download.cgi#struts2513 > > http://vertx.io/download/ > > > > > > Spring is the exception but they have one big page for everything per > > project. Not what we want. > > And GitHub which has Releases https://github.com/google/guava > > > > I'm still not recovered from GitHub's move from Downloads to Releases to > > be honest. > > > > If everyone thinks Releases is clearer and more intuitive, I won't > > block. > > - having a "Downloads" link is essential > - having a "Releases" page is what we think is more useful, for many > good reasons > > Yet we agree they are slightly different in nature. Could we ride the > differences and generate them both? > > Especially "Releases" could be a good home for all older releases and > the "Past Roadmaps" which Emmanuel suggested before we should have, > yet I said they don't belong on "Roadmap". > On "Downloads" we only want to promote the active branches; have some > basic series descriptions but way more ecclectic than the releases > descriptions. We make them cross-linked and everyone is happy? > > Thanks, > Sanne > > > > > >> > >> But if you really want a "download" entry in the menu... would it be > okay > >> if it just redirected to the "releases" page? I'll do that for now. > >> > >> - if you do downloads -> releases, you need to also write some redirect > >>> > >>> rules not to break URLs > >>> > >> > >> I already did. Redirects don't seem to work locally for some reason, > >> though. They work on staging. > >> > >> > >>> - I don't like the term maintained much, I think latest like you > >>> proposed makes it more neutral. You could even just name them Series > >>> > >> > >> Steve found "latest releases" "confusing" (if I understood correctly). I > >> changed it to "Series" as you suggested. > >> > >> > >>> - The migration guide should probably be referenced from each > individual > >>> series page. > >>> > >> > >> Done. > >> > >> > >>> - the matrix does not scale very well to that many versions. > >>> > >> > >> Could you be more specific? Is it that you're having trouble finding out > >> which cell relates to which HSearch version, or which cell relates to > >> which > >> dependency, or about the size of columns not being the same, or... ? I'd > >> rather know exactly what's wrong before trying to mess with the CSS, > >> because solutions to each of these problems will probably require to use > >> more horizontal space, and as you can see we don't have that much > >> available. > > > > > > It's more the number of columns, what if you add more version, should I > > scroll horizontally? Also releeases tend to be shown vertically with > > version in desc order. This model breaks a bit this habit. > > > > It does not work well on phones either. > > > > > > > >> > >> > >>> - in the dedicated series page, "Reference" is confusing, I'd probably > >>> replace it with documentation or main documentation > >> > >> > >> > >> Done. > >> > >> Since there seems to be a general agreement that it's not worse than it > >> used to be, I'll send a PR soon. We can continue the discussion there. > >> > >> > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> yoann at hibernate.org > >> > >> On 11 September 2017 at 15:54, Emmanuel Bernard > > >> wrote: > >> > >>> Hey Yoann and all, > >>> > >>> Thanks Yoann for stepping up. This is definitely much better. > >>> Here are non ordered comments: > >>> > >>> - Releases speaks less than downloads, Where do I download Hibernate X > >>> is a question we want addressed from the top level menus > >>> - if you do downloads -> releases, you need to also write some redirect > >>> rules not to break URLs > >>> - I don't like the term maintained much, I think latest like you > >>> proposed makes it more neutral. You could even just name them Series > >>> - The migration guide should probably be referenced from each > individual > >>> series page. > >>> - the matrix does not scale very well to that many versions. > >>> - in the dedicated series page, "Reference" is confusing, I'd probably > >>> replace it with documentation or main documentation > >>> > >>> Emmanuel > >>> > >>> On Fri 17-09-08 14:53, Yoann Rodiere wrote: > >>> > >>>> Hey, > >>>> > >>>> I pushed an update to staging. I only converted the "Search" part for > >>>> now. > >>>> What changes: > >>>> > >>>> - The _data folder structured changed a bit, so that we can > introduces > >>>> a > >>>> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a > >>>> summary > >>>> of this series and a list of integration constraints (ORM > 5.2, > etc.) > >>>> - The "Downloads" page is renamed to "Releases", since, well, it's > >>>> about > >>>> more than just downloads. See > >>>> http://staging.hibernate.org/search/releases/ > >>>> - The "Releases" page now includes a "Compatibilty matrix" section > >>>> based > >>>> on the new data I mentioned above > >>>> - The "Releases" page now includes links to one page for each series > >>>> ("More on the 5.8 series") > >>>> - There is now one page for each series (see > >>>> http://staging.hibernate.org/search/releases/series/5.8/). This > page > >>>> includes: > >>>> - A short (one-line) summary of this series > >>>> - A reminder of the integration constraints for this series > >>>> - A section about the main changes in this release. I only wrote > >>>> something for the 5.8 series for now, and I basically > >>>> copy/pasted sections > >>>> from various blog posts. > >>>> - A list of all releases in this series. > >>>> > >>>> What I didn't do, but could make sense: > >>>> > >>>> - add a sub-menu element under "Releases" for each series > >>>> - link to the documentation for each of the latest releases from the > >>>> "Releases" page > >>>> - link to the latest documentation and to the migration guides from > >>>> each > >>>> series' page > >>>> > >>>> What do you all think? Emmanuel, would this address your concerns? > >>>> Steve, > >>>> would this be a good fit for ORM? > >>>> > >>>> Yoann Rodi?re > >>>> Hibernate NoORM Team > >>>> yoann at hibernate.org > >>>> > >>>> On 6 September 2017 at 17:16, Steve Ebersole > >>>> wrote: > >>>> > >>>> This is something I brought up ages ago wrt ORM. I wanted something > >>>>> > >>>>> (although ideally integrated with the "more version friendly" > >>>>> hibernate.org design) similar to what I did atm on the ORM GitHub > wiki. > >>>>> For example, for 5.2 we have: > >>>>> > >>>>> > >>>>> - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 > >>>>> - https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu > >>>>> ide---5.2 > >>>>> - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 > >>>>> > >>>>> > >>>>> > >>>>> The format could be better and some of this information could be > >>>>> combined > >>>>> (release notes and migration guide e.g.). But bear in mind that this > >>>>> was > >>>>> just what I put together to illustrate what I was wanted to do, > >>>>> generally > >>>>> speaking - so its a bit "rough" > >>>>> > >>>>> > >>>>> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero > >>>>> wrote: > >>>>> > >>>>> Thanks for that Emmanuel. > >>>>>> > >>>>>> > >>>>>> I'll fix the one-liner describing the release, I believe we had > >>>>>> already noticed this in the past: they need to describe the whole > >>>>>> minor not the micro update. > >>>>>> The Search roadmap actually also needs a little re-touch, I'll > propose > >>>>>> a PR for that too. > >>>>>> > >>>>>> Regarding past roadmaps: I don't like to clutter the roadmap page > with > >>>>>> the previous copies, especially as they should have a different > nature > >>>>>> of not being a plan but being a record of what was actually done. > >>>>>> Also, we did agree in past meetings to remove all the old ones. e.g. > >>>>>> we never ported the release notes for version 3.x and 4.x as back > then > >>>>>> we decided this was no place for that. Happy to revisit this > decision > >>>>>> but let's separate them: > >>>>>> > >>>>>> What about a "past releases" page at the same level of roadmap, and > >>>>>> linking to it both from the main Search menu and the roadmap? > >>>>>> > >>>>>> +1 for Yoann's proposal to re-introduce the compatibility matrix > >>>>>> (there was one ~6 years ago). I also had proposed to reintroduce it > >>>>>> more recently, and was not done on the grounds that it gets out of > >>>>>> date quickly. > >>>>>> Still users badly need it so unless someone has a better idea, let's > >>>>>> agree on trying to keep it up to date manually. Let's try structure > it > >>>>>> in such a way that it won't need to be updated for every single > >>>>>> release. > >>>>>> > >>>>>> Thanks, > >>>>>> Sanne > >>>>>> > >>>>>> > >>>>>> On 6 September 2017 at 08:37, Yoann Rodiere > >>>>>> wrote: > >>>>>> > Hey, > >>>>>> > > >>>>>> > About Search, true, the information is somewhat hidden in many > blog > >>>>>> posts. > >>>>>> > I'm not sure the roadmap is the right place, though, since we > >>>>>> > probably > >>>>>> want > >>>>>> > the format to be different for past and future releases: > information > >>>>>> for > >>>>>> > past releases is typically more precise and more verbose, with > code > >>>>>> > examples and so on. See for instance this blog post: > >>>>>> http://in.relation.to/ > >>>>>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future > >>>>>> roadmap > >>>>>> > would be drowned in the past releases. > >>>>>> > > >>>>>> > I was thinking about another problem: we don't have a > compatibility > >>>>>> matrix. > >>>>>> > We only have a few dependencies (mainly ORM and Lucene), but it's > >>>>>> really > >>>>>> > hard to know which versions of the dependencies to use with which > >>>>>> version > >>>>>> > of Search, and users frequently use the wrong versions. > >>>>>> > With that in mind, I would rather see a "Versions" page, with a > >>>>>> summary > >>>>>> at > >>>>>> > the top (including a one-liner for each minor and the compatibilty > >>>>>> matrix), > >>>>>> > and one section for each minor (with anchors, so that we can link > to > >>>>>> them > >>>>>> > from other pages such as the downloads). Or maybe even one page > for > >>>>>> the > >>>>>> > detail of each minor, if there's too much text. > >>>>>> > I think it would make sense to have all that information gathered > in > >>>>>> > a > >>>>>> > single place, because all of that is needed for users to pick the > >>>>>> version > >>>>>> > they want: they need to know the benefits of upgrading (features) > >>>>>> > but > >>>>>> also > >>>>>> > the constraints (compatibility matrix). > >>>>>> > Maybe I can give it a try at the end of the week? > >>>>>> > > >>>>>> > > >>>>>> > Yoann Rodi?re > >>>>>> > Hibernate NoORM Team > >>>>>> > yoann at hibernate.org > >>>>>> > > >>>>>> > On 6 September 2017 at 09:21, Emmanuel Bernard < > >>>>>> emmanuel at hibernate.org> > >>>>>> > wrote: > >>>>>> > > >>>>>> >> Hey all, > >>>>>> >> > >>>>>> >> I was trying to answer the following question, what is roughly > new > >>>>>> between > >>>>>> >> 5.6, 5.7 and 5.8 (minor releases)? > >>>>>> >> > >>>>>> >> My first reflex was to go to http://hibernate.org/search/ > downloads/ > >>>>>> < > >>>>>> >> http://hibernate.org/search/downloads/> to read about the > onliner > >>>>>> per > >>>>>> >> release. Except it?s a onliner per micro release and ?minor > >>>>>> adjustments? > >>>>>> >> for 5.6.3.Final gave me literally no info whatsoever. > >>>>>> >> > >>>>>> >> My second reflex was to go to http://hibernate.org/search/ > roadmap/ > >>>>>> >> < > >>>>>> >> http://hibernate.org/search/roadmap/> to find a historical entry > >>>>>> about > >>>>>> >> older versions and the main changes in bullet points. No luck. It > >>>>>> only > >>>>>> >> talks about the future. > >>>>>> >> > >>>>>> >> My third reflex was to go to > >>>>>> >> http://in.relation.to/hibernate-search/ > >>>>>> < > >>>>>> >> http://in.relation.to/hibernate-search/> I ended up giving up > >>>>>> >> midway > >>>>>> page > >>>>>> >> 2 of the list of blog entries. It?s a mix of simultaneous > parallel > >>>>>> releases > >>>>>> >> with what?s new since the last CR or the last micro kind of > reports > >>>>>> and > >>>>>> >> gave up in dismay at the energy I would have to spend to extract > >>>>>> what?s new > >>>>>> >> for a full minor release. > >>>>>> >> > >>>>>> >> I did exaggerate a bit the third point but I did give up. We need > >>>>>> >> somewhere a summary page of what?s new per minor releases. I > think > >>>>>> the > >>>>>> >> roadmap page could be the host. > >>>>>> >> Likewise, we might need a oneliner entry in the download section > >>>>>> >> (per > >>>>>> >> release) that points to this minor release summary. > >>>>>> >> > >>>>>> >> Thoughts? > >>>>>> >> > >>>>>> >> Speaking of roadmap: > >>>>>> >> - HV roadmap is massively out of date > >>>>>> >> - OGM is lying a bit on the future but at least has the past > >>>>>> >> summary > >>>>>> I > >>>>>> was > >>>>>> >> talking about > >>>>>> >> - Search has a good future roadmap but no past > >>>>>> >> > >>>>>> >> Emmanuek > >>>>>> >> _______________________________________________ > >>>>>> >> hibernate-dev mailing list > >>>>>> >> hibernate-dev at lists.jboss.org > >>>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>> > _______________________________________________ > >>>>>> > hibernate-dev mailing list > >>>>>> > hibernate-dev at lists.jboss.org > >>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>> > >>>>>> _______________________________________________ > >>>>>> hibernate-dev mailing list > >>>>>> hibernate-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>> > >>>>> > >>>>> > >>>>> > > > From sanne at hibernate.org Wed Sep 13 05:55:31 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Sep 2017 10:55:31 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> Message-ID: On 13 September 2017 at 10:51, Yoann Rodiere wrote: >> It's more the number of columns, what if you add more version, should I >> scroll horizontally? Also releeases tend to be shown vertically with >> version in desc order. This model breaks a bit this habit. > > > At least versions are in desc order :D > More seriously, I was more worried about the number of dependencies than > about the number of series. We don't want to maintain a hundred branches, so > we'll probably try to keep the number of series to a minimum, but we do want > to offer as much as possible to users, so we may offer many different > integrations, and thus many different dependencies. Just think if the ORM > team wants to display supported versions of each DBMS... So I thought > showing versions horizontally would be more future-proof. > I'll try to add horizontal scrolling to the table. The oldest releases may > not be displayed, but then those are not the one we want to advertise, so... > And in any case, we have limited horizontal space, so we have to hide > *something*. > About phones, I think bootstrap has something, I'll give it a try. > >> On "Downloads" we only want to promote the active branches; have some >> basic series descriptions but way more ecclectic than the releases >> descriptions. We make them cross-linked and everyone is happy? > > > Sure, we can do that. But the "downloads" page will essentially be a > stripped-down version of the "releases" page. +1 since maintenance is automated I see no problem with a little redundancy. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 13 September 2017 at 11:48, Sanne Grinovero wrote: >> >> On 13 September 2017 at 10:41, Emmanuel Bernard >> wrote: >> > On Tue 17-09-12 13:50, Yoann Rodiere wrote: >> >>> >> >>> >> >>> - Releases speaks less than downloads, Where do I download Hibernate X >> >>> is a question we want addressed from the top level menus >> >>> >> >> >> >> Always amazed that there's still people out there actually downloading >> >> JARs >> >> manually. But yes, we shouldn't forget about them. >> >> >> >> My problem with "downloads" is that, while it conveys the correct >> >> meaning >> >> for the minority (I hope) of users not using Maven/Gradle, it's really >> >> not >> >> appropriate as an entry point to pages giving information about >> >> series/releases. >> >> Let's put it that way: >> >> >> >> - To a user looking for info about a particular release (maven GAV, >> >> changelog, ...) , a "download" entry isn't even remotely relevant >> >> - To a user looking to download packages, a "releases" entry does >> >> seem a >> >> bit relevant >> > >> > >> > You are right on principle. But if you look around, pretty much all >> > software websites have a download button leading to a page where you can >> > find releases, changelog etc. People are trained. >> > >> > http://kafka.apache.org/downloads >> > http://struts.apache.org/download.cgi#struts2513 >> > http://vertx.io/download/ >> > >> > >> > Spring is the exception but they have one big page for everything per >> > project. Not what we want. >> > And GitHub which has Releases https://github.com/google/guava >> > >> > I'm still not recovered from GitHub's move from Downloads to Releases to >> > be honest. >> > >> > If everyone thinks Releases is clearer and more intuitive, I won't >> > block. >> >> - having a "Downloads" link is essential >> - having a "Releases" page is what we think is more useful, for many >> good reasons >> >> Yet we agree they are slightly different in nature. Could we ride the >> differences and generate them both? >> >> Especially "Releases" could be a good home for all older releases and >> the "Past Roadmaps" which Emmanuel suggested before we should have, >> yet I said they don't belong on "Roadmap". >> On "Downloads" we only want to promote the active branches; have some >> basic series descriptions but way more ecclectic than the releases >> descriptions. We make them cross-linked and everyone is happy? >> >> Thanks, >> Sanne >> >> >> > >> >> >> >> But if you really want a "download" entry in the menu... would it be >> >> okay >> >> if it just redirected to the "releases" page? I'll do that for now. >> >> >> >> - if you do downloads -> releases, you need to also write some redirect >> >>> >> >>> rules not to break URLs >> >>> >> >> >> >> I already did. Redirects don't seem to work locally for some reason, >> >> though. They work on staging. >> >> >> >> >> >>> - I don't like the term maintained much, I think latest like you >> >>> proposed makes it more neutral. You could even just name them Series >> >>> >> >> >> >> Steve found "latest releases" "confusing" (if I understood correctly). >> >> I >> >> changed it to "Series" as you suggested. >> >> >> >> >> >>> - The migration guide should probably be referenced from each >> >>> individual >> >>> series page. >> >>> >> >> >> >> Done. >> >> >> >> >> >>> - the matrix does not scale very well to that many versions. >> >>> >> >> >> >> Could you be more specific? Is it that you're having trouble finding >> >> out >> >> which cell relates to which HSearch version, or which cell relates to >> >> which >> >> dependency, or about the size of columns not being the same, or... ? >> >> I'd >> >> rather know exactly what's wrong before trying to mess with the CSS, >> >> because solutions to each of these problems will probably require to >> >> use >> >> more horizontal space, and as you can see we don't have that much >> >> available. >> > >> > >> > It's more the number of columns, what if you add more version, should I >> > scroll horizontally? Also releeases tend to be shown vertically with >> > version in desc order. This model breaks a bit this habit. >> > >> > It does not work well on phones either. >> > >> > >> > >> >> >> >> >> >>> - in the dedicated series page, "Reference" is confusing, I'd probably >> >>> replace it with documentation or main documentation >> >> >> >> >> >> >> >> Done. >> >> >> >> Since there seems to be a general agreement that it's not worse than it >> >> used to be, I'll send a PR soon. We can continue the discussion there. >> >> >> >> >> >> >> >> Yoann Rodi?re >> >> Hibernate NoORM Team >> >> yoann at hibernate.org >> >> >> >> On 11 September 2017 at 15:54, Emmanuel Bernard >> >> >> >> wrote: >> >> >> >>> Hey Yoann and all, >> >>> >> >>> Thanks Yoann for stepping up. This is definitely much better. >> >>> Here are non ordered comments: >> >>> >> >>> - Releases speaks less than downloads, Where do I download Hibernate X >> >>> is a question we want addressed from the top level menus >> >>> - if you do downloads -> releases, you need to also write some >> >>> redirect >> >>> rules not to break URLs >> >>> - I don't like the term maintained much, I think latest like you >> >>> proposed makes it more neutral. You could even just name them Series >> >>> - The migration guide should probably be referenced from each >> >>> individual >> >>> series page. >> >>> - the matrix does not scale very well to that many versions. >> >>> - in the dedicated series page, "Reference" is confusing, I'd probably >> >>> replace it with documentation or main documentation >> >>> >> >>> Emmanuel >> >>> >> >>> On Fri 17-09-08 14:53, Yoann Rodiere wrote: >> >>> >> >>>> Hey, >> >>>> >> >>>> I pushed an update to staging. I only converted the "Search" part for >> >>>> now. >> >>>> What changes: >> >>>> >> >>>> - The _data folder structured changed a bit, so that we can >> >>>> introduces >> >>>> a >> >>>> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a >> >>>> summary >> >>>> of this series and a list of integration constraints (ORM > 5.2, >> >>>> etc.) >> >>>> - The "Downloads" page is renamed to "Releases", since, well, it's >> >>>> about >> >>>> more than just downloads. See >> >>>> http://staging.hibernate.org/search/releases/ >> >>>> - The "Releases" page now includes a "Compatibilty matrix" section >> >>>> based >> >>>> on the new data I mentioned above >> >>>> - The "Releases" page now includes links to one page for each >> >>>> series >> >>>> ("More on the 5.8 series") >> >>>> - There is now one page for each series (see >> >>>> http://staging.hibernate.org/search/releases/series/5.8/). This >> >>>> page >> >>>> includes: >> >>>> - A short (one-line) summary of this series >> >>>> - A reminder of the integration constraints for this series >> >>>> - A section about the main changes in this release. I only wrote >> >>>> something for the 5.8 series for now, and I basically >> >>>> copy/pasted sections >> >>>> from various blog posts. >> >>>> - A list of all releases in this series. >> >>>> >> >>>> What I didn't do, but could make sense: >> >>>> >> >>>> - add a sub-menu element under "Releases" for each series >> >>>> - link to the documentation for each of the latest releases from >> >>>> the >> >>>> "Releases" page >> >>>> - link to the latest documentation and to the migration guides from >> >>>> each >> >>>> series' page >> >>>> >> >>>> What do you all think? Emmanuel, would this address your concerns? >> >>>> Steve, >> >>>> would this be a good fit for ORM? >> >>>> >> >>>> Yoann Rodi?re >> >>>> Hibernate NoORM Team >> >>>> yoann at hibernate.org >> >>>> >> >>>> On 6 September 2017 at 17:16, Steve Ebersole >> >>>> wrote: >> >>>> >> >>>> This is something I brought up ages ago wrt ORM. I wanted something >> >>>>> >> >>>>> (although ideally integrated with the "more version friendly" >> >>>>> hibernate.org design) similar to what I did atm on the ORM GitHub >> >>>>> wiki. >> >>>>> For example, for 5.2 we have: >> >>>>> >> >>>>> >> >>>>> - https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2 >> >>>>> - https://github.com/hibernate/hibernate-orm/wiki/Migration-Gu >> >>>>> ide---5.2 >> >>>>> - https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2 >> >>>>> >> >>>>> >> >>>>> >> >>>>> The format could be better and some of this information could be >> >>>>> combined >> >>>>> (release notes and migration guide e.g.). But bear in mind that >> >>>>> this >> >>>>> was >> >>>>> just what I put together to illustrate what I was wanted to do, >> >>>>> generally >> >>>>> speaking - so its a bit "rough" >> >>>>> >> >>>>> >> >>>>> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero >> >>>>> wrote: >> >>>>> >> >>>>> Thanks for that Emmanuel. >> >>>>>> >> >>>>>> >> >>>>>> I'll fix the one-liner describing the release, I believe we had >> >>>>>> already noticed this in the past: they need to describe the whole >> >>>>>> minor not the micro update. >> >>>>>> The Search roadmap actually also needs a little re-touch, I'll >> >>>>>> propose >> >>>>>> a PR for that too. >> >>>>>> >> >>>>>> Regarding past roadmaps: I don't like to clutter the roadmap page >> >>>>>> with >> >>>>>> the previous copies, especially as they should have a different >> >>>>>> nature >> >>>>>> of not being a plan but being a record of what was actually done. >> >>>>>> Also, we did agree in past meetings to remove all the old ones. >> >>>>>> e.g. >> >>>>>> we never ported the release notes for version 3.x and 4.x as back >> >>>>>> then >> >>>>>> we decided this was no place for that. Happy to revisit this >> >>>>>> decision >> >>>>>> but let's separate them: >> >>>>>> >> >>>>>> What about a "past releases" page at the same level of roadmap, and >> >>>>>> linking to it both from the main Search menu and the roadmap? >> >>>>>> >> >>>>>> +1 for Yoann's proposal to re-introduce the compatibility matrix >> >>>>>> (there was one ~6 years ago). I also had proposed to reintroduce it >> >>>>>> more recently, and was not done on the grounds that it gets out of >> >>>>>> date quickly. >> >>>>>> Still users badly need it so unless someone has a better idea, >> >>>>>> let's >> >>>>>> agree on trying to keep it up to date manually. Let's try structure >> >>>>>> it >> >>>>>> in such a way that it won't need to be updated for every single >> >>>>>> release. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Sanne >> >>>>>> >> >>>>>> >> >>>>>> On 6 September 2017 at 08:37, Yoann Rodiere >> >>>>>> wrote: >> >>>>>> > Hey, >> >>>>>> > >> >>>>>> > About Search, true, the information is somewhat hidden in many >> >>>>>> > blog >> >>>>>> posts. >> >>>>>> > I'm not sure the roadmap is the right place, though, since we >> >>>>>> > probably >> >>>>>> want >> >>>>>> > the format to be different for past and future releases: >> >>>>>> > information >> >>>>>> for >> >>>>>> > past releases is typically more precise and more verbose, with >> >>>>>> > code >> >>>>>> > examples and so on. See for instance this blog post: >> >>>>>> http://in.relation.to/ >> >>>>>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future >> >>>>>> roadmap >> >>>>>> > would be drowned in the past releases. >> >>>>>> > >> >>>>>> > I was thinking about another problem: we don't have a >> >>>>>> > compatibility >> >>>>>> matrix. >> >>>>>> > We only have a few dependencies (mainly ORM and Lucene), but it's >> >>>>>> really >> >>>>>> > hard to know which versions of the dependencies to use with which >> >>>>>> version >> >>>>>> > of Search, and users frequently use the wrong versions. >> >>>>>> > With that in mind, I would rather see a "Versions" page, with a >> >>>>>> summary >> >>>>>> at >> >>>>>> > the top (including a one-liner for each minor and the >> >>>>>> > compatibilty >> >>>>>> matrix), >> >>>>>> > and one section for each minor (with anchors, so that we can link >> >>>>>> > to >> >>>>>> them >> >>>>>> > from other pages such as the downloads). Or maybe even one page >> >>>>>> > for >> >>>>>> the >> >>>>>> > detail of each minor, if there's too much text. >> >>>>>> > I think it would make sense to have all that information gathered >> >>>>>> > in >> >>>>>> > a >> >>>>>> > single place, because all of that is needed for users to pick the >> >>>>>> version >> >>>>>> > they want: they need to know the benefits of upgrading (features) >> >>>>>> > but >> >>>>>> also >> >>>>>> > the constraints (compatibility matrix). >> >>>>>> > Maybe I can give it a try at the end of the week? >> >>>>>> > >> >>>>>> > >> >>>>>> > Yoann Rodi?re >> >>>>>> > Hibernate NoORM Team >> >>>>>> > yoann at hibernate.org >> >>>>>> > >> >>>>>> > On 6 September 2017 at 09:21, Emmanuel Bernard < >> >>>>>> emmanuel at hibernate.org> >> >>>>>> > wrote: >> >>>>>> > >> >>>>>> >> Hey all, >> >>>>>> >> >> >>>>>> >> I was trying to answer the following question, what is roughly >> >>>>>> >> new >> >>>>>> between >> >>>>>> >> 5.6, 5.7 and 5.8 (minor releases)? >> >>>>>> >> >> >>>>>> >> My first reflex was to go to >> >>>>>> >> http://hibernate.org/search/downloads/ >> >>>>>> < >> >>>>>> >> http://hibernate.org/search/downloads/> to read about the >> >>>>>> >> onliner >> >>>>>> per >> >>>>>> >> release. Except it?s a onliner per micro release and ?minor >> >>>>>> adjustments? >> >>>>>> >> for 5.6.3.Final gave me literally no info whatsoever. >> >>>>>> >> >> >>>>>> >> My second reflex was to go to >> >>>>>> >> http://hibernate.org/search/roadmap/ >> >>>>>> >> < >> >>>>>> >> http://hibernate.org/search/roadmap/> to find a historical entry >> >>>>>> about >> >>>>>> >> older versions and the main changes in bullet points. No luck. >> >>>>>> >> It >> >>>>>> only >> >>>>>> >> talks about the future. >> >>>>>> >> >> >>>>>> >> My third reflex was to go to >> >>>>>> >> http://in.relation.to/hibernate-search/ >> >>>>>> < >> >>>>>> >> http://in.relation.to/hibernate-search/> I ended up giving up >> >>>>>> >> midway >> >>>>>> page >> >>>>>> >> 2 of the list of blog entries. It?s a mix of simultaneous >> >>>>>> >> parallel >> >>>>>> releases >> >>>>>> >> with what?s new since the last CR or the last micro kind of >> >>>>>> >> reports >> >>>>>> and >> >>>>>> >> gave up in dismay at the energy I would have to spend to extract >> >>>>>> what?s new >> >>>>>> >> for a full minor release. >> >>>>>> >> >> >>>>>> >> I did exaggerate a bit the third point but I did give up. We >> >>>>>> >> need >> >>>>>> >> somewhere a summary page of what?s new per minor releases. I >> >>>>>> >> think >> >>>>>> the >> >>>>>> >> roadmap page could be the host. >> >>>>>> >> Likewise, we might need a oneliner entry in the download section >> >>>>>> >> (per >> >>>>>> >> release) that points to this minor release summary. >> >>>>>> >> >> >>>>>> >> Thoughts? >> >>>>>> >> >> >>>>>> >> Speaking of roadmap: >> >>>>>> >> - HV roadmap is massively out of date >> >>>>>> >> - OGM is lying a bit on the future but at least has the past >> >>>>>> >> summary >> >>>>>> I >> >>>>>> was >> >>>>>> >> talking about >> >>>>>> >> - Search has a good future roadmap but no past >> >>>>>> >> >> >>>>>> >> Emmanuek >> >>>>>> >> _______________________________________________ >> >>>>>> >> hibernate-dev mailing list >> >>>>>> >> hibernate-dev at lists.jboss.org >> >>>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>>> > _______________________________________________ >> >>>>>> > hibernate-dev mailing list >> >>>>>> > hibernate-dev at lists.jboss.org >> >>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> hibernate-dev mailing list >> >>>>>> hibernate-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> > > > From gbadner at redhat.com Wed Sep 13 13:52:02 2017 From: gbadner at redhat.com (Gail Badner) Date: Wed, 13 Sep 2017 10:52:02 -0700 Subject: [hibernate-dev] Preparing to release 5.2.11 Message-ID: I'm getting ready to release 5.2.11. Please do not push any commits to master branch until I announce the release. Thanks, Gail From gbadner at redhat.com Wed Sep 13 16:53:02 2017 From: gbadner at redhat.com (Gail Badner) Date: Wed, 13 Sep 2017 13:53:02 -0700 Subject: [hibernate-dev] Hibernate ORM 5.2.11.Final Released Message-ID: http://in.relation.to/2017/09/13/hibernate-orm-5211-final-release/ From sanne at hibernate.org Wed Sep 13 17:39:06 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Sep 2017 22:39:06 +0100 Subject: [hibernate-dev] Good behaviour & pull requests Message-ID: Hi all, I recently sent a pull request containing, among others, a very specific paragraph of documentation. This was merged with no other comment than a thank you, and I appreciate both the speed and thanks. BUT checking now after the release is done, as I am in need to refer to this section, I see my paragraph was altered, and it's wrong, or confusing at best. That's not fair. It's nice and pragmatic that we all occasionally take initiative and decide on some flexibility on the PR process, but please please please let the PR author know when you decide to make some changes so they get the opportunity to disagree. Thanks, Sanne From emmanuel at hibernate.org Thu Sep 14 04:38:39 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 14 Sep 2017 10:38:39 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> Message-ID: <20170914083839.GB12444@hibernate.org> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >On 13 September 2017 at 10:51, Yoann Rodiere wrote: >>> It's more the number of columns, what if you add more version, should I >>> scroll horizontally? Also releeases tend to be shown vertically with >>> version in desc order. This model breaks a bit this habit. >> >> >> At least versions are in desc order :D >> More seriously, I was more worried about the number of dependencies than >> about the number of series. We don't want to maintain a hundred branches, so >> we'll probably try to keep the number of series to a minimum, but we do want >> to offer as much as possible to users, so we may offer many different >> integrations, and thus many different dependencies. Just think if the ORM >> team wants to display supported versions of each DBMS... So I thought >> showing versions horizontally would be more future-proof. >> I'll try to add horizontal scrolling to the table. The oldest releases may >> not be displayed, but then those are not the one we want to advertise, so... >> And in any case, we have limited horizontal space, so we have to hide >> *something*. >> About phones, I think bootstrap has something, I'll give it a try. >> >>> On "Downloads" we only want to promote the active branches; have some >>> basic series descriptions but way more ecclectic than the releases >>> descriptions. We make them cross-linked and everyone is happy? >> >> >> Sure, we can do that. But the "downloads" page will essentially be a >> stripped-down version of the "releases" page. > >+1 since maintenance is automated I see no problem with a little redundancy. I'm not sure two pages is really solving the problem. It looks like you don't want to make a choice. But I don't have a pro/con opinion. My real concern is since you will have two pages, what's the navigation logic? How do you reach each on of these pages? Just thinking out loud here but I think the one way to solve long standing Steve objective is indeed to have per series sections of the website (including download, documentation, migration guide) And a top nav for "latest/promoted" releases (like we have today really). How do you merge the two navigation wise is what I don't know. This is for later work anyways. From yoann at hibernate.org Thu Sep 14 08:04:40 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 14 Sep 2017 14:04:40 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: <20170914083839.GB12444@hibernate.org> References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: I polished the changes, applied them to all projects (ORM, OGM, Validator, Search), and sent a PR: https://github.com/hibernate/hibernate.org/pull/126 Could you guys review it? Mainly I'd need one person per project to check they agree with the changes, especially in their project's section. Also, there's still a bit of work to do for each project, mainly filling in missing metadata (see the PR). Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 14 September 2017 at 10:38, Emmanuel Bernard wrote: > On Wed 17-09-13 10:55, Sanne Grinovero wrote: > >> On 13 September 2017 at 10:51, Yoann Rodiere wrote: >> >>> It's more the number of columns, what if you add more version, should I >>>> scroll horizontally? Also releeases tend to be shown vertically with >>>> version in desc order. This model breaks a bit this habit. >>>> >>> >>> >>> At least versions are in desc order :D >>> More seriously, I was more worried about the number of dependencies than >>> about the number of series. We don't want to maintain a hundred >>> branches, so >>> we'll probably try to keep the number of series to a minimum, but we do >>> want >>> to offer as much as possible to users, so we may offer many different >>> integrations, and thus many different dependencies. Just think if the ORM >>> team wants to display supported versions of each DBMS... So I thought >>> showing versions horizontally would be more future-proof. >>> I'll try to add horizontal scrolling to the table. The oldest releases >>> may >>> not be displayed, but then those are not the one we want to advertise, >>> so... >>> And in any case, we have limited horizontal space, so we have to hide >>> *something*. >>> About phones, I think bootstrap has something, I'll give it a try. >>> >>> On "Downloads" we only want to promote the active branches; have some >>>> basic series descriptions but way more ecclectic than the releases >>>> descriptions. We make them cross-linked and everyone is happy? >>>> >>> >>> >>> Sure, we can do that. But the "downloads" page will essentially be a >>> stripped-down version of the "releases" page. >>> >> >> +1 since maintenance is automated I see no problem with a little >> redundancy. >> > > I'm not sure two pages is really solving the problem. It looks like you > don't want to make a choice. But I don't have a pro/con opinion. > My real concern is since you will have two pages, what's the navigation > logic? How do you reach each on of these pages? > > Just thinking out loud here but I think the one way to solve long > standing Steve objective is indeed to have per series sections of the > website (including download, documentation, migration guide) > And a top nav for "latest/promoted" releases (like we have today > really). > How do you merge the two navigation wise is what I don't know. > This is for later work anyways. > From steve at hibernate.org Thu Sep 14 08:34:11 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Sep 2017 12:34:11 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Yoann, First thanks for the work on this. I think it looks worlds better. A few minor things: 1. Not sure of the source for this, but can we fix these doc link for 5.2 from ` https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html` to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not sure it matters, just found it odd 2. Much of the information on that ORM releases page is, in turn, version/series specific. Any reason why those pieces of information are not part of the series? Either in the synopsis on the releases page or on the specific series page, or both. Specifically 1. "Compatibility Matrix" - the fact that its a table based on series is a good indicator it is all series specific ;) 2. "Maven Repository" - I'd personally prefer to have this as part of the series info 3. I think the individual series pages are missing a key piece of information... the "synopsis" of that series. I guess partially this fits under "what's new" Other than these minor things I love it. Great job! P.S. another question is whether (and if so, how) to apply the same treatment to the Documentation info in terms of the nav links. On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere wrote: > I polished the changes, applied them to all projects (ORM, OGM, Validator, > Search), and sent a PR: > https://github.com/hibernate/hibernate.org/pull/126 > Could you guys review it? Mainly I'd need one person per project to check > they agree with the changes, especially in their project's section. > Also, there's still a bit of work to do for each project, mainly filling > in missing metadata (see the PR). > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 14 September 2017 at 10:38, Emmanuel Bernard > wrote: > >> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >> >>> On 13 September 2017 at 10:51, Yoann Rodiere >>> wrote: >>> >>>> It's more the number of columns, what if you add more version, should I >>>>> scroll horizontally? Also releeases tend to be shown vertically with >>>>> version in desc order. This model breaks a bit this habit. >>>>> >>>> >>>> >>>> At least versions are in desc order :D >>>> More seriously, I was more worried about the number of dependencies than >>>> about the number of series. We don't want to maintain a hundred >>>> branches, so >>>> we'll probably try to keep the number of series to a minimum, but we do >>>> want >>>> to offer as much as possible to users, so we may offer many different >>>> integrations, and thus many different dependencies. Just think if the >>>> ORM >>>> team wants to display supported versions of each DBMS... So I thought >>>> showing versions horizontally would be more future-proof. >>>> I'll try to add horizontal scrolling to the table. The oldest releases >>>> may >>>> not be displayed, but then those are not the one we want to advertise, >>>> so... >>>> And in any case, we have limited horizontal space, so we have to hide >>>> *something*. >>>> About phones, I think bootstrap has something, I'll give it a try. >>>> >>>> On "Downloads" we only want to promote the active branches; have some >>>>> basic series descriptions but way more ecclectic than the releases >>>>> descriptions. We make them cross-linked and everyone is happy? >>>>> >>>> >>>> >>>> Sure, we can do that. But the "downloads" page will essentially be a >>>> stripped-down version of the "releases" page. >>>> >>> >>> +1 since maintenance is automated I see no problem with a little >>> redundancy. >>> >> >> I'm not sure two pages is really solving the problem. It looks like you >> don't want to make a choice. But I don't have a pro/con opinion. >> My real concern is since you will have two pages, what's the navigation >> logic? How do you reach each on of these pages? >> >> Just thinking out loud here but I think the one way to solve long >> standing Steve objective is indeed to have per series sections of the >> website (including download, documentation, migration guide) >> And a top nav for "latest/promoted" releases (like we have today >> really). >> How do you merge the two navigation wise is what I don't know. >> This is for later work anyways. >> > > From mihalcea.vlad at gmail.com Thu Sep 14 08:55:32 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 14 Sep 2017 15:55:32 +0300 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Hi, To be able to load the User Guide like this: https://docs.jboss.org/hibernate/orm/5.2 we have two options: 1. Either we rename the User Guide to index.adoc so that it will become index.html. 2. We leave it as-is, but when we copy the docs to JBoss, we also copy the User Guide as index.html as well. This will allow our users to retain bookmarks they've created since we published the new User Guide. Let me know which one do you prefer. Vlad On Thu, Sep 14, 2017 at 3:34 PM, Steve Ebersole wrote: > Yoann, > > First thanks for the work on this. I think it looks worlds better. A few > minor things: > > > 1. Not sure of the source for this, but can we fix these doc link for > 5.2 from ` > https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/ > Hibernate_User_Guide.html` > to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not > sure it matters, just found it odd > 2. Much of the information on that ORM releases page is, in turn, > version/series specific. Any reason why those pieces of information are > not part of the series? Either in the synopsis on the releases page or > on > the specific series page, or both. Specifically > 1. "Compatibility Matrix" - the fact that its a table based on series > is a good indicator it is all series specific ;) > 2. "Maven Repository" - I'd personally prefer to have this as part of > the series info > 3. I think the individual series pages are missing a key piece of > information... the "synopsis" of that series. I guess partially this > fits > under "what's new" > > Other than these minor things I love it. Great job! > > P.S. another question is whether (and if so, how) to apply the same > treatment to the Documentation info in terms of the nav links. > > On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere wrote: > > > I polished the changes, applied them to all projects (ORM, OGM, > Validator, > > Search), and sent a PR: > > https://github.com/hibernate/hibernate.org/pull/126 > > Could you guys review it? Mainly I'd need one person per project to check > > they agree with the changes, especially in their project's section. > > Also, there's still a bit of work to do for each project, mainly filling > > in missing metadata (see the PR). > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 14 September 2017 at 10:38, Emmanuel Bernard > > wrote: > > > >> On Wed 17-09-13 10:55, Sanne Grinovero wrote: > >> > >>> On 13 September 2017 at 10:51, Yoann Rodiere > >>> wrote: > >>> > >>>> It's more the number of columns, what if you add more version, should > I > >>>>> scroll horizontally? Also releeases tend to be shown vertically with > >>>>> version in desc order. This model breaks a bit this habit. > >>>>> > >>>> > >>>> > >>>> At least versions are in desc order :D > >>>> More seriously, I was more worried about the number of dependencies > than > >>>> about the number of series. We don't want to maintain a hundred > >>>> branches, so > >>>> we'll probably try to keep the number of series to a minimum, but we > do > >>>> want > >>>> to offer as much as possible to users, so we may offer many different > >>>> integrations, and thus many different dependencies. Just think if the > >>>> ORM > >>>> team wants to display supported versions of each DBMS... So I thought > >>>> showing versions horizontally would be more future-proof. > >>>> I'll try to add horizontal scrolling to the table. The oldest releases > >>>> may > >>>> not be displayed, but then those are not the one we want to advertise, > >>>> so... > >>>> And in any case, we have limited horizontal space, so we have to hide > >>>> *something*. > >>>> About phones, I think bootstrap has something, I'll give it a try. > >>>> > >>>> On "Downloads" we only want to promote the active branches; have some > >>>>> basic series descriptions but way more ecclectic than the releases > >>>>> descriptions. We make them cross-linked and everyone is happy? > >>>>> > >>>> > >>>> > >>>> Sure, we can do that. But the "downloads" page will essentially be a > >>>> stripped-down version of the "releases" page. > >>>> > >>> > >>> +1 since maintenance is automated I see no problem with a little > >>> redundancy. > >>> > >> > >> I'm not sure two pages is really solving the problem. It looks like you > >> don't want to make a choice. But I don't have a pro/con opinion. > >> My real concern is since you will have two pages, what's the navigation > >> logic? How do you reach each on of these pages? > >> > >> Just thinking out loud here but I think the one way to solve long > >> standing Steve objective is indeed to have per series sections of the > >> website (including download, documentation, migration guide) > >> And a top nav for "latest/promoted" releases (like we have today > >> really). > >> How do you merge the two navigation wise is what I don't know. > >> This is for later work anyways. > >> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Sep 14 09:27:36 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 14 Sep 2017 15:27:36 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Hi, Would anyone have something about putting the Compatibility matrix before the Series part in the page: http://staging.hibernate.org/ogm/releases/ ? Atm, we don't see the matrix at a quick glance (I totally missed it until Yoann told me it was there) and I think it's probably the first information you need when you want to download something. Typically, if you're stuck to Java 6 for whatever reasons, no need to take a look at the 5.2 serie. It's maybe a little less sexy but it would be more useful IMHO. -- Guillaume On Thu, Sep 14, 2017 at 2:55 PM, Vlad Mihalcea wrote: > Hi, > > To be able to load the User Guide like this: > > https://docs.jboss.org/hibernate/orm/5.2 > > > we have two options: > > 1. Either we rename the User Guide to index.adoc so that it will become > index.html. > 2. We leave it as-is, but when we copy the docs to JBoss, we also copy the > User Guide as index.html as well. This will allow our users to retain > bookmarks they've created since we published the new User Guide. > > Let me know which one do you prefer. > Vlad > > On Thu, Sep 14, 2017 at 3:34 PM, Steve Ebersole > wrote: > > > Yoann, > > > > First thanks for the work on this. I think it looks worlds better. A > few > > minor things: > > > > > > 1. Not sure of the source for this, but can we fix these doc link for > > 5.2 from ` > > https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/ > > Hibernate_User_Guide.html` > > to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not > > sure it matters, just found it odd > > 2. Much of the information on that ORM releases page is, in turn, > > version/series specific. Any reason why those pieces of information > are > > not part of the series? Either in the synopsis on the releases page > or > > on > > the specific series page, or both. Specifically > > 1. "Compatibility Matrix" - the fact that its a table based on > series > > is a good indicator it is all series specific ;) > > 2. "Maven Repository" - I'd personally prefer to have this as part > of > > the series info > > 3. I think the individual series pages are missing a key piece of > > information... the "synopsis" of that series. I guess partially this > > fits > > under "what's new" > > > > Other than these minor things I love it. Great job! > > > > P.S. another question is whether (and if so, how) to apply the same > > treatment to the Documentation info in terms of the nav links. > > > > On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere > wrote: > > > > > I polished the changes, applied them to all projects (ORM, OGM, > > Validator, > > > Search), and sent a PR: > > > https://github.com/hibernate/hibernate.org/pull/126 > > > Could you guys review it? Mainly I'd need one person per project to > check > > > they agree with the changes, especially in their project's section. > > > Also, there's still a bit of work to do for each project, mainly > filling > > > in missing metadata (see the PR). > > > > > > Yoann Rodi?re > > > Hibernate NoORM Team > > > yoann at hibernate.org > > > > > > On 14 September 2017 at 10:38, Emmanuel Bernard < > emmanuel at hibernate.org> > > > wrote: > > > > > >> On Wed 17-09-13 10:55, Sanne Grinovero wrote: > > >> > > >>> On 13 September 2017 at 10:51, Yoann Rodiere > > >>> wrote: > > >>> > > >>>> It's more the number of columns, what if you add more version, > should > > I > > >>>>> scroll horizontally? Also releeases tend to be shown vertically > with > > >>>>> version in desc order. This model breaks a bit this habit. > > >>>>> > > >>>> > > >>>> > > >>>> At least versions are in desc order :D > > >>>> More seriously, I was more worried about the number of dependencies > > than > > >>>> about the number of series. We don't want to maintain a hundred > > >>>> branches, so > > >>>> we'll probably try to keep the number of series to a minimum, but we > > do > > >>>> want > > >>>> to offer as much as possible to users, so we may offer many > different > > >>>> integrations, and thus many different dependencies. Just think if > the > > >>>> ORM > > >>>> team wants to display supported versions of each DBMS... So I > thought > > >>>> showing versions horizontally would be more future-proof. > > >>>> I'll try to add horizontal scrolling to the table. The oldest > releases > > >>>> may > > >>>> not be displayed, but then those are not the one we want to > advertise, > > >>>> so... > > >>>> And in any case, we have limited horizontal space, so we have to > hide > > >>>> *something*. > > >>>> About phones, I think bootstrap has something, I'll give it a try. > > >>>> > > >>>> On "Downloads" we only want to promote the active branches; have > some > > >>>>> basic series descriptions but way more ecclectic than the releases > > >>>>> descriptions. We make them cross-linked and everyone is happy? > > >>>>> > > >>>> > > >>>> > > >>>> Sure, we can do that. But the "downloads" page will essentially be a > > >>>> stripped-down version of the "releases" page. > > >>>> > > >>> > > >>> +1 since maintenance is automated I see no problem with a little > > >>> redundancy. > > >>> > > >> > > >> I'm not sure two pages is really solving the problem. It looks like > you > > >> don't want to make a choice. But I don't have a pro/con opinion. > > >> My real concern is since you will have two pages, what's the > navigation > > >> logic? How do you reach each on of these pages? > > >> > > >> Just thinking out loud here but I think the one way to solve long > > >> standing Steve objective is indeed to have per series sections of the > > >> website (including download, documentation, migration guide) > > >> And a top nav for "latest/promoted" releases (like we have today > > >> really). > > >> How do you merge the two navigation wise is what I don't know. > > >> This is for later work anyways. > > >> > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 14 09:29:37 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Sep 2017 13:29:37 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: This makes me a little nervous in the case we ever publish other manuals/docs. IMO the better option is to publish an index.html that is currently just a redirect to the User Manual On Thu, Sep 14, 2017, 7:55 AM Vlad Mihalcea wrote: > Hi, > > To be able to load the User Guide like this: > > https://docs.jboss.org/hibernate/orm/5.2 > > > we have two options: > > 1. Either we rename the User Guide to index.adoc so that it will become > index.html. > 2. We leave it as-is, but when we copy the docs to JBoss, we also copy the > User Guide as index.html as well. This will allow our users to retain > bookmarks they've created since we published the new User Guide. > > Let me know which one do you prefer. > Vlad > > On Thu, Sep 14, 2017 at 3:34 PM, Steve Ebersole > wrote: > >> Yoann, >> >> First thanks for the work on this. I think it looks worlds better. A few >> minor things: >> >> >> 1. Not sure of the source for this, but can we fix these doc link for > > >> 5.2 from ` >> >> https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html` >> >> to `https://docs.jboss.org/hibernate/orm/5.2` >> ? Also, why https? Not >> sure it matters, just found it odd >> > 2. Much of the information on that ORM releases page is, in turn, > > >> version/series specific. Any reason why those pieces of information >> are >> not part of the series? Either in the synopsis on the releases page >> or on >> the specific series page, or both. Specifically >> > 1. "Compatibility Matrix" - the fact that its a table based on series > > >> is a good indicator it is all series specific ;) >> > 2. "Maven Repository" - I'd personally prefer to have this as part of >> the series info >> 3. I think the individual series pages are missing a key piece of > > >> information... the "synopsis" of that series. I guess partially this >> fits >> under "what's new" >> >> Other than these minor things I love it. Great job! >> >> P.S. another question is whether (and if so, how) to apply the same >> treatment to the Documentation info in terms of the nav links. >> > >> On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere >> wrote: >> >> > I polished the changes, applied them to all projects (ORM, OGM, >> Validator, >> > Search), and sent a PR: >> > https://github.com/hibernate/hibernate.org/pull/126 >> > Could you guys review it? Mainly I'd need one person per project to >> check >> > they agree with the changes, especially in their project's section. >> > Also, there's still a bit of work to do for each project, mainly filling >> > in missing metadata (see the PR). >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > On 14 September 2017 at 10:38, Emmanuel Bernard > > >> > wrote: >> > >> >> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >> >> >> >>> On 13 September 2017 at 10:51, Yoann Rodiere >> >>> wrote: >> >>> >> >>>> It's more the number of columns, what if you add more version, >> should I >> >>>>> scroll horizontally? Also releeases tend to be shown vertically with >> >>>>> version in desc order. This model breaks a bit this habit. >> >>>>> >> >>>> >> >>>> >> >>>> At least versions are in desc order :D >> >>>> More seriously, I was more worried about the number of dependencies >> than >> >>>> about the number of series. We don't want to maintain a hundred >> >>>> branches, so >> >>>> we'll probably try to keep the number of series to a minimum, but we >> do >> >>>> want >> >>>> to offer as much as possible to users, so we may offer many different >> >>>> integrations, and thus many different dependencies. Just think if the >> >>>> ORM >> >>>> team wants to display supported versions of each DBMS... So I thought >> >>>> showing versions horizontally would be more future-proof. >> >>>> I'll try to add horizontal scrolling to the table. The oldest >> releases >> >>>> may >> >>>> not be displayed, but then those are not the one we want to >> advertise, >> >>>> so... >> >>>> And in any case, we have limited horizontal space, so we have to hide >> >>>> *something*. >> >>>> About phones, I think bootstrap has something, I'll give it a try. >> >>>> >> >>>> On "Downloads" we only want to promote the active branches; have some >> >>>>> basic series descriptions but way more ecclectic than the releases >> >>>>> descriptions. We make them cross-linked and everyone is happy? >> >>>>> >> >>>> >> >>>> >> >>>> Sure, we can do that. But the "downloads" page will essentially be a >> >>>> stripped-down version of the "releases" page. >> >>>> >> >>> >> >>> +1 since maintenance is automated I see no problem with a little >> >>> redundancy. >> >>> >> >> >> >> I'm not sure two pages is really solving the problem. It looks like you >> >> don't want to make a choice. But I don't have a pro/con opinion. >> >> My real concern is since you will have two pages, what's the navigation >> >> logic? How do you reach each on of these pages? >> >> >> >> Just thinking out loud here but I think the one way to solve long >> >> standing Steve objective is indeed to have per series sections of the >> >> website (including download, documentation, migration guide) >> >> And a top nav for "latest/promoted" releases (like we have today >> >> really). >> >> How do you merge the two navigation wise is what I don't know. >> >> This is for later work anyways. >> >> >> > >> > >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Thu Sep 14 10:05:03 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Sep 2017 14:05:03 +0000 Subject: [hibernate-dev] How is LogicalConnectionImplementor#makeShareableCopy intended to be used? In-Reply-To: References: Message-ID: It was originally intended for "shared Session" handling, but we ended up handling this differently. I believe this can go away. On Tue, Sep 12, 2017 at 2:42 PM Gail Badner wrote: > LogicalConnectionImplementor#makeShareableCopy [1] doesn't seem to be used > by anything. > > The implemented method in LogicalConnectionManagedImpl returns null. [2] > > Should this method be deprecated? > > I'm asking because I created a PR [3] that allows passing JdbcObserver > to ResourceRegistryStandardImpl so that any existing batch can be cleaned > up before releasing JDBC resources. > > In my PR, the LogicalConnectionProvidedImpl#makeShareableCopy results in a > LogicalConnectionProvidedImpl with a ResourceRegistryStandardImpl that has > a null JdbcObserver. > > It didn't make sense to me that the original and shareable > ResourceRegistryStandardImpl should both have the same JdbcObserver, but > I'm really not sure about this. > > If LogicalConnectionImplementor#makeShareableCopy really is not used and > should be deprecated, I won't worry about this. > > I'd like to get my PR merged for 5.2.11 tomorrow, so a quick response would > be greatly appreciated. If I don't hear back, I'll push it to 5.2.12. > > Thanks, > Gail > > [1] > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/spi/LogicalConnectionImplementor.java#L61-L66 > [2] > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/internal/LogicalConnectionManagedImpl.java#L217-L223 > [3] https://github.com/hibernate/hibernate-orm/pull/2004 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 14 10:05:40 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Sep 2017 14:05:40 +0000 Subject: [hibernate-dev] How is LogicalConnectionImplementor#makeShareableCopy intended to be used? In-Reply-To: References: Message-ID: However, as it is part of the SPI its probably better to deprecate it and we can remove it in 6.0 On Thu, Sep 14, 2017 at 9:05 AM Steve Ebersole wrote: > It was originally intended for "shared Session" handling, but we ended up > handling this differently. I believe this can go away. > > On Tue, Sep 12, 2017 at 2:42 PM Gail Badner wrote: > >> LogicalConnectionImplementor#makeShareableCopy [1] doesn't seem to be used >> by anything. >> >> The implemented method in LogicalConnectionManagedImpl returns null. [2] >> >> Should this method be deprecated? >> >> I'm asking because I created a PR [3] that allows passing JdbcObserver >> to ResourceRegistryStandardImpl so that any existing batch can be cleaned >> up before releasing JDBC resources. >> >> In my PR, the LogicalConnectionProvidedImpl#makeShareableCopy results in a >> LogicalConnectionProvidedImpl with a ResourceRegistryStandardImpl that has >> a null JdbcObserver. >> >> It didn't make sense to me that the original and shareable >> ResourceRegistryStandardImpl should both have the same JdbcObserver, but >> I'm really not sure about this. >> >> If LogicalConnectionImplementor#makeShareableCopy really is not used and >> should be deprecated, I won't worry about this. >> >> I'd like to get my PR merged for 5.2.11 tomorrow, so a quick response >> would >> be greatly appreciated. If I don't hear back, I'll push it to 5.2.12. >> >> Thanks, >> Gail >> >> [1] >> >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/spi/LogicalConnectionImplementor.java#L61-L66 >> [2] >> >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/internal/LogicalConnectionManagedImpl.java#L217-L223 >> [3] https://github.com/hibernate/hibernate-orm/pull/2004 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From yoann at hibernate.org Thu Sep 14 13:21:00 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 14 Sep 2017 19:21:00 +0200 Subject: [hibernate-dev] Hibernate Search 5.8.0.Final released Message-ID: Hello everyone, We just released Hibernate Search 5.8.0.Final. Hibernate Search now integrates with all version of Elasticsearch from 2.0 to 5.6! Check out our blog for more information about this release: http://in.relation.to/2017/09/14/hibernate-search-5-8-0-Final/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From sanne at hibernate.org Thu Sep 14 13:33:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 14 Sep 2017 18:33:50 +0100 Subject: [hibernate-dev] [hibernate-announce] Hibernate Search 5.8.0.Final released In-Reply-To: References: Message-ID: This was an amazing amount of work :) Congratulations! Also, perfectly timed in synch just after the ORM release 5.2.11.Final, just following up the Elasticsearch 5.6 release, compatible with WildFly 11, ready for Java 9 and already integrated into Infinispan 9.1 ! On 14 September 2017 at 18:21, Yoann Rodiere wrote: > Hello everyone, > > We just released Hibernate Search 5.8.0.Final. Hibernate Search now > integrates with all version of Elasticsearch from 2.0 to 5.6! > > Check out our blog for more information about this release: > > http://in.relation.to/2017/09/14/hibernate-search-5-8-0-Final/ > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > _______________________________________________ > hibernate-announce mailing list > hibernate-announce at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-announce From emmanuel at hibernate.org Thu Sep 14 15:03:12 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 14 Sep 2017 21:03:12 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: <3EE174CC-AA33-47EF-9387-32AC587E3D33@hibernate.org> I don?t like it. It?s less important than what the various versions bring (the onliner) and the ability to go download them right away. > On 14 Sep 2017, at 15:27, Guillaume Smet wrote: > > Hi, > > Would anyone have something about putting the Compatibility matrix before > the Series part in the page: http://staging.hibernate.org/ogm/releases/ ? > > Atm, we don't see the matrix at a quick glance (I totally missed it until > Yoann told me it was there) and I think it's probably the first information > you need when you want to download something. Typically, if you're stuck to > Java 6 for whatever reasons, no need to take a look at the 5.2 serie. > > It's maybe a little less sexy but it would be more useful IMHO. > > -- > Guillaume > > On Thu, Sep 14, 2017 at 2:55 PM, Vlad Mihalcea > wrote: > >> Hi, >> >> To be able to load the User Guide like this: >> >> https://docs.jboss.org/hibernate/orm/5.2 >> >> >> we have two options: >> >> 1. Either we rename the User Guide to index.adoc so that it will become >> index.html. >> 2. We leave it as-is, but when we copy the docs to JBoss, we also copy the >> User Guide as index.html as well. This will allow our users to retain >> bookmarks they've created since we published the new User Guide. >> >> Let me know which one do you prefer. >> Vlad >> >> On Thu, Sep 14, 2017 at 3:34 PM, Steve Ebersole >> wrote: >> >>> Yoann, >>> >>> First thanks for the work on this. I think it looks worlds better. A >> few >>> minor things: >>> >>> >>> 1. Not sure of the source for this, but can we fix these doc link for >>> 5.2 from ` >>> https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/ >>> Hibernate_User_Guide.html` >>> to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not >>> sure it matters, just found it odd >>> 2. Much of the information on that ORM releases page is, in turn, >>> version/series specific. Any reason why those pieces of information >> are >>> not part of the series? Either in the synopsis on the releases page >> or >>> on >>> the specific series page, or both. Specifically >>> 1. "Compatibility Matrix" - the fact that its a table based on >> series >>> is a good indicator it is all series specific ;) >>> 2. "Maven Repository" - I'd personally prefer to have this as part >> of >>> the series info >>> 3. I think the individual series pages are missing a key piece of >>> information... the "synopsis" of that series. I guess partially this >>> fits >>> under "what's new" >>> >>> Other than these minor things I love it. Great job! >>> >>> P.S. another question is whether (and if so, how) to apply the same >>> treatment to the Documentation info in terms of the nav links. >>> >>> On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere >> wrote: >>> >>>> I polished the changes, applied them to all projects (ORM, OGM, >>> Validator, >>>> Search), and sent a PR: >>>> https://github.com/hibernate/hibernate.org/pull/126 >>>> Could you guys review it? Mainly I'd need one person per project to >> check >>>> they agree with the changes, especially in their project's section. >>>> Also, there's still a bit of work to do for each project, mainly >> filling >>>> in missing metadata (see the PR). >>>> >>>> Yoann Rodi?re >>>> Hibernate NoORM Team >>>> yoann at hibernate.org >>>> >>>> On 14 September 2017 at 10:38, Emmanuel Bernard < >> emmanuel at hibernate.org> >>>> wrote: >>>> >>>>> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >>>>> >>>>>> On 13 September 2017 at 10:51, Yoann Rodiere >>>>>> wrote: >>>>>> >>>>>>> It's more the number of columns, what if you add more version, >> should >>> I >>>>>>>> scroll horizontally? Also releeases tend to be shown vertically >> with >>>>>>>> version in desc order. This model breaks a bit this habit. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> At least versions are in desc order :D >>>>>>> More seriously, I was more worried about the number of dependencies >>> than >>>>>>> about the number of series. We don't want to maintain a hundred >>>>>>> branches, so >>>>>>> we'll probably try to keep the number of series to a minimum, but we >>> do >>>>>>> want >>>>>>> to offer as much as possible to users, so we may offer many >> different >>>>>>> integrations, and thus many different dependencies. Just think if >> the >>>>>>> ORM >>>>>>> team wants to display supported versions of each DBMS... So I >> thought >>>>>>> showing versions horizontally would be more future-proof. >>>>>>> I'll try to add horizontal scrolling to the table. The oldest >> releases >>>>>>> may >>>>>>> not be displayed, but then those are not the one we want to >> advertise, >>>>>>> so... >>>>>>> And in any case, we have limited horizontal space, so we have to >> hide >>>>>>> *something*. >>>>>>> About phones, I think bootstrap has something, I'll give it a try. >>>>>>> >>>>>>> On "Downloads" we only want to promote the active branches; have >> some >>>>>>>> basic series descriptions but way more ecclectic than the releases >>>>>>>> descriptions. We make them cross-linked and everyone is happy? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Sure, we can do that. But the "downloads" page will essentially be a >>>>>>> stripped-down version of the "releases" page. >>>>>>> >>>>>> >>>>>> +1 since maintenance is automated I see no problem with a little >>>>>> redundancy. >>>>>> >>>>> >>>>> I'm not sure two pages is really solving the problem. It looks like >> you >>>>> don't want to make a choice. But I don't have a pro/con opinion. >>>>> My real concern is since you will have two pages, what's the >> navigation >>>>> logic? How do you reach each on of these pages? >>>>> >>>>> Just thinking out loud here but I think the one way to solve long >>>>> standing Steve objective is indeed to have per series sections of the >>>>> website (including download, documentation, migration guide) >>>>> And a top nav for "latest/promoted" releases (like we have today >>>>> really). >>>>> How do you merge the two navigation wise is what I don't know. >>>>> This is for later work anyways. >>>>> >>>> >>>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Thu Sep 14 15:12:04 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 14 Sep 2017 12:12:04 -0700 Subject: [hibernate-dev] How is LogicalConnectionImplementor#makeShareableCopy intended to be used? In-Reply-To: References: Message-ID: I created HHH-11989 to deprecate in 5.2.12, and HHH-11990 to remove it. Thanks, Gail On Thu, Sep 14, 2017 at 7:05 AM, Steve Ebersole wrote: > However, as it is part of the SPI its probably better to deprecate it and > we can remove it in 6.0 > > On Thu, Sep 14, 2017 at 9:05 AM Steve Ebersole > wrote: > >> It was originally intended for "shared Session" handling, but we ended up >> handling this differently. I believe this can go away. >> >> On Tue, Sep 12, 2017 at 2:42 PM Gail Badner wrote: >> >>> LogicalConnectionImplementor#makeShareableCopy [1] doesn't seem to be >>> used >>> by anything. >>> >>> The implemented method in LogicalConnectionManagedImpl returns null. [2] >>> >>> Should this method be deprecated? >>> >>> I'm asking because I created a PR [3] that allows passing JdbcObserver >>> to ResourceRegistryStandardImpl so that any existing batch can be cleaned >>> up before releasing JDBC resources. >>> >>> In my PR, the LogicalConnectionProvidedImpl#makeShareableCopy results >>> in a >>> LogicalConnectionProvidedImpl with a ResourceRegistryStandardImpl that >>> has >>> a null JdbcObserver. >>> >>> It didn't make sense to me that the original and shareable >>> ResourceRegistryStandardImpl should both have the same JdbcObserver, but >>> I'm really not sure about this. >>> >>> If LogicalConnectionImplementor#makeShareableCopy really is not used and >>> should be deprecated, I won't worry about this. >>> >>> I'd like to get my PR merged for 5.2.11 tomorrow, so a quick response >>> would >>> be greatly appreciated. If I don't hear back, I'll push it to 5.2.12. >>> >>> Thanks, >>> Gail >>> >>> [1] >>> https://github.com/hibernate/hibernate-orm/blob/master/ >>> hibernate-core/src/main/java/org/hibernate/resource/jdbc/spi/ >>> LogicalConnectionImplementor.java#L61-L66 >>> [2] >>> https://github.com/hibernate/hibernate-orm/blob/master/ >>> hibernate-core/src/main/java/org/hibernate/resource/jdbc/internal/ >>> LogicalConnectionManagedImpl.java#L217-L223 >>> [3] https://github.com/hibernate/hibernate-orm/pull/2004 >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From guillaume.smet at gmail.com Thu Sep 14 17:06:57 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 14 Sep 2017 23:06:57 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: <3EE174CC-AA33-47EF-9387-32AC587E3D33@hibernate.org> References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> <3EE174CC-AA33-47EF-9387-32AC587E3D33@hibernate.org> Message-ID: On Thu, Sep 14, 2017 at 9:03 PM, Emmanuel Bernard wrote: > I don?t like it. It?s less important than what the various versions bring > (the onliner) and the ability to go download them right away. > OK. Let's agree to disagree :). We often have SO questions of people not using the right version. Not sure it would help to put the information more visible though. -- Guillaume From sanne at hibernate.org Fri Sep 15 09:50:57 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 15 Sep 2017 14:50:57 +0100 Subject: [hibernate-dev] New `noorm-admins` team on Github & proposal for group restructuring Message-ID: I created a new team on Github and am giving it admin privileges to Validator, Search, OGM, and the related support repositories (JPQL parser, HCANN). This is to give some selected members admin privileges on the repositories; useful as it allows us to "proctect" branches when we create maintenance release branches, which is becoming routine so I shouldn't be the only one with such privileges. It also allows all members to delete repositories and/or to temporarily remove such protection in case of extreme need. Needless to say, I expect some kind of quorum among us - in writing on this mailing list - before taking any such initiatives! We already had an Admin team but I'm no longer comfortable in using a single Admin team for all 30+ repositories, it requires giving too many privileges to too many people. The single admin team is a legacy of how GitHub used to work in the past; let's disband it and replace it with more fine grained groups? Thanks, Sanne From steve at hibernate.org Fri Sep 15 13:50:09 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 15 Sep 2017 17:50:09 +0000 Subject: [hibernate-dev] New `noorm-admins` team on Github & proposal for group restructuring In-Reply-To: References: Message-ID: +1 On Fri, Sep 15, 2017, 9:10 AM Sanne Grinovero wrote: > I created a new team on Github and am giving it admin privileges to > Validator, Search, OGM, and the related support repositories (JPQL > parser, HCANN). > > This is to give some selected members admin privileges on the > repositories; useful as it allows us to "proctect" branches when we > create maintenance release branches, which is becoming routine so I > shouldn't be the only one with such privileges. > > It also allows all members to delete repositories and/or to > temporarily remove such protection in case of extreme need. Needless > to say, I expect some kind of quorum among us - in writing on this > mailing list - before taking any such initiatives! > > We already had an Admin team but I'm no longer comfortable in using a > single Admin team for all 30+ repositories, it requires giving too > many privileges to too many people. > The single admin team is a legacy of how GitHub used to work in the > past; let's disband it and replace it with more fine grained groups? > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Sep 18 04:44:09 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 18 Sep 2017 09:44:09 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: On 14 September 2017 at 13:34, Steve Ebersole wrote: > Yoann, > > First thanks for the work on this. I think it looks worlds better. A few > minor things: > > Not sure of the source for this, but can we fix these doc link for 5.2 from > `https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html` > to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not sure > it matters, just found it odd Specifically about the `https` question: there's no longer any reason standing to avoid https, other than it being slightly more work to setup - in this case it's done by the jboss.org team so we can take advantage from it at no extra effort. There are several benefits in using it from the SEO perspective though so we should use and encourage it whenever possible, to make these URLs the canonical ones for the documentation. (and also because otherwise bots (and people) need to be thaught that this content is now available over https as well). Ideally we should set it up for our websites too. Thanks, Sanne > Much of the information on that ORM releases page is, in turn, > version/series specific. Any reason why those pieces of information are not > part of the series? Either in the synopsis on the releases page or on the > specific series page, or both. Specifically > > "Compatibility Matrix" - the fact that its a table based on series is a good > indicator it is all series specific ;) > "Maven Repository" - I'd personally prefer to have this as part of the > series info > > I think the individual series pages are missing a key piece of > information... the "synopsis" of that series. I guess partially this fits > under "what's new" > > Other than these minor things I love it. Great job! > > P.S. another question is whether (and if so, how) to apply the same > treatment to the Documentation info in terms of the nav links. > > On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere wrote: >> >> I polished the changes, applied them to all projects (ORM, OGM, Validator, >> Search), and sent a PR: https://github.com/hibernate/hibernate.org/pull/126 >> Could you guys review it? Mainly I'd need one person per project to check >> they agree with the changes, especially in their project's section. >> Also, there's still a bit of work to do for each project, mainly filling >> in missing metadata (see the PR). >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 14 September 2017 at 10:38, Emmanuel Bernard >> wrote: >>> >>> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >>>> >>>> On 13 September 2017 at 10:51, Yoann Rodiere >>>> wrote: >>>>>> >>>>>> It's more the number of columns, what if you add more version, should >>>>>> I >>>>>> scroll horizontally? Also releeases tend to be shown vertically with >>>>>> version in desc order. This model breaks a bit this habit. >>>>> >>>>> >>>>> >>>>> At least versions are in desc order :D >>>>> More seriously, I was more worried about the number of dependencies >>>>> than >>>>> about the number of series. We don't want to maintain a hundred >>>>> branches, so >>>>> we'll probably try to keep the number of series to a minimum, but we do >>>>> want >>>>> to offer as much as possible to users, so we may offer many different >>>>> integrations, and thus many different dependencies. Just think if the >>>>> ORM >>>>> team wants to display supported versions of each DBMS... So I thought >>>>> showing versions horizontally would be more future-proof. >>>>> I'll try to add horizontal scrolling to the table. The oldest releases >>>>> may >>>>> not be displayed, but then those are not the one we want to advertise, >>>>> so... >>>>> And in any case, we have limited horizontal space, so we have to hide >>>>> *something*. >>>>> About phones, I think bootstrap has something, I'll give it a try. >>>>> >>>>>> On "Downloads" we only want to promote the active branches; have some >>>>>> basic series descriptions but way more ecclectic than the releases >>>>>> descriptions. We make them cross-linked and everyone is happy? >>>>> >>>>> >>>>> >>>>> Sure, we can do that. But the "downloads" page will essentially be a >>>>> stripped-down version of the "releases" page. >>>> >>>> >>>> +1 since maintenance is automated I see no problem with a little >>>> redundancy. >>> >>> >>> I'm not sure two pages is really solving the problem. It looks like you >>> don't want to make a choice. But I don't have a pro/con opinion. >>> My real concern is since you will have two pages, what's the navigation >>> logic? How do you reach each on of these pages? >>> >>> Just thinking out loud here but I think the one way to solve long >>> standing Steve objective is indeed to have per series sections of the >>> website (including download, documentation, migration guide) >>> And a top nav for "latest/promoted" releases (like we have today >>> really). >>> How do you merge the two navigation wise is what I don't know. >>> This is for later work anyways. >> >> > From yoann at hibernate.org Tue Sep 19 02:36:26 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 19 Sep 2017 08:36:26 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: So, following the comments and a discussion on Hangouts on Friday, I worked a bit more, and I just pushed what will hopefully be the last version ;) Main changes: - The "Releases" menu entry now has one sub-entry for each series - The big, green/yellow buttons related to the stable/development releases, and located on the top of the "About" page and "Releases" page. Previously they allowed to download a ZIP, but that's arguably not very useful without all the information provided by the series page (documentation, "What's new", compatibility, ...). So now, they redirect to the dedicated page of the current stable/development series. See for example http://staging.hibernate.org/ogm/ - The list of series in the "Releases" page has been modified to better suit its new purpose: it's just a hub to the dedicated page of each series, and as such its content should be very clear and provide obvious links to the page for each series. I made do with what's available in our current CSS framework (it's Bootstrap 2, which is very old), but I have good hope that we could improve on that one day (if we upgrade to Bootstrap 3/4). See for example http://staging.hibernate.org/ogm/releases/ - The maven coordinates and download link for the latest releases has moved to the series-specific page. It is configurable for each project: one can specify in the series.yml file which artifacts should be displayed, and add a summary for each artifact. I decided against the XML format and simply displayed the GAV as groupId:artifactId:version. Two reasons: 1. The XML format is really, really verbose, and the pages are long enough as they are (one already needs to scroll one screen down to see the "What's new" section). 2. I can't create a single syntax-highlighted block from the content of YAML files (if I switch to the AsciiDoc format, I don't have access to the loop features of HAML, and if I stick to HAML I don't have access to AsciiDoc syntax highlighting). Yes, we could probably solve 2, given enough time. And yes, I suppose we could find better UI alternatives using tabs or whatever. But I've already spent way too much time on this. Could we just agree it's good enough and work on this later? See for example http://staging.hibernate.org/search/releases/5.8/#get_it - As requested, I updated the "survival guide": http://staging. hibernate.org/survival-guide/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 18 September 2017 at 10:44, Sanne Grinovero wrote: > On 14 September 2017 at 13:34, Steve Ebersole wrote: > > Yoann, > > > > First thanks for the work on this. I think it looks worlds better. A > few > > minor things: > > > > Not sure of the source for this, but can we fix these doc link for 5.2 > from > > `https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/ > Hibernate_User_Guide.html` > > to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not > sure > > it matters, just found it odd > > Specifically about the `https` question: there's no longer any reason > standing to avoid https, other than it being slightly more work to > setup - in this case it's done by the jboss.org team so we can take > advantage from it at no extra effort. > > There are several benefits in using it from the SEO perspective though > so we should use and encourage it whenever possible, to make these > URLs the canonical ones for the documentation. (and also because > otherwise bots (and people) need to be thaught that this content is > now available over https as well). > > Ideally we should set it up for our websites too. > > Thanks, > Sanne > > > Much of the information on that ORM releases page is, in turn, > > version/series specific. Any reason why those pieces of information are > not > > part of the series? Either in the synopsis on the releases page or on > the > > specific series page, or both. Specifically > > > > "Compatibility Matrix" - the fact that its a table based on series is a > good > > indicator it is all series specific ;) > > "Maven Repository" - I'd personally prefer to have this as part of the > > series info > > > > I think the individual series pages are missing a key piece of > > information... the "synopsis" of that series. I guess partially this > fits > > under "what's new" > > > > Other than these minor things I love it. Great job! > > > > P.S. another question is whether (and if so, how) to apply the same > > treatment to the Documentation info in terms of the nav links. > > > > On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere > wrote: > >> > >> I polished the changes, applied them to all projects (ORM, OGM, > Validator, > >> Search), and sent a PR: https://github.com/hibernate/ > hibernate.org/pull/126 > >> Could you guys review it? Mainly I'd need one person per project to > check > >> they agree with the changes, especially in their project's section. > >> Also, there's still a bit of work to do for each project, mainly filling > >> in missing metadata (see the PR). > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> yoann at hibernate.org > >> > >> On 14 September 2017 at 10:38, Emmanuel Bernard > > >> wrote: > >>> > >>> On Wed 17-09-13 10:55, Sanne Grinovero wrote: > >>>> > >>>> On 13 September 2017 at 10:51, Yoann Rodiere > >>>> wrote: > >>>>>> > >>>>>> It's more the number of columns, what if you add more version, > should > >>>>>> I > >>>>>> scroll horizontally? Also releeases tend to be shown vertically with > >>>>>> version in desc order. This model breaks a bit this habit. > >>>>> > >>>>> > >>>>> > >>>>> At least versions are in desc order :D > >>>>> More seriously, I was more worried about the number of dependencies > >>>>> than > >>>>> about the number of series. We don't want to maintain a hundred > >>>>> branches, so > >>>>> we'll probably try to keep the number of series to a minimum, but we > do > >>>>> want > >>>>> to offer as much as possible to users, so we may offer many different > >>>>> integrations, and thus many different dependencies. Just think if the > >>>>> ORM > >>>>> team wants to display supported versions of each DBMS... So I thought > >>>>> showing versions horizontally would be more future-proof. > >>>>> I'll try to add horizontal scrolling to the table. The oldest > releases > >>>>> may > >>>>> not be displayed, but then those are not the one we want to > advertise, > >>>>> so... > >>>>> And in any case, we have limited horizontal space, so we have to hide > >>>>> *something*. > >>>>> About phones, I think bootstrap has something, I'll give it a try. > >>>>> > >>>>>> On "Downloads" we only want to promote the active branches; have > some > >>>>>> basic series descriptions but way more ecclectic than the releases > >>>>>> descriptions. We make them cross-linked and everyone is happy? > >>>>> > >>>>> > >>>>> > >>>>> Sure, we can do that. But the "downloads" page will essentially be a > >>>>> stripped-down version of the "releases" page. > >>>> > >>>> > >>>> +1 since maintenance is automated I see no problem with a little > >>>> redundancy. > >>> > >>> > >>> I'm not sure two pages is really solving the problem. It looks like you > >>> don't want to make a choice. But I don't have a pro/con opinion. > >>> My real concern is since you will have two pages, what's the navigation > >>> logic? How do you reach each on of these pages? > >>> > >>> Just thinking out loud here but I think the one way to solve long > >>> standing Steve objective is indeed to have per series sections of the > >>> website (including download, documentation, migration guide) > >>> And a top nav for "latest/promoted" releases (like we have today > >>> really). > >>> How do you merge the two navigation wise is what I don't know. > >>> This is for later work anyways. > >> > >> > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Thu Sep 21 11:10:11 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 21 Sep 2017 17:10:11 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: No answer? So I guess I can merge it whenever I want? :-) Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 19 September 2017 at 08:36, Yoann Rodiere wrote: > So, following the comments and a discussion on Hangouts on Friday, I > worked a bit more, and I just pushed what will hopefully be the last > version ;) > > Main changes: > > - The "Releases" menu entry now has one sub-entry for each series > - The big, green/yellow buttons related to the stable/development > releases, and located on the top of the "About" page and "Releases" page. > Previously they allowed to download a ZIP, but that's arguably not > very useful without all the information provided by the series page > (documentation, "What's new", compatibility, ...). > So now, they redirect to the dedicated page of the current > stable/development series. > See for example http://staging.hibernate.org/ogm/ > - The list of series in the "Releases" page has been modified to > better suit its new purpose: it's just a hub to the dedicated page of each > series, and as such its content should be very clear and provide obvious > links to the page for each series. I made do with what's available in our > current CSS framework (it's Bootstrap 2, which is very old), but I have > good hope that we could improve on that one day (if we upgrade to Bootstrap > 3/4). > See for example http://staging.hibernate.org/ogm/releases/ > - The maven coordinates and download link for the latest releases has > moved to the series-specific page. It is configurable for each project: one > can specify in the series.yml file which artifacts should be displayed, and > add a summary for each artifact. > I decided against the XML format and simply displayed the GAV as > groupId:artifactId:version. Two reasons: > 1. The XML format is really, really verbose, and the pages are long > enough as they are (one already needs to scroll one screen down to see the > "What's new" section). > 2. I can't create a single syntax-highlighted block from the content > of YAML files (if I switch to the AsciiDoc format, I don't have access to > the loop features of HAML, and if I stick to HAML I don't have access to > AsciiDoc syntax highlighting). > Yes, we could probably solve 2, given enough time. And yes, I suppose > we could find better UI alternatives using tabs or whatever. But I've > already spent way too much time on this. Could we just agree it's good > enough and work on this later? > See for example http://staging.hibernate.org/search/releases/5.8/# > get_it > - As requested, I updated the "survival guide": http://staging.hiberna > te.org/survival-guide/ > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 18 September 2017 at 10:44, Sanne Grinovero > wrote: > >> On 14 September 2017 at 13:34, Steve Ebersole >> wrote: >> > Yoann, >> > >> > First thanks for the work on this. I think it looks worlds better. A >> few >> > minor things: >> > >> > Not sure of the source for this, but can we fix these doc link for 5.2 >> from >> > `https://docs.jboss.org/hibernate/stable/orm/userguide/html_ >> single/Hibernate_User_Guide.html` >> >> > to `https://docs.jboss.org/hibernate/orm/5.2` >> ? Also, why https? Not sure >> > it matters, just found it odd >> >> Specifically about the `https` question: there's no longer any reason >> standing to avoid https, other than it being slightly more work to >> setup - in this case it's done by the jboss.org team so we can take >> advantage from it at no extra effort. >> >> There are several benefits in using it from the SEO perspective though >> so we should use and encourage it whenever possible, to make these >> URLs the canonical ones for the documentation. (and also because >> otherwise bots (and people) need to be thaught that this content is >> now available over https as well). >> >> Ideally we should set it up for our websites too. >> >> Thanks, >> Sanne >> >> > Much of the information on that ORM releases page is, in turn, >> > version/series specific. Any reason why those pieces of information >> are not >> > part of the series? Either in the synopsis on the releases page or on >> the >> > specific series page, or both. Specifically >> > >> > "Compatibility Matrix" - the fact that its a table based on series is a >> good >> > indicator it is all series specific ;) >> > "Maven Repository" - I'd personally prefer to have this as part of the >> > series info >> > >> > I think the individual series pages are missing a key piece of >> > information... the "synopsis" of that series. I guess partially this >> fits >> > under "what's new" >> > >> > Other than these minor things I love it. Great job! >> > >> > P.S. another question is whether (and if so, how) to apply the same >> > treatment to the Documentation info in terms of the nav links. >> > >> > On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere >> wrote: >> >> >> >> I polished the changes, applied them to all projects (ORM, OGM, >> Validator, >> >> Search), and sent a PR: https://github.com/hibernate/h >> ibernate.org/pull/126 >> >> Could you guys review it? Mainly I'd need one person per project to >> check >> >> they agree with the changes, especially in their project's section. >> >> Also, there's still a bit of work to do for each project, mainly >> filling >> >> in missing metadata (see the PR). >> >> >> >> Yoann Rodi?re >> >> Hibernate NoORM Team >> >> yoann at hibernate.org >> >> >> >> On 14 September 2017 at 10:38, Emmanuel Bernard < >> emmanuel at hibernate.org> >> >> wrote: >> >>> >> >>> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >> >>>> >> >>>> On 13 September 2017 at 10:51, Yoann Rodiere >> >>>> wrote: >> >>>>>> >> >>>>>> It's more the number of columns, what if you add more version, >> should >> >>>>>> I >> >>>>>> scroll horizontally? Also releeases tend to be shown vertically >> with >> >>>>>> version in desc order. This model breaks a bit this habit. >> >>>>> >> >>>>> >> >>>>> >> >>>>> At least versions are in desc order :D >> >>>>> More seriously, I was more worried about the number of dependencies >> >>>>> than >> >>>>> about the number of series. We don't want to maintain a hundred >> >>>>> branches, so >> >>>>> we'll probably try to keep the number of series to a minimum, but >> we do >> >>>>> want >> >>>>> to offer as much as possible to users, so we may offer many >> different >> >>>>> integrations, and thus many different dependencies. Just think if >> the >> >>>>> ORM >> >>>>> team wants to display supported versions of each DBMS... So I >> thought >> >>>>> showing versions horizontally would be more future-proof. >> >>>>> I'll try to add horizontal scrolling to the table. The oldest >> releases >> >>>>> may >> >>>>> not be displayed, but then those are not the one we want to >> advertise, >> >>>>> so... >> >>>>> And in any case, we have limited horizontal space, so we have to >> hide >> >>>>> *something*. >> >>>>> About phones, I think bootstrap has something, I'll give it a try. >> >>>>> >> >>>>>> On "Downloads" we only want to promote the active branches; have >> some >> >>>>>> basic series descriptions but way more ecclectic than the releases >> >>>>>> descriptions. We make them cross-linked and everyone is happy? >> >>>>> >> >>>>> >> >>>>> >> >>>>> Sure, we can do that. But the "downloads" page will essentially be a >> >>>>> stripped-down version of the "releases" page. >> >>>> >> >>>> >> >>>> +1 since maintenance is automated I see no problem with a little >> >>>> redundancy. >> >>> >> >>> >> >>> I'm not sure two pages is really solving the problem. It looks like >> you >> >>> don't want to make a choice. But I don't have a pro/con opinion. >> >>> My real concern is since you will have two pages, what's the >> navigation >> >>> logic? How do you reach each on of these pages? >> >>> >> >>> Just thinking out loud here but I think the one way to solve long >> >>> standing Steve objective is indeed to have per series sections of the >> >>> website (including download, documentation, migration guide) >> >>> And a top nav for "latest/promoted" releases (like we have today >> >>> really). >> >>> How do you merge the two navigation wise is what I don't know. >> >>> This is for later work anyways. >> >> >> >> >> > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Thu Sep 21 12:19:27 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 21 Sep 2017 18:19:27 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Looks like the issues I reported directly to you are fixed so it's OK for me. Emmanuel? On Thu, Sep 21, 2017 at 5:10 PM, Yoann Rodiere wrote: > No answer? So I guess I can merge it whenever I want? :-) > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > From sanne at hibernate.org Thu Sep 21 12:45:36 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 21 Sep 2017 17:45:36 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: I like it, looking forward to integration. *IF* you are willing to improve a minor point: I didn't expect the "Releases" menu to be expanded when not being in any of these sections. Related: I wouldn't highlight both the current release and the "Releases" label, the shading looks odd and misaligned. Thanks! Sanne On 21 September 2017 at 16:10, Yoann Rodiere wrote: > No answer? So I guess I can merge it whenever I want? :-) > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 19 September 2017 at 08:36, Yoann Rodiere wrote: >> >> So, following the comments and a discussion on Hangouts on Friday, I >> worked a bit more, and I just pushed what will hopefully be the last version >> ;) >> >> Main changes: >> >> The "Releases" menu entry now has one sub-entry for each series >> The big, green/yellow buttons related to the stable/development releases, >> and located on the top of the "About" page and "Releases" page. >> Previously they allowed to download a ZIP, but that's arguably not very >> useful without all the information provided by the series page >> (documentation, "What's new", compatibility, ...). >> So now, they redirect to the dedicated page of the current >> stable/development series. >> See for example http://staging.hibernate.org/ogm/ >> The list of series in the "Releases" page has been modified to better suit >> its new purpose: it's just a hub to the dedicated page of each series, and >> as such its content should be very clear and provide obvious links to the >> page for each series. I made do with what's available in our current CSS >> framework (it's Bootstrap 2, which is very old), but I have good hope that >> we could improve on that one day (if we upgrade to Bootstrap 3/4). >> See for example http://staging.hibernate.org/ogm/releases/ >> The maven coordinates and download link for the latest releases has moved >> to the series-specific page. It is configurable for each project: one can >> specify in the series.yml file which artifacts should be displayed, and add >> a summary for each artifact. >> I decided against the XML format and simply displayed the GAV as >> groupId:artifactId:version. Two reasons: >> 1. The XML format is really, really verbose, and the pages are long >> enough as they are (one already needs to scroll one screen down to see the >> "What's new" section). >> 2. I can't create a single syntax-highlighted block from the content of >> YAML files (if I switch to the AsciiDoc format, I don't have access to the >> loop features of HAML, and if I stick to HAML I don't have access to >> AsciiDoc syntax highlighting). >> Yes, we could probably solve 2, given enough time. And yes, I suppose we >> could find better UI alternatives using tabs or whatever. But I've already >> spent way too much time on this. Could we just agree it's good enough and >> work on this later? >> See for example http://staging.hibernate.org/search/releases/5.8/#get_it >> As requested, I updated the "survival guide": >> http://staging.hibernate.org/survival-guide/ >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 18 September 2017 at 10:44, Sanne Grinovero >> wrote: >>> >>> On 14 September 2017 at 13:34, Steve Ebersole >>> wrote: >>> > Yoann, >>> > >>> > First thanks for the work on this. I think it looks worlds better. A >>> > few >>> > minor things: >>> > >>> > Not sure of the source for this, but can we fix these doc link for 5.2 >>> > from >>> > >>> > `https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html` >>> > to `https://docs.jboss.org/hibernate/orm/5.2`? Also, why https? Not >>> > sure >>> > it matters, just found it odd >>> >>> Specifically about the `https` question: there's no longer any reason >>> standing to avoid https, other than it being slightly more work to >>> setup - in this case it's done by the jboss.org team so we can take >>> advantage from it at no extra effort. >>> >>> There are several benefits in using it from the SEO perspective though >>> so we should use and encourage it whenever possible, to make these >>> URLs the canonical ones for the documentation. (and also because >>> otherwise bots (and people) need to be thaught that this content is >>> now available over https as well). >>> >>> Ideally we should set it up for our websites too. >>> >>> Thanks, >>> Sanne >>> >>> > Much of the information on that ORM releases page is, in turn, >>> > version/series specific. Any reason why those pieces of information >>> > are not >>> > part of the series? Either in the synopsis on the releases page or on >>> > the >>> > specific series page, or both. Specifically >>> > >>> > "Compatibility Matrix" - the fact that its a table based on series is a >>> > good >>> > indicator it is all series specific ;) >>> > "Maven Repository" - I'd personally prefer to have this as part of the >>> > series info >>> > >>> > I think the individual series pages are missing a key piece of >>> > information... the "synopsis" of that series. I guess partially this >>> > fits >>> > under "what's new" >>> > >>> > Other than these minor things I love it. Great job! >>> > >>> > P.S. another question is whether (and if so, how) to apply the same >>> > treatment to the Documentation info in terms of the nav links. >>> > >>> > On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere >>> > wrote: >>> >> >>> >> I polished the changes, applied them to all projects (ORM, OGM, >>> >> Validator, >>> >> Search), and sent a PR: >>> >> https://github.com/hibernate/hibernate.org/pull/126 >>> >> Could you guys review it? Mainly I'd need one person per project to >>> >> check >>> >> they agree with the changes, especially in their project's section. >>> >> Also, there's still a bit of work to do for each project, mainly >>> >> filling >>> >> in missing metadata (see the PR). >>> >> >>> >> Yoann Rodi?re >>> >> Hibernate NoORM Team >>> >> yoann at hibernate.org >>> >> >>> >> On 14 September 2017 at 10:38, Emmanuel Bernard >>> >> >>> >> wrote: >>> >>> >>> >>> On Wed 17-09-13 10:55, Sanne Grinovero wrote: >>> >>>> >>> >>>> On 13 September 2017 at 10:51, Yoann Rodiere >>> >>>> wrote: >>> >>>>>> >>> >>>>>> It's more the number of columns, what if you add more version, >>> >>>>>> should >>> >>>>>> I >>> >>>>>> scroll horizontally? Also releeases tend to be shown vertically >>> >>>>>> with >>> >>>>>> version in desc order. This model breaks a bit this habit. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> At least versions are in desc order :D >>> >>>>> More seriously, I was more worried about the number of dependencies >>> >>>>> than >>> >>>>> about the number of series. We don't want to maintain a hundred >>> >>>>> branches, so >>> >>>>> we'll probably try to keep the number of series to a minimum, but >>> >>>>> we do >>> >>>>> want >>> >>>>> to offer as much as possible to users, so we may offer many >>> >>>>> different >>> >>>>> integrations, and thus many different dependencies. Just think if >>> >>>>> the >>> >>>>> ORM >>> >>>>> team wants to display supported versions of each DBMS... So I >>> >>>>> thought >>> >>>>> showing versions horizontally would be more future-proof. >>> >>>>> I'll try to add horizontal scrolling to the table. The oldest >>> >>>>> releases >>> >>>>> may >>> >>>>> not be displayed, but then those are not the one we want to >>> >>>>> advertise, >>> >>>>> so... >>> >>>>> And in any case, we have limited horizontal space, so we have to >>> >>>>> hide >>> >>>>> *something*. >>> >>>>> About phones, I think bootstrap has something, I'll give it a try. >>> >>>>> >>> >>>>>> On "Downloads" we only want to promote the active branches; have >>> >>>>>> some >>> >>>>>> basic series descriptions but way more ecclectic than the releases >>> >>>>>> descriptions. We make them cross-linked and everyone is happy? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Sure, we can do that. But the "downloads" page will essentially be >>> >>>>> a >>> >>>>> stripped-down version of the "releases" page. >>> >>>> >>> >>>> >>> >>>> +1 since maintenance is automated I see no problem with a little >>> >>>> redundancy. >>> >>> >>> >>> >>> >>> I'm not sure two pages is really solving the problem. It looks like >>> >>> you >>> >>> don't want to make a choice. But I don't have a pro/con opinion. >>> >>> My real concern is since you will have two pages, what's the >>> >>> navigation >>> >>> logic? How do you reach each on of these pages? >>> >>> >>> >>> Just thinking out loud here but I think the one way to solve long >>> >>> standing Steve objective is indeed to have per series sections of the >>> >>> website (including download, documentation, migration guide) >>> >>> And a top nav for "latest/promoted" releases (like we have today >>> >>> really). >>> >>> How do you merge the two navigation wise is what I don't know. >>> >>> This is for later work anyways. >>> >> >>> >> >>> > >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > From rory.odonnell at oracle.com Thu Sep 21 16:48:04 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 21 Sep 2017 21:48:04 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 9 Message-ID: Hi Sanne, Three items to share with you today * *JDK 9 General Availability * o GPL'd binaries from Oracle are available here: + http://jdk.java.net/9 o See Mark Reinhold's email for more details on the Release [1] + delivery of Project Jigsaw [2] * Are you JDK 9 Ready ? o The Quality Outreach wiki has been updated to include a JDK 9 Ready column. o If you would like us to identify your project as JDK 9 ready , please let me know and I will add it to the wiki. * Quality Outreach Report for September 2017**is available o many thanks for your continued support and welcome to the new projects! Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html [2] https://mreinhold.org/blog/jigsaw-complete -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Thu Sep 21 18:53:14 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 21 Sep 2017 23:53:14 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 9 In-Reply-To: References: Message-ID: Hi Rory, congratulations all with the release! Yes please flag our projects as "JDK9 ready". We still have some unresolved pain points with some tools we use to automate all builds, but these issues won't affect our users. All functional tests are working fine for all Hibernate projects! https://twitter.com/SanneGrinovero/status/910914942408232967 Thanks, Sanne On 21 September 2017 at 21:48, Rory O'Donnell wrote: > Hi Sanne, > > Three items to share with you today > > * *JDK 9 General Availability > * > o GPL'd binaries from Oracle are available here: > + http://jdk.java.net/9 > o See Mark Reinhold's email for more details on the Release [1] > + delivery of Project Jigsaw [2] > > * Are you JDK 9 Ready ? > o The Quality Outreach wiki has been updated to include a JDK 9 > Ready column. > o If you would like us to identify your project as JDK 9 ready , > please let me know and I will add it to the wiki. > > * Quality Outreach Report for September 2017**is available > o many thanks for your continued support and welcome to the new > projects! > > Rgds,Rory > > [1] > http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html > [2] https://mreinhold.org/blog/jigsaw-complete > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Fri Sep 22 06:41:17 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 22 Sep 2017 11:41:17 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 9 In-Reply-To: References: Message-ID: <40f13cd5-ecc6-d49b-8060-7e6d83c84dc0@oracle.com> Hi Sanne, Wiki updated : https://wiki.openjdk.java.net/display/quality/Quality+Outreach Thanks,Rory On 21/09/2017 23:53, Sanne Grinovero wrote: > Hi Rory, > > congratulations all with the release! > > Yes please flag our projects as "JDK9 ready". We still have some > unresolved pain points with some tools we use to automate all builds, > but these issues won't affect our users. All functional tests are > working fine for all Hibernate projects! > > https://twitter.com/SanneGrinovero/status/910914942408232967 > > Thanks, > Sanne > > > On 21 September 2017 at 21:48, Rory O'Donnell wrote: >> Hi Sanne, >> >> Three items to share with you today >> >> * *JDK 9 General Availability >> * >> o GPL'd binaries from Oracle are available here: >> + http://jdk.java.net/9 >> o See Mark Reinhold's email for more details on the Release [1] >> + delivery of Project Jigsaw [2] >> >> * Are you JDK 9 Ready ? >> o The Quality Outreach wiki has been updated to include a JDK 9 >> Ready column. >> o If you would like us to identify your project as JDK 9 ready , >> please let me know and I will add it to the wiki. >> >> * Quality Outreach Report for September 2017**is available >> o many thanks for your continued support and welcome to the new >> projects! >> >> Rgds,Rory >> >> [1] >> http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html >> [2] https://mreinhold.org/blog/jigsaw-complete >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland From guillaume.smet at gmail.com Fri Sep 22 07:21:25 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 22 Sep 2017 13:21:25 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero wrote: > *IF* you are willing to improve a minor point: I didn't expect the > "Releases" menu to be expanded when not being in any of these > sections. > Let's keep that one for another time. > Related: I wouldn't highlight both the current release and the > "Releases" label, the shading looks odd and misaligned. > Yoann fixed it. Could we push that version to production and iterate after if required? It's a tad better than what we have now and I don't see a reason to delay it more. Emmanuel? -- Guillaume From sanne at hibernate.org Fri Sep 22 09:40:08 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Sep 2017 14:40:08 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 9 In-Reply-To: <40f13cd5-ecc6-d49b-8060-7e6d83c84dc0@oracle.com> References: <40f13cd5-ecc6-d49b-8060-7e6d83c84dc0@oracle.com> Message-ID: Thanks Muneer and Rory! It's looking great. -- Sanne On 22 September 2017 at 11:41, Rory O'Donnell wrote: > Hi Sanne, > > Wiki updated : > https://wiki.openjdk.java.net/display/quality/Quality+Outreach > > Thanks,Rory > > > > On 21/09/2017 23:53, Sanne Grinovero wrote: >> >> Hi Rory, >> >> congratulations all with the release! >> >> Yes please flag our projects as "JDK9 ready". We still have some >> unresolved pain points with some tools we use to automate all builds, >> but these issues won't affect our users. All functional tests are >> working fine for all Hibernate projects! >> >> https://twitter.com/SanneGrinovero/status/910914942408232967 >> >> Thanks, >> Sanne >> >> >> On 21 September 2017 at 21:48, Rory O'Donnell >> wrote: >>> >>> Hi Sanne, >>> >>> Three items to share with you today >>> >>> * *JDK 9 General Availability >>> * >>> o GPL'd binaries from Oracle are available here: >>> + http://jdk.java.net/9 >>> o See Mark Reinhold's email for more details on the Release [1] >>> + delivery of Project Jigsaw [2] >>> >>> * Are you JDK 9 Ready ? >>> o The Quality Outreach wiki has been updated to include a JDK 9 >>> Ready column. >>> o If you would like us to identify your project as JDK 9 ready , >>> please let me know and I will add it to the wiki. >>> >>> * Quality Outreach Report for September 2017**is available >>> o many thanks for your continued support and welcome to the new >>> projects! >>> >>> Rgds,Rory >>> >>> [1] >>> >>> http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html >>> [2] https://mreinhold.org/blog/jigsaw-complete >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin,Ireland > From thomas at reinhardt.com Fri Sep 22 10:34:37 2017 From: thomas at reinhardt.com (Thomas Reinhardt) Date: Fri, 22 Sep 2017 16:34:37 +0200 Subject: [hibernate-dev] Number of SQL statements Message-ID: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> Hello Hibernate Team, is there a good way to check in a junit test which number of sql statements are generated ? I want to tackle some of the lazy loading/class enhancement issues and those need good tests of course. Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate Criteria does not respect fetch mode, when alias is used). As this is related to the now deprecated Hibernate Criteria API is there any chance my fix gets accepted or should I spare my time? Thanks, Thomas From sanne at hibernate.org Fri Sep 22 10:49:05 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Sep 2017 15:49:05 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: After some chats and a night of sleep on this, I think we need to stop obsessing about guiding people into the choice among multiple minor versions: it's hard enough that they have to pick a project. We need to encourage people to use the latest versions and we need to send a clear, strong message about this, no middle ground fiddling with names and definitions We can give them a choice between using the latest stable vs the latest development, but beyond this we're giving too much choice. Yet I do believe we should make it "not-hard" for people looking for details of other recent versions; could we consider them all "archived" ? Some drop downs on key areas like the ones in ORM today would still be welcome to make it easy to find - but let's remove the version choice from the "primary navigation path". There are some exceptional cases coming to mind which would need some mitigation; for example the fact that OGM won't work with the latest Search and ORM releases! But there are better solutions than to pollute the website experience by making the matching versions too visible, for example bundle it with OGM, link to the right versions from the OGM pages, or have the modules eventually pull-in the required dependencies, etc... (technical details irrelevant in this context). Thanks, Sanne On 22 September 2017 at 12:21, Guillaume Smet wrote: > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero > wrote: >> >> *IF* you are willing to improve a minor point: I didn't expect the >> "Releases" menu to be expanded when not being in any of these >> sections. > > > Let's keep that one for another time. > >> >> Related: I wouldn't highlight both the current release and the >> "Releases" label, the shading looks odd and misaligned. > > > Yoann fixed it. > > Could we push that version to production and iterate after if required? > > It's a tad better than what we have now and I don't see a reason to delay it > more. > > Emmanuel? > > -- > Guillaume > From mihalcea.vlad at gmail.com Fri Sep 22 10:49:54 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 22 Sep 2017 17:49:54 +0300 Subject: [hibernate-dev] Number of SQL statements In-Reply-To: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> References: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> Message-ID: Hi, 1. To validate the number of SQL statements, use this SQL Statement count validator I explained in this article: https://vladmihalcea.com/2014/02/01/how-to-detect-the-n-plus-one-query-problem-during-testing/ 2. For Hibernate Criteria, I don't think you should bother since it will be removed in the future and the fix might not be backported to older versions. You could use the JPA Criteria instead. Vlad On Fri, Sep 22, 2017 at 5:34 PM, Thomas Reinhardt wrote: > > Hello Hibernate Team, > > is there a good way to check in a junit test which number of sql > statements are generated ? > I want to tackle some of the lazy loading/class enhancement issues and > those need good tests of course. > > Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate > Criteria does not respect fetch mode, when alias is used). As this is > related to the now deprecated Hibernate Criteria API is there any chance > my fix gets accepted or should I spare my time? > > > Thanks, > Thomas > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Fri Sep 22 10:55:27 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Sep 2017 15:55:27 +0100 Subject: [hibernate-dev] Number of SQL statements In-Reply-To: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> References: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> Message-ID: Hi Thomas, I can't answer your question - will leave that to the people working on Hibernate ORM - but let me share that I'd also love to see such a tool or an example for unit tests (integration tests) to assert that some specific piece of code won't be generating more than N database round trips. That would be extremely useful! Let me suggst to focus on the actual network round-trips though: looking at the number of statements being generated is misleading as Hibernate ORM is able to do many clever things with multiple statements; for example you might see many of them being logged but it could still be wrapping them all in a single batch, therefore not being a performance problem. Vlad could this be a feature of your Flexy Pool ? Would love to see such a feature as a JUnit Rule ... Thanks, Sanne On 22 September 2017 at 15:34, Thomas Reinhardt wrote: > > Hello Hibernate Team, > > is there a good way to check in a junit test which number of sql > statements are generated ? > I want to tackle some of the lazy loading/class enhancement issues and > those need good tests of course. > > Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate > Criteria does not respect fetch mode, when alias is used). As this is > related to the now deprecated Hibernate Criteria API is there any chance > my fix gets accepted or should I spare my time? > > > Thanks, > Thomas > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Fri Sep 22 11:03:35 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 22 Sep 2017 17:03:35 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Ok, this will never end... It was good to merge less than 24h ago and now you're arguing against the very point of this work: provide users with more information regarding each series, so that they know what's new. (see the first email by Emmanuel) Please make concrete, exhaustive proposals. From what I understand, your concerns could be addressed with only simple changes to the menu (hide older series, add an "archived series" entry), but I don't know what to think anymore. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 22 September 2017 at 16:49, Sanne Grinovero wrote: > After some chats and a night of sleep on this, I think we need to stop > obsessing about guiding people into the choice among multiple minor > versions: it's hard enough that they have to pick a project. > > We need to encourage people to use the latest versions and we need to > send a clear, strong message about this, no middle ground fiddling > with names and definitions > > We can give them a choice between using the latest stable vs the > latest development, but beyond this we're giving too much choice. > > Yet I do believe we should make it "not-hard" for people looking for > details of other recent versions; could we consider them all > "archived" ? Some drop downs on key areas like the ones in ORM today > would still be welcome to make it easy to find - but let's remove the > version choice from the "primary navigation path". > > There are some exceptional cases coming to mind which would need some > mitigation; for example the fact that OGM won't work with the latest > Search and ORM releases! > But there are better solutions than to pollute the website experience > by making the matching versions too visible, for example bundle it > with OGM, link to the right versions from the OGM pages, or have the > modules eventually pull-in the required dependencies, etc... > (technical details irrelevant in this context). > > Thanks, > Sanne > > > > > On 22 September 2017 at 12:21, Guillaume Smet > wrote: > > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero > > wrote: > >> > >> *IF* you are willing to improve a minor point: I didn't expect the > >> "Releases" menu to be expanded when not being in any of these > >> sections. > > > > > > Let's keep that one for another time. > > > >> > >> Related: I wouldn't highlight both the current release and the > >> "Releases" label, the shading looks odd and misaligned. > > > > > > Yoann fixed it. > > > > Could we push that version to production and iterate after if required? > > > > It's a tad better than what we have now and I don't see a reason to > delay it > > more. > > > > Emmanuel? > > > > -- > > Guillaume > > > From steve at hibernate.org Fri Sep 22 11:47:06 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Sep 2017 15:47:06 +0000 Subject: [hibernate-dev] Number of SQL statements In-Reply-To: References: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> Message-ID: For such assertions in the Hibernate test suite we generally rely on Hibernate Statistics. I also really like Vlad's solution. On Fri, Sep 22, 2017 at 10:19 AM Sanne Grinovero wrote: > Hi Thomas, > > I can't answer your question - will leave that to the people working > on Hibernate ORM - but let me share that I'd also love to see such a > tool or an example for unit tests (integration tests) to assert that > some specific piece of code won't be generating more than N database > round trips. That would be extremely useful! > > Let me suggst to focus on the actual network round-trips though: > looking at the number of statements being generated is misleading as > Hibernate ORM is able to do many clever things with multiple > statements; for example you might see many of them being logged but it > could still be wrapping them all in a single batch, therefore not > being a performance problem. > > Vlad could this be a feature of your Flexy Pool ? Would love to see > such a feature as a JUnit Rule ... > > Thanks, > Sanne > > On 22 September 2017 at 15:34, Thomas Reinhardt > wrote: > > > > Hello Hibernate Team, > > > > is there a good way to check in a junit test which number of sql > > statements are generated ? > > I want to tackle some of the lazy loading/class enhancement issues and > > those need good tests of course. > > > > Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate > > Criteria does not respect fetch mode, when alias is used). As this is > > related to the now deprecated Hibernate Criteria API is there any chance > > my fix gets accepted or should I spare my time? > > > > > > Thanks, > > Thomas > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Sep 22 12:00:13 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Sep 2017 16:00:13 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: I think he is saying what I was saying... make the nav links point to the latest version, but with easy nav from there to list of all series/family/whatever On Fri, Sep 22, 2017 at 10:25 AM Yoann Rodiere wrote: > Ok, this will never end... It was good to merge less than 24h ago and now > you're arguing against the very point of this work: provide users with more > information regarding each series, so that they know what's new. (see the > first email by Emmanuel) > > Please make concrete, exhaustive proposals. From what I understand, your > concerns could be addressed with only simple changes to the menu (hide > older series, add an "archived series" entry), but I don't know what to > think anymore. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 22 September 2017 at 16:49, Sanne Grinovero > wrote: > > > After some chats and a night of sleep on this, I think we need to stop > > obsessing about guiding people into the choice among multiple minor > > versions: it's hard enough that they have to pick a project. > > > > We need to encourage people to use the latest versions and we need to > > send a clear, strong message about this, no middle ground fiddling > > with names and definitions > > > > We can give them a choice between using the latest stable vs the > > latest development, but beyond this we're giving too much choice. > > > > Yet I do believe we should make it "not-hard" for people looking for > > details of other recent versions; could we consider them all > > "archived" ? Some drop downs on key areas like the ones in ORM today > > would still be welcome to make it easy to find - but let's remove the > > version choice from the "primary navigation path". > > > > There are some exceptional cases coming to mind which would need some > > mitigation; for example the fact that OGM won't work with the latest > > Search and ORM releases! > > But there are better solutions than to pollute the website experience > > by making the matching versions too visible, for example bundle it > > with OGM, link to the right versions from the OGM pages, or have the > > modules eventually pull-in the required dependencies, etc... > > (technical details irrelevant in this context). > > > > Thanks, > > Sanne > > > > > > > > > > On 22 September 2017 at 12:21, Guillaume Smet > > wrote: > > > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero > > > wrote: > > >> > > >> *IF* you are willing to improve a minor point: I didn't expect the > > >> "Releases" menu to be expanded when not being in any of these > > >> sections. > > > > > > > > > Let's keep that one for another time. > > > > > >> > > >> Related: I wouldn't highlight both the current release and the > > >> "Releases" label, the shading looks odd and misaligned. > > > > > > > > > Yoann fixed it. > > > > > > Could we push that version to production and iterate after if required? > > > > > > It's a tad better than what we have now and I don't see a reason to > > delay it > > > more. > > > > > > Emmanuel? > > > > > > -- > > > Guillaume > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Sep 22 12:04:24 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Sep 2017 16:04:24 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: And again I just wanted to say thanks, great job. It works much better I think, no matter these nit-picky things On Fri, Sep 22, 2017 at 11:00 AM Steve Ebersole wrote: > I think he is saying what I was saying... make the nav links point to the > latest version, but with easy nav from there to list of all > series/family/whatever > > > On Fri, Sep 22, 2017 at 10:25 AM Yoann Rodiere > wrote: > >> Ok, this will never end... It was good to merge less than 24h ago and now >> you're arguing against the very point of this work: provide users with >> more >> information regarding each series, so that they know what's new. (see the >> first email by Emmanuel) >> >> Please make concrete, exhaustive proposals. From what I understand, your >> concerns could be addressed with only simple changes to the menu (hide >> older series, add an "archived series" entry), but I don't know what to >> think anymore. >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 22 September 2017 at 16:49, Sanne Grinovero >> wrote: >> >> > After some chats and a night of sleep on this, I think we need to stop >> > obsessing about guiding people into the choice among multiple minor >> > versions: it's hard enough that they have to pick a project. >> > >> > We need to encourage people to use the latest versions and we need to >> > send a clear, strong message about this, no middle ground fiddling >> > with names and definitions >> > >> > We can give them a choice between using the latest stable vs the >> > latest development, but beyond this we're giving too much choice. >> > >> > Yet I do believe we should make it "not-hard" for people looking for >> > details of other recent versions; could we consider them all >> > "archived" ? Some drop downs on key areas like the ones in ORM today >> > would still be welcome to make it easy to find - but let's remove the >> > version choice from the "primary navigation path". >> > >> > There are some exceptional cases coming to mind which would need some >> > mitigation; for example the fact that OGM won't work with the latest >> > Search and ORM releases! >> > But there are better solutions than to pollute the website experience >> > by making the matching versions too visible, for example bundle it >> > with OGM, link to the right versions from the OGM pages, or have the >> > modules eventually pull-in the required dependencies, etc... >> > (technical details irrelevant in this context). >> > >> > Thanks, >> > Sanne >> > >> > >> > >> > >> > On 22 September 2017 at 12:21, Guillaume Smet > > >> > wrote: >> > > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero > > >> > > wrote: >> > >> >> > >> *IF* you are willing to improve a minor point: I didn't expect the >> > >> "Releases" menu to be expanded when not being in any of these >> > >> sections. >> > > >> > > >> > > Let's keep that one for another time. >> > > >> > >> >> > >> Related: I wouldn't highlight both the current release and the >> > >> "Releases" label, the shading looks odd and misaligned. >> > > >> > > >> > > Yoann fixed it. >> > > >> > > Could we push that version to production and iterate after if >> required? >> > > >> > > It's a tad better than what we have now and I don't see a reason to >> > delay it >> > > more. >> > > >> > > Emmanuel? >> > > >> > > -- >> > > Guillaume >> > > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From mihalcea.vlad at gmail.com Fri Sep 22 12:09:02 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 22 Sep 2017 19:09:02 +0300 Subject: [hibernate-dev] Number of SQL statements In-Reply-To: References: <2706372d-b94f-45c6-11bd-6a45e702f439@reinhardt.com> Message-ID: HI, We already have such tool for the Hibernate tests. The one that I suggested does not use FlexyPool, but datasource-proxy. Vlad On Fri, Sep 22, 2017 at 5:55 PM, Sanne Grinovero wrote: > Hi Thomas, > > I can't answer your question - will leave that to the people working > on Hibernate ORM - but let me share that I'd also love to see such a > tool or an example for unit tests (integration tests) to assert that > some specific piece of code won't be generating more than N database > round trips. That would be extremely useful! > > Let me suggst to focus on the actual network round-trips though: > looking at the number of statements being generated is misleading as > Hibernate ORM is able to do many clever things with multiple > statements; for example you might see many of them being logged but it > could still be wrapping them all in a single batch, therefore not > being a performance problem. > > Vlad could this be a feature of your Flexy Pool ? Would love to see > such a feature as a JUnit Rule ... > > Thanks, > Sanne > > On 22 September 2017 at 15:34, Thomas Reinhardt > wrote: > > > > Hello Hibernate Team, > > > > is there a good way to check in a junit test which number of sql > > statements are generated ? > > I want to tackle some of the lazy loading/class enhancement issues and > > those need good tests of course. > > > > Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate > > Criteria does not respect fetch mode, when alias is used). As this is > > related to the now deprecated Hibernate Criteria API is there any chance > > my fix gets accepted or should I spare my time? > > > > > > Thanks, > > Thomas > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Fri Sep 22 13:45:33 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 22 Sep 2017 19:45:33 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Hi Sanne, IMHO, this is an orthogonal discussion to the problem Yoann is trying to solve. Yoann didn't change anything about which versions are advertised. What I'm saying is that, if when we start a move, we have 4 other discussions about 4 other things we want to change, we won't do a move anymore. Just to show you your point will generate more discussion and is not as easy as it seems: I tend to agree that we present too many versions but I think we have to think carefully about what we want to do about that (you're already talking about the OGM exceptions, but we will also have a Search exception when ORM 6 will be released as it will require some time for us to port Search to 6). What I was saying yesterday is that I don't think keeping Search 5.7 has value as people shouldn't use that version - there's no good reason for it. I'm more torn about 5.6 as people might find it useful if they are stuck on ORM 5.1 for whatever reason (WildFly, difficulty to upgrade...). So this is not an easy debate and I don't think we should block Yoann's work for this. Note that It can be quite frustrating when you invested time in something and you can never merge what you did because over the time we include other subjects in the discussion. Let's be more agile about it. We agreed it was a good change, let's merge it and iterate from there. -- Guillaume On Fri, Sep 22, 2017 at 4:49 PM, Sanne Grinovero wrote: > After some chats and a night of sleep on this, I think we need to stop > obsessing about guiding people into the choice among multiple minor > versions: it's hard enough that they have to pick a project. > > We need to encourage people to use the latest versions and we need to > send a clear, strong message about this, no middle ground fiddling > with names and definitions > > We can give them a choice between using the latest stable vs the > latest development, but beyond this we're giving too much choice. > > Yet I do believe we should make it "not-hard" for people looking for > details of other recent versions; could we consider them all > "archived" ? Some drop downs on key areas like the ones in ORM today > would still be welcome to make it easy to find - but let's remove the > version choice from the "primary navigation path". > > There are some exceptional cases coming to mind which would need some > mitigation; for example the fact that OGM won't work with the latest > Search and ORM releases! > But there are better solutions than to pollute the website experience > by making the matching versions too visible, for example bundle it > with OGM, link to the right versions from the OGM pages, or have the > modules eventually pull-in the required dependencies, etc... > (technical details irrelevant in this context). > > Thanks, > Sanne > > > > > On 22 September 2017 at 12:21, Guillaume Smet > wrote: > > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero > > wrote: > >> > >> *IF* you are willing to improve a minor point: I didn't expect the > >> "Releases" menu to be expanded when not being in any of these > >> sections. > > > > > > Let's keep that one for another time. > > > >> > >> Related: I wouldn't highlight both the current release and the > >> "Releases" label, the shading looks odd and misaligned. > > > > > > Yoann fixed it. > > > > Could we push that version to production and iterate after if required? > > > > It's a tad better than what we have now and I don't see a reason to > delay it > > more. > > > > Emmanuel? > > > > -- > > Guillaume > > > From sanne at hibernate.org Fri Sep 22 17:59:59 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Sep 2017 22:59:59 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Sorry for the confusion, my comment was indeed orthogonal and actually meant to get us all somwhat on the same page, as I have the feeling we have been proposing conflicting design changes (both here and in chat) because there is no agreement on the intent. I took that as a sign that our strategy needed to get some quorum first, but it was meant to bring closure on this change to go live asap, and possibly reduce debate on future proposals. As a suggestion maybe next time we start with the intent. I had already given my blessing to merge this and haven't changed my mind (I'd say so explicitly!). This is great progress and I'm eager to see it merged. > Yoann didn't change anything about which versions are advertised. He did. What you're probably missing is that my comment was championing it: the main Search landing page highlights the link to the latest series (and description) rather than to a pointless sourceforce download. (Steve understood it) Also I'm essentially conceding you're right in shutting down Search 5.7 (in subsequent work!) but for consistency reasons, not least people would wonder why there's a gap, I'd move all versions except latest to some form of "archived versions" or "previous series", whatever, exactly like Steve suggested. Which doesn't mean hard thye are going to be hard to find, but nudging people into the latest because it's the only thing we recommend rather than giving them various choices. All "series" pages need to stay for this to work nicely, which implies we definitely need the "series landing pages" Yoann introduced; un-exploding the menu of the series would help in the future when we'll have more - and that's why I suggested the change but it can wait. I don't see the conflict with Yoann's work; if any it's an important milestone. Frankly I'm confused how my suggestion was interpreted as a no-go; possibly as I didn't reply directly to your question about going ahead? I didn't reply on that directly because you made it clear you were waiting on Emmanuel's go ahead, but sorry anyway for the ambiguous message :) Damn mailing lists are hard! Thanks again! Sanne On 22 September 2017 at 18:45, Guillaume Smet wrote: > Hi Sanne, > > IMHO, this is an orthogonal discussion to the problem Yoann is trying to > solve. > > Yoann didn't change anything about which versions are advertised. > > What I'm saying is that, if when we start a move, we have 4 other > discussions about 4 other things we want to change, we won't do a move > anymore. > > Just to show you your point will generate more discussion and is not as easy > as it seems: > > I tend to agree that we present too many versions but I think we have to > think carefully about what we want to do about that (you're already talking > about the OGM exceptions, but we will also have a Search exception when ORM > 6 will be released as it will require some time for us to port Search to 6). > > What I was saying yesterday is that I don't think keeping Search 5.7 has > value as people shouldn't use that version - there's no good reason for it. > I'm more torn about 5.6 as people might find it useful if they are stuck on > ORM 5.1 for whatever reason (WildFly, difficulty to upgrade...). > > So this is not an easy debate and I don't think we should block Yoann's work > for this. > > Note that It can be quite frustrating when you invested time in something > and you can never merge what you did because over the time we include other > subjects in the discussion. Let's be more agile about it. > > We agreed it was a good change, let's merge it and iterate from there. > > -- > Guillaume > > On Fri, Sep 22, 2017 at 4:49 PM, Sanne Grinovero > wrote: >> >> After some chats and a night of sleep on this, I think we need to stop >> obsessing about guiding people into the choice among multiple minor >> versions: it's hard enough that they have to pick a project. >> >> We need to encourage people to use the latest versions and we need to >> send a clear, strong message about this, no middle ground fiddling >> with names and definitions >> >> We can give them a choice between using the latest stable vs the >> latest development, but beyond this we're giving too much choice. >> >> Yet I do believe we should make it "not-hard" for people looking for >> details of other recent versions; could we consider them all >> "archived" ? Some drop downs on key areas like the ones in ORM today >> would still be welcome to make it easy to find - but let's remove the >> version choice from the "primary navigation path". >> >> There are some exceptional cases coming to mind which would need some >> mitigation; for example the fact that OGM won't work with the latest >> Search and ORM releases! >> But there are better solutions than to pollute the website experience >> by making the matching versions too visible, for example bundle it >> with OGM, link to the right versions from the OGM pages, or have the >> modules eventually pull-in the required dependencies, etc... >> (technical details irrelevant in this context). >> >> Thanks, >> Sanne >> >> >> >> >> On 22 September 2017 at 12:21, Guillaume Smet >> wrote: >> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero >> > wrote: >> >> >> >> *IF* you are willing to improve a minor point: I didn't expect the >> >> "Releases" menu to be expanded when not being in any of these >> >> sections. >> > >> > >> > Let's keep that one for another time. >> > >> >> >> >> Related: I wouldn't highlight both the current release and the >> >> "Releases" label, the shading looks odd and misaligned. >> > >> > >> > Yoann fixed it. >> > >> > Could we push that version to production and iterate after if required? >> > >> > It's a tad better than what we have now and I don't see a reason to >> > delay it >> > more. >> > >> > Emmanuel? >> > >> > -- >> > Guillaume >> > > > From sanne at hibernate.org Mon Sep 25 07:25:39 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Sep 2017 12:25:39 +0100 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces Message-ID: Our friend and colleague Andrew Dinn from the OpenJDK team is working on a series of blog posts to help people understand the impact of certain design choices on the cost of internal JVM metadata and native memory; this affects bootstrap costs of both the JVM and our libraries, overhead at runtime in terms of permanent memory waste, etc.. So as these blogs will be out soon I'm not going to dive into more details or how I discovered this, but as a draft reviewer I had the privilege to already play with the technique and send a PR to Hibernate Search as result of verifying some theories. In a nutshell Andrew's work allowed me to spot that having a Logger interface in module A extended by another Logger in module B is causing it to generate a significant amount of duplication of Class definition metadata: the generated loggers are quite verbose in terms of such costs and don't benefit from inheritance as one would expect: the cost of B is (A+B), if you ignore benefits from symbol de-duplication. In this specific example I could measure more than 200K of wasted space. That's not small for a single jar! Incidentally in this case it also bloats the jar file size. A code patch might be more clear to explain than emails; this is what I recommend we do in all projects: - https://github.com/hibernate/hibernate-search/pull/1546 N.B. the verbosity of the generated code is related with runtime performance so I don't think we'll to remove the generated Logger metadata, and certainly don't plan to switch logger implementations as there are many more aspects to take into account - yet we might have identified an anti-pattern which is multiplying this cost N times without a good reason and it's quite easy and under our control to avoid that. Thanks, Sanne From steve at hibernate.org Mon Sep 25 07:47:29 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 25 Sep 2017 11:47:29 +0000 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: I'm missing something. IIUC the discovery was that, e.g., having something like `BaseHibernateSearchLogger` in module-A and then something like `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes extra space to be taken up within the VM memory space. Yet this is still exactly what you do. What am I missing? Out of curiosity, is this specific to WildFly/Modules and how it handles Class loading? Or is this something in the JVM itself? Another thing I'd like to point out that I believe helps with performance in regards to loggers is what I have been doing in ORM which is to use just a single instance of named loggers, which you can see in the loggers in the `org.hibernate.internal.log` package : https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/internal/log On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero wrote: > Our friend and colleague Andrew Dinn from the OpenJDK team is working > on a series of blog posts to help people understand the impact of > certain design choices on the cost of internal JVM metadata and native > memory; this affects bootstrap costs of both the JVM and our > libraries, overhead at runtime in terms of permanent memory waste, > etc.. > > So as these blogs will be out soon I'm not going to dive into more > details or how I discovered this, but as a draft reviewer I had the > privilege to already play with the technique and send a PR to > Hibernate Search as result of verifying some theories. > > In a nutshell Andrew's work allowed me to spot that having a Logger > interface in module A extended by another Logger in module B is > causing it to generate a significant amount of duplication of Class > definition metadata: the generated loggers are quite verbose in terms > of such costs and don't benefit from inheritance as one would expect: > the cost of B is (A+B), if you ignore benefits from symbol > de-duplication. In this specific example I could measure more than > 200K of wasted space. That's not small for a single jar! Incidentally > in this case it also bloats the jar file size. > > A code patch might be more clear to explain than emails; this is what > I recommend we do in all projects: > - https://github.com/hibernate/hibernate-search/pull/1546 > > N.B. the verbosity of the generated code is related with runtime > performance so I don't think we'll to remove the generated Logger > metadata, and certainly don't plan to switch logger implementations as > there are many more aspects to take into account - yet we might have > identified an anti-pattern which is multiplying this cost N times > without a good reason and it's quite easy and under our control to > avoid that. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Mon Sep 25 08:09:11 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 25 Sep 2017 14:09:11 +0200 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: 2017-09-25 13:47 GMT+02:00 Steve Ebersole : > I'm missing something. IIUC the discovery was that, e.g., having something > like `BaseHibernateSearchLogger` in module-A and then something like > `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes > extra space to be taken up within the VM memory space. Yet this is still > exactly what you do. What am I missing? > Same question here. Also, does it only apply when inheriting from a base logger in another module or also when inheriting from a logger in the same module? I.e. is this issue related to cross-module boundaries or rather any kind of inheritance of logger types? > Out of curiosity, is this specific to WildFly/Modules and how it handles > Class loading? Or is this something in the JVM itself? > > Another thing I'd like to point out that I believe helps with performance > in regards to loggers is what I have been doing in ORM which is to use just > a single instance of named loggers, which you can see in the loggers in the > `org.hibernate.internal.log` package : > https://github.com/hibernate/hibernate-orm/tree/master/ > hibernate-core/src/main/java/org/hibernate/internal/log > > On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero > wrote: > > > Our friend and colleague Andrew Dinn from the OpenJDK team is working > > on a series of blog posts to help people understand the impact of > > certain design choices on the cost of internal JVM metadata and native > > memory; this affects bootstrap costs of both the JVM and our > > libraries, overhead at runtime in terms of permanent memory waste, > > etc.. > > > > So as these blogs will be out soon I'm not going to dive into more > > details or how I discovered this, but as a draft reviewer I had the > > privilege to already play with the technique and send a PR to > > Hibernate Search as result of verifying some theories. > > > > In a nutshell Andrew's work allowed me to spot that having a Logger > > interface in module A extended by another Logger in module B is > > causing it to generate a significant amount of duplication of Class > > definition metadata: the generated loggers are quite verbose in terms > > of such costs and don't benefit from inheritance as one would expect: > > the cost of B is (A+B), if you ignore benefits from symbol > > de-duplication. In this specific example I could measure more than > > 200K of wasted space. That's not small for a single jar! Incidentally > > in this case it also bloats the jar file size. > > > > A code patch might be more clear to explain than emails; this is what > > I recommend we do in all projects: > > - https://github.com/hibernate/hibernate-search/pull/1546 > > > > N.B. the verbosity of the generated code is related with runtime > > performance so I don't think we'll to remove the generated Logger > > metadata, and certainly don't plan to switch logger implementations as > > there are many more aspects to take into account - yet we might have > > identified an anti-pattern which is multiplying this cost N times > > without a good reason and it's quite easy and under our control to > > avoid that. > > > > Thanks, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Sep 25 08:11:40 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Sep 2017 13:11:40 +0100 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: On 25 September 2017 at 12:47, Steve Ebersole wrote: > I'm missing something. IIUC the discovery was that, e.g., having something > like `BaseHibernateSearchLogger` in module-A and then something like > `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes > extra space to be taken up within the VM memory space. Yet this is still > exactly what you do. What am I missing? Good point. The problem is not "to not extend anything" but to not extend another interface which also contains some hundreds of logging messages you're not actually needing. I introduced the `BaseHibernateSearchLogger` for it to contain the ones which I'd still want to share, at least for a little longer. In an ideal cleanup this interface would be empty. > > Out of curiosity, is this specific to WildFly/Modules and how it handles > Class loading? Or is this something in the JVM itself? The JVM itself: it affects all our users. It's interesting for WildFly too but mainly because a lot of libraries composing WildFly do similar stuff. > > Another thing I'd like to point out that I believe helps with performance in > regards to loggers is what I have been doing in ORM which is to use just a > single instance of named loggers, which you can see in the loggers in the > `org.hibernate.internal.log` package : > https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/internal/log I like that but especially in terms of user friendlyness. What makes you think it would affect performance? And thanks for teaching me about @ValidIdRange, I didn't know that one :) Thanks, Sanne > > On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero wrote: >> >> Our friend and colleague Andrew Dinn from the OpenJDK team is working >> on a series of blog posts to help people understand the impact of >> certain design choices on the cost of internal JVM metadata and native >> memory; this affects bootstrap costs of both the JVM and our >> libraries, overhead at runtime in terms of permanent memory waste, >> etc.. >> >> So as these blogs will be out soon I'm not going to dive into more >> details or how I discovered this, but as a draft reviewer I had the >> privilege to already play with the technique and send a PR to >> Hibernate Search as result of verifying some theories. >> >> In a nutshell Andrew's work allowed me to spot that having a Logger >> interface in module A extended by another Logger in module B is >> causing it to generate a significant amount of duplication of Class >> definition metadata: the generated loggers are quite verbose in terms >> of such costs and don't benefit from inheritance as one would expect: >> the cost of B is (A+B), if you ignore benefits from symbol >> de-duplication. In this specific example I could measure more than >> 200K of wasted space. That's not small for a single jar! Incidentally >> in this case it also bloats the jar file size. >> >> A code patch might be more clear to explain than emails; this is what >> I recommend we do in all projects: >> - https://github.com/hibernate/hibernate-search/pull/1546 >> >> N.B. the verbosity of the generated code is related with runtime >> performance so I don't think we'll to remove the generated Logger >> metadata, and certainly don't plan to switch logger implementations as >> there are many more aspects to take into account - yet we might have >> identified an anti-pattern which is multiplying this cost N times >> without a good reason and it's quite easy and under our control to >> avoid that. >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Sep 25 08:18:35 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Sep 2017 13:18:35 +0100 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: On 25 September 2017 at 13:09, Gunnar Morling wrote: > 2017-09-25 13:47 GMT+02:00 Steve Ebersole : >> >> I'm missing something. IIUC the discovery was that, e.g., having >> something >> like `BaseHibernateSearchLogger` in module-A and then something like >> `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes >> extra space to be taken up within the VM memory space. Yet this is still >> exactly what you do. What am I missing? > > > Same question here. > > Also, does it only apply when inheriting from a base logger in another > module or also when inheriting from a logger in the same module? I.e. is > this issue related to cross-module boundaries or rather any kind of > inheritance of logger types? It's just that the generated code looks at the actual definitions, not only the declared ones. Since it's a different interface you'll get a new copy of each logger definition; this might sound irrelevant but in this specific case gets quite large in terms of metadata, so it's worth keeping in mind when designing these inheritances. I'm not saying such inheritance needs to be avoided at all costs; just raising awareness of this effect. In the Hibernate Search case seems reasonable to clean it up - in other cases I guess but I'm not sure if it's worth it to take concrete action but I like us to be aware of the tradeoffs. Thanks, Sanne > >> >> Out of curiosity, is this specific to WildFly/Modules and how it handles >> Class loading? Or is this something in the JVM itself? >> >> Another thing I'd like to point out that I believe helps with performance >> in regards to loggers is what I have been doing in ORM which is to use >> just >> a single instance of named loggers, which you can see in the loggers in >> the >> `org.hibernate.internal.log` package : >> >> https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/internal/log >> >> On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero >> wrote: >> >> > Our friend and colleague Andrew Dinn from the OpenJDK team is working >> > on a series of blog posts to help people understand the impact of >> > certain design choices on the cost of internal JVM metadata and native >> > memory; this affects bootstrap costs of both the JVM and our >> > libraries, overhead at runtime in terms of permanent memory waste, >> > etc.. >> > >> > So as these blogs will be out soon I'm not going to dive into more >> > details or how I discovered this, but as a draft reviewer I had the >> > privilege to already play with the technique and send a PR to >> > Hibernate Search as result of verifying some theories. >> > >> > In a nutshell Andrew's work allowed me to spot that having a Logger >> > interface in module A extended by another Logger in module B is >> > causing it to generate a significant amount of duplication of Class >> > definition metadata: the generated loggers are quite verbose in terms >> > of such costs and don't benefit from inheritance as one would expect: >> > the cost of B is (A+B), if you ignore benefits from symbol >> > de-duplication. In this specific example I could measure more than >> > 200K of wasted space. That's not small for a single jar! Incidentally >> > in this case it also bloats the jar file size. >> > >> > A code patch might be more clear to explain than emails; this is what >> > I recommend we do in all projects: >> > - https://github.com/hibernate/hibernate-search/pull/1546 >> > >> > N.B. the verbosity of the generated code is related with runtime >> > performance so I don't think we'll to remove the generated Logger >> > metadata, and certainly don't plan to switch logger implementations as >> > there are many more aspects to take into account - yet we might have >> > identified an anti-pattern which is multiplying this cost N times >> > without a good reason and it's quite easy and under our control to >> > avoid that. >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From gunnar at hibernate.org Mon Sep 25 08:31:21 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 25 Sep 2017 14:31:21 +0200 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: My question would be why do you need the inheritance to begin with? You could just invoke the methods on the logger interface defining them. It'll require you to have two (or more) fields for the logger references, but then you'll get just a set of more related and coherent methods offered from each such logger, which may be better than mangling everything together into one interface. 2017-09-25 14:18 GMT+02:00 Sanne Grinovero : > On 25 September 2017 at 13:09, Gunnar Morling > wrote: > > 2017-09-25 13:47 GMT+02:00 Steve Ebersole : > >> > >> I'm missing something. IIUC the discovery was that, e.g., having > >> something > >> like `BaseHibernateSearchLogger` in module-A and then something like > >> `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes > >> extra space to be taken up within the VM memory space. Yet this is > still > >> exactly what you do. What am I missing? > > > > > > Same question here. > > > > Also, does it only apply when inheriting from a base logger in another > > module or also when inheriting from a logger in the same module? I.e. is > > this issue related to cross-module boundaries or rather any kind of > > inheritance of logger types? > > It's just that the generated code looks at the actual definitions, not > only the declared ones. > Since it's a different interface you'll get a new copy of each logger > definition; this might sound irrelevant but in this specific case gets > quite large in terms of metadata, so it's worth keeping in mind when > designing these inheritances. > > I'm not saying such inheritance needs to be avoided at all costs; just > raising awareness of this effect. In the Hibernate Search case seems > reasonable to clean it up - in other cases I guess but I'm not sure if > it's worth it to take concrete action but I like us to be aware of the > tradeoffs. > > Thanks, > Sanne > > > > >> > >> Out of curiosity, is this specific to WildFly/Modules and how it handles > >> Class loading? Or is this something in the JVM itself? > >> > >> Another thing I'd like to point out that I believe helps with > performance > >> in regards to loggers is what I have been doing in ORM which is to use > >> just > >> a single instance of named loggers, which you can see in the loggers in > >> the > >> `org.hibernate.internal.log` package : > >> > >> https://github.com/hibernate/hibernate-orm/tree/master/ > hibernate-core/src/main/java/org/hibernate/internal/log > >> > >> On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero > >> wrote: > >> > >> > Our friend and colleague Andrew Dinn from the OpenJDK team is working > >> > on a series of blog posts to help people understand the impact of > >> > certain design choices on the cost of internal JVM metadata and native > >> > memory; this affects bootstrap costs of both the JVM and our > >> > libraries, overhead at runtime in terms of permanent memory waste, > >> > etc.. > >> > > >> > So as these blogs will be out soon I'm not going to dive into more > >> > details or how I discovered this, but as a draft reviewer I had the > >> > privilege to already play with the technique and send a PR to > >> > Hibernate Search as result of verifying some theories. > >> > > >> > In a nutshell Andrew's work allowed me to spot that having a Logger > >> > interface in module A extended by another Logger in module B is > >> > causing it to generate a significant amount of duplication of Class > >> > definition metadata: the generated loggers are quite verbose in terms > >> > of such costs and don't benefit from inheritance as one would expect: > >> > the cost of B is (A+B), if you ignore benefits from symbol > >> > de-duplication. In this specific example I could measure more than > >> > 200K of wasted space. That's not small for a single jar! Incidentally > >> > in this case it also bloats the jar file size. > >> > > >> > A code patch might be more clear to explain than emails; this is what > >> > I recommend we do in all projects: > >> > - https://github.com/hibernate/hibernate-search/pull/1546 > >> > > >> > N.B. the verbosity of the generated code is related with runtime > >> > performance so I don't think we'll to remove the generated Logger > >> > metadata, and certainly don't plan to switch logger implementations as > >> > there are many more aspects to take into account - yet we might have > >> > identified an anti-pattern which is multiplying this cost N times > >> > without a good reason and it's quite easy and under our control to > >> > avoid that. > >> > > >> > Thanks, > >> > Sanne > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From steve at hibernate.org Mon Sep 25 09:37:52 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 25 Sep 2017 13:37:52 +0000 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: Generally speaking, generating one instance of something versus generating N is better. It has the potential to affect performance in regards to memory consumption in relation to the size of N On Mon, Sep 25, 2017 at 7:12 AM Sanne Grinovero wrote: > On 25 September 2017 at 12:47, Steve Ebersole wrote: > > I'm missing something. IIUC the discovery was that, e.g., having > something > > like `BaseHibernateSearchLogger` in module-A and then something like > > `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes > > extra space to be taken up within the VM memory space. Yet this is still > > exactly what you do. What am I missing? > > Good point. The problem is not "to not extend anything" but to not > extend another interface which also contains some hundreds of logging > messages you're not actually needing. > > I introduced the `BaseHibernateSearchLogger` for it to contain the > ones which I'd still want to share, at least for a little longer. In > an ideal cleanup this interface would be empty. > > > > > Out of curiosity, is this specific to WildFly/Modules and how it handles > > Class loading? Or is this something in the JVM itself? > > The JVM itself: it affects all our users. > It's interesting for WildFly too but mainly because a lot of libraries > composing WildFly do similar stuff. > > > > > Another thing I'd like to point out that I believe helps with > performance in > > regards to loggers is what I have been doing in ORM which is to use just > a > > single instance of named loggers, which you can see in the loggers in the > > `org.hibernate.internal.log` package : > > > https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/internal/log > > I like that but especially in terms of user friendlyness. What makes > you think it would affect performance? > > And thanks for teaching me about @ValidIdRange, I didn't know that one :) > > Thanks, > Sanne > > > > > > On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero > wrote: > >> > >> Our friend and colleague Andrew Dinn from the OpenJDK team is working > >> on a series of blog posts to help people understand the impact of > >> certain design choices on the cost of internal JVM metadata and native > >> memory; this affects bootstrap costs of both the JVM and our > >> libraries, overhead at runtime in terms of permanent memory waste, > >> etc.. > >> > >> So as these blogs will be out soon I'm not going to dive into more > >> details or how I discovered this, but as a draft reviewer I had the > >> privilege to already play with the technique and send a PR to > >> Hibernate Search as result of verifying some theories. > >> > >> In a nutshell Andrew's work allowed me to spot that having a Logger > >> interface in module A extended by another Logger in module B is > >> causing it to generate a significant amount of duplication of Class > >> definition metadata: the generated loggers are quite verbose in terms > >> of such costs and don't benefit from inheritance as one would expect: > >> the cost of B is (A+B), if you ignore benefits from symbol > >> de-duplication. In this specific example I could measure more than > >> 200K of wasted space. That's not small for a single jar! Incidentally > >> in this case it also bloats the jar file size. > >> > >> A code patch might be more clear to explain than emails; this is what > >> I recommend we do in all projects: > >> - https://github.com/hibernate/hibernate-search/pull/1546 > >> > >> N.B. the verbosity of the generated code is related with runtime > >> performance so I don't think we'll to remove the generated Logger > >> metadata, and certainly don't plan to switch logger implementations as > >> there are many more aspects to take into account - yet we might have > >> identified an anti-pattern which is multiplying this cost N times > >> without a good reason and it's quite easy and under our control to > >> avoid that. > >> > >> Thanks, > >> Sanne > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Sep 25 10:21:23 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Sep 2017 15:21:23 +0100 Subject: [hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces In-Reply-To: References: Message-ID: On 25 September 2017 at 13:31, Gunnar Morling wrote: > > My question would be why do you need the inheritance to begin with? You could just invoke the methods on the logger interface defining them. It'll require you to have two (or more) fields for the logger references, but then you'll get just a set of more related and coherent methods offered from each such logger, which may be better than mangling everything together into one interface. +1 I'd surely recommend to avoid the inheritance to new codebases, I just had various other factors currently making me not like to totally remove the shared methods in a single step but I agree that's where we should be headed. In the grand scheme of things, I'm not going to disrupt error code stability (user friendlyness of people googling these codes) for the sake of 12 bytes so that can wait a bit, likely some of those methods won't even exist in the next major release. Thanks, Sanne > > > 2017-09-25 14:18 GMT+02:00 Sanne Grinovero : >> >> On 25 September 2017 at 13:09, Gunnar Morling wrote: >> > 2017-09-25 13:47 GMT+02:00 Steve Ebersole : >> >> >> >> I'm missing something. IIUC the discovery was that, e.g., having >> >> something >> >> like >> `BaseHibernateSearchLogger` in module-A and then something like >> >> `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes >> >> extra space to be taken up within the VM memory space. Yet this is still >> >> exactly what you do. What am I missing? >> > >> > >> > Same question here. >> > >> > Also, does it only apply when inheriting from a base logger in another >> > module or also when inheriting from a logger in the same module? I.e. is >> > this issue related to cross-module boundaries or rather any kind of >> > inheritance of logger types? >> >> It's just that the generated code looks at the actual definitions, not >> only the declared ones. >> Since it's a different interface you'll get a new copy of each logger >> definition; this might sound irrelevant but in this specific case gets >> quite large in terms of metadata, so it's worth keeping in mind when >> designing these inheritances. >> >> I'm not saying such inheritance needs to be avoided at all costs; just >> raising awareness of this effect. In the Hibernate Search case seems >> reasonable to clean it up - in other cases I guess but I'm not sure if >> it's worth it to take concrete action but I like us to be aware of the >> tradeoffs. >> >> Thanks, >> Sanne >> >> > >> >> >> >> Out of curiosity, is this specific to WildFly/Modules and how it handles >> >> Class loading? Or is this something in the JVM itself? >> >> >> >> Another thing I'd like to point out that I believe helps with performance >> >> in regards to loggers is what I have been doing in ORM which is to use >> >> just >> >> a single instance of named loggers, which you can see in the loggers in >> >> the >> >> `org.hibernate.internal.log` package : >> >> >> >> https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/internal/log >> >> >> >> On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero >> >> wrote: >> >> >> >> > Our friend and colleague Andrew Dinn from the OpenJDK team is working >> >> > on a series of blog posts to help people understand the impact of >> >> > certain design choices on the cost of internal JVM metadata and native >> >> > memory; this affects bootstrap costs of both the JVM and our >> >> > libraries, overhead at runtime in terms of permanent memory waste, >> >> > etc.. >> >> > >> >> > So as these blogs will be out soon I'm not going to dive into more >> >> > details or how I discovered this, but as a draft reviewer I had the >> >> > privilege to already play with the technique and send a PR to >> >> > Hibernate Search as result of verifying some theories. >> >> > >> >> > In a nutshell Andrew's work allowed me to spot that having a Logger >> >> > interface in module A extended by another Logger in module B is >> >> > causing it to generate a significant amount of duplication of Class >> >> > definition metadata: the generated loggers are quite verbose in terms >> >> > of such costs and don't benefit from inheritance as one would expect: >> >> > the cost of B is (A+B), if you ignore benefits from symbol >> >> > de-duplication. In this specific example I could measure more than >> >> > 200K of wasted space. That's not small for a single jar! Incidentally >> >> > in this case it also bloats the jar file size. >> >> > >> >> > A code patch might be more clear to explain than emails; this is what >> >> > I recommend we do in all projects: >> >> > - https://github.com/hibernate/hibernate-search/pull/1546 >> >> > >> >> > N.B. the verbosity of the generated code is related with runtime >> >> > performance so I don't think we'll to remove the generated Logger >> >> > metadata, and certainly don't plan to switch logger implementations as >> >> > there are many more aspects to take into account - yet we might have >> >> > identified an anti-pattern which is multiplying this cost N times >> >> > without a good reason and it's quite easy and under our control to >> >> > avoid that. >> >> > >> >> > Thanks, >> >> > Sanne >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > > > From guillaume.smet at gmail.com Tue Sep 26 07:19:49 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 26 Sep 2017 13:19:49 +0200 Subject: [hibernate-dev] New layout for the website Message-ID: Hi, Following Yoann's work and based on it, I tried to work on a new layout for the website. The idea was to make it more modern while not starting a full discussion about the content. I think we could benefit from making more iterative improvements. I know a few things bother some people to who I already presented this work, but this is what I would like to present as "my proposal for a new website". I tried to take into account the remarks I found consistent with my vision (which unfortunately prevents you to see my first ugly try at a new home page, blame Sanne for that :)). I didn't change the content (except for reorganizing a few links in the menu to put "Source code" before "Wiki" for instance). That's not the point of this exercise. I added a short baseline on each About page. They are just placeholders, better propositions very welcome! The hero text below coming from the old site can also probably be tweaked for the new layout. Generally I think some changes are due to the content but that's for another day and for another discussion. To play with it: http://new.hibernate.org/ with 54.174.65.136 new.hibernate.org in your /etc/hosts The branch on GitHub is "new-layout". I consider the conversion work completed, so if you see any issue, it's not normal, please report it. The only thing I have in mind for the near future is to improve the mobile experience but I think it can be kept as a second step. It's usable as of now, even if not perfect. -- Guillaume From christian.beikov at gmail.com Tue Sep 26 07:37:01 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 26 Sep 2017 13:37:01 +0200 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: I like it, good work! As you already noticed yourself, there are some problems on mobile devices like images overlapping text and the menus being expanded, but other than that it already looks fine! Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 26.09.2017 um 13:19 schrieb Guillaume Smet: > Hi, > > Following Yoann's work and based on it, I tried to work on a new layout for > the website. > > The idea was to make it more modern while not starting a full discussion > about the content. I think we could benefit from making more iterative > improvements. > > I know a few things bother some people to who I already presented this > work, but this is what I would like to present as "my proposal for a new > website". > > I tried to take into account the remarks I found consistent with my vision > (which unfortunately prevents you to see my first ugly try at a new home > page, blame Sanne for that :)). > > I didn't change the content (except for reorganizing a few links in the > menu to put "Source code" before "Wiki" for instance). That's not the point > of this exercise. > > I added a short baseline on each About page. They are just placeholders, > better propositions very welcome! > The hero text below coming from the old site can also probably be tweaked > for the new layout. > > Generally I think some changes are due to the content but that's for > another day and for another discussion. > > To play with it: > http://new.hibernate.org/ > with > 54.174.65.136 new.hibernate.org > in your /etc/hosts > > The branch on GitHub is "new-layout". > > I consider the conversion work completed, so if you see any issue, it's not > normal, please report it. > > The only thing I have in mind for the near future is to improve the mobile > experience but I think it can be kept as a second step. It's usable as of > now, even if not perfect. > From yoann at hibernate.org Tue Sep 26 09:10:07 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 26 Sep 2017 15:10:07 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Aaaand it's merged. I tried to clean up release YAML files as much as possible for every project, adding missing files as necessary. You may want to add some content to each project, most notably to the "what's new" section of each series, but also to the compatibility matrix of each series. I updated the survival guide with some information about the YAML files, and I'm available if you need help. Thanks for the feedback! Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 22 September 2017 at 23:59, Sanne Grinovero wrote: > Sorry for the confusion, my comment was indeed orthogonal and actually > meant to get us all somwhat on the same page, as I have the feeling we > have been proposing conflicting design changes (both here and in chat) > because there is no agreement on the intent. I took that as a sign > that our strategy needed to get some quorum first, but it was meant to > bring closure on this change to go live asap, and possibly reduce > debate on future proposals. > As a suggestion maybe next time we start with the intent. > > I had already given my blessing to merge this and haven't changed my > mind (I'd say so explicitly!). This is great progress and I'm eager to > see it merged. > > > Yoann didn't change anything about which versions are advertised. > > He did. What you're probably missing is that my comment was > championing it: the main Search landing page highlights the link to > the latest series (and description) rather than to a pointless > sourceforce download. (Steve understood it) > > Also I'm essentially conceding you're right in shutting down Search > 5.7 (in subsequent work!) but for consistency reasons, not least > people would wonder why there's a gap, I'd move all versions except > latest to some form of "archived versions" or "previous series", > whatever, exactly like Steve suggested. Which doesn't mean hard thye > are going to be hard to find, but nudging people into the latest > because it's the only thing we recommend rather than giving them > various choices. > All "series" pages need to stay for this to work nicely, which implies > we definitely need the "series landing pages" Yoann introduced; > un-exploding the menu of the series would help in the future when > we'll have more - and that's why I suggested the change but it can > wait. > > I don't see the conflict with Yoann's work; if any it's an important > milestone. Frankly I'm confused how my suggestion was interpreted as a > no-go; possibly as I didn't reply directly to your question about > going ahead? I didn't reply on that directly because you made it clear > you were waiting on Emmanuel's go ahead, but sorry anyway for the > ambiguous message :) Damn mailing lists are hard! > > Thanks again! > Sanne > > > On 22 September 2017 at 18:45, Guillaume Smet > wrote: > > Hi Sanne, > > > > IMHO, this is an orthogonal discussion to the problem Yoann is trying to > > solve. > > > > Yoann didn't change anything about which versions are advertised. > > > > What I'm saying is that, if when we start a move, we have 4 other > > discussions about 4 other things we want to change, we won't do a move > > anymore. > > > > Just to show you your point will generate more discussion and is not as > easy > > as it seems: > > > > I tend to agree that we present too many versions but I think we have to > > think carefully about what we want to do about that (you're already > talking > > about the OGM exceptions, but we will also have a Search exception when > ORM > > 6 will be released as it will require some time for us to port Search to > 6). > > > > What I was saying yesterday is that I don't think keeping Search 5.7 has > > value as people shouldn't use that version - there's no good reason for > it. > > I'm more torn about 5.6 as people might find it useful if they are stuck > on > > ORM 5.1 for whatever reason (WildFly, difficulty to upgrade...). > > > > So this is not an easy debate and I don't think we should block Yoann's > work > > for this. > > > > Note that It can be quite frustrating when you invested time in something > > and you can never merge what you did because over the time we include > other > > subjects in the discussion. Let's be more agile about it. > > > > We agreed it was a good change, let's merge it and iterate from there. > > > > -- > > Guillaume > > > > On Fri, Sep 22, 2017 at 4:49 PM, Sanne Grinovero > > wrote: > >> > >> After some chats and a night of sleep on this, I think we need to stop > >> obsessing about guiding people into the choice among multiple minor > >> versions: it's hard enough that they have to pick a project. > >> > >> We need to encourage people to use the latest versions and we need to > >> send a clear, strong message about this, no middle ground fiddling > >> with names and definitions > >> > >> We can give them a choice between using the latest stable vs the > >> latest development, but beyond this we're giving too much choice. > >> > >> Yet I do believe we should make it "not-hard" for people looking for > >> details of other recent versions; could we consider them all > >> "archived" ? Some drop downs on key areas like the ones in ORM today > >> would still be welcome to make it easy to find - but let's remove the > >> version choice from the "primary navigation path". > >> > >> There are some exceptional cases coming to mind which would need some > >> mitigation; for example the fact that OGM won't work with the latest > >> Search and ORM releases! > >> But there are better solutions than to pollute the website experience > >> by making the matching versions too visible, for example bundle it > >> with OGM, link to the right versions from the OGM pages, or have the > >> modules eventually pull-in the required dependencies, etc... > >> (technical details irrelevant in this context). > >> > >> Thanks, > >> Sanne > >> > >> > >> > >> > >> On 22 September 2017 at 12:21, Guillaume Smet > > >> wrote: > >> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero > > >> > wrote: > >> >> > >> >> *IF* you are willing to improve a minor point: I didn't expect the > >> >> "Releases" menu to be expanded when not being in any of these > >> >> sections. > >> > > >> > > >> > Let's keep that one for another time. > >> > > >> >> > >> >> Related: I wouldn't highlight both the current release and the > >> >> "Releases" label, the shading looks odd and misaligned. > >> > > >> > > >> > Yoann fixed it. > >> > > >> > Could we push that version to production and iterate after if > required? > >> > > >> > It's a tad better than what we have now and I don't see a reason to > >> > delay it > >> > more. > >> > > >> > Emmanuel? > >> > > >> > -- > >> > Guillaume > >> > > > > > > From sanne at hibernate.org Tue Sep 26 09:12:21 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 26 Sep 2017 14:12:21 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170911135440.GA2624@hibernate.org> <20170913094101.GA12444@hibernate.org> <20170914083839.GB12444@hibernate.org> Message-ID: Thanks Yoann! Great work On 26 September 2017 at 14:10, Yoann Rodiere wrote: > Aaaand it's merged. > > I tried to clean up release YAML files as much as possible for every > project, adding missing files as necessary. > > You may want to add some content to each project, most notably to the > "what's new" section of each series, but also to the compatibility matrix of > each series. I updated the survival guide with some information about the > YAML files, and I'm available if you need help. > > Thanks for the feedback! > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 22 September 2017 at 23:59, Sanne Grinovero wrote: >> >> Sorry for the confusion, my comment was indeed orthogonal and actually >> meant to get us all somwhat on the same page, as I have the feeling we >> have been proposing conflicting design changes (both here and in chat) >> because there is no agreement on the intent. I took that as a sign >> that our strategy needed to get some quorum first, but it was meant to >> bring closure on this change to go live asap, and possibly reduce >> debate on future proposals. >> As a suggestion maybe next time we start with the intent. >> >> I had already given my blessing to merge this and haven't changed my >> mind (I'd say so explicitly!). This is great progress and I'm eager to >> see it merged. >> >> > Yoann didn't change anything about which versions are advertised. >> >> He did. What you're probably missing is that my comment was >> championing it: the main Search landing page highlights the link to >> the latest series (and description) rather than to a pointless >> sourceforce download. (Steve understood it) >> >> Also I'm essentially conceding you're right in shutting down Search >> 5.7 (in subsequent work!) but for consistency reasons, not least >> people would wonder why there's a gap, I'd move all versions except >> latest to some form of "archived versions" or "previous series", >> whatever, exactly like Steve suggested. Which doesn't mean hard thye >> are going to be hard to find, but nudging people into the latest >> because it's the only thing we recommend rather than giving them >> various choices. >> All "series" pages need to stay for this to work nicely, which implies >> we definitely need the "series landing pages" Yoann introduced; >> un-exploding the menu of the series would help in the future when >> we'll have more - and that's why I suggested the change but it can >> wait. >> >> I don't see the conflict with Yoann's work; if any it's an important >> milestone. Frankly I'm confused how my suggestion was interpreted as a >> no-go; possibly as I didn't reply directly to your question about >> going ahead? I didn't reply on that directly because you made it clear >> you were waiting on Emmanuel's go ahead, but sorry anyway for the >> ambiguous message :) Damn mailing lists are hard! >> >> Thanks again! >> Sanne >> >> >> On 22 September 2017 at 18:45, Guillaume Smet >> wrote: >> > Hi Sanne, >> > >> > IMHO, this is an orthogonal discussion to the problem Yoann is trying to >> > solve. >> > >> > Yoann didn't change anything about which versions are advertised. >> > >> > What I'm saying is that, if when we start a move, we have 4 other >> > discussions about 4 other things we want to change, we won't do a move >> > anymore. >> > >> > Just to show you your point will generate more discussion and is not as >> > easy >> > as it seems: >> > >> > I tend to agree that we present too many versions but I think we have to >> > think carefully about what we want to do about that (you're already >> > talking >> > about the OGM exceptions, but we will also have a Search exception when >> > ORM >> > 6 will be released as it will require some time for us to port Search to >> > 6). >> > >> > What I was saying yesterday is that I don't think keeping Search 5.7 has >> > value as people shouldn't use that version - there's no good reason for >> > it. >> > I'm more torn about 5.6 as people might find it useful if they are stuck >> > on >> > ORM 5.1 for whatever reason (WildFly, difficulty to upgrade...). >> > >> > So this is not an easy debate and I don't think we should block Yoann's >> > work >> > for this. >> > >> > Note that It can be quite frustrating when you invested time in >> > something >> > and you can never merge what you did because over the time we include >> > other >> > subjects in the discussion. Let's be more agile about it. >> > >> > We agreed it was a good change, let's merge it and iterate from there. >> > >> > -- >> > Guillaume >> > >> > On Fri, Sep 22, 2017 at 4:49 PM, Sanne Grinovero >> > wrote: >> >> >> >> After some chats and a night of sleep on this, I think we need to stop >> >> obsessing about guiding people into the choice among multiple minor >> >> versions: it's hard enough that they have to pick a project. >> >> >> >> We need to encourage people to use the latest versions and we need to >> >> send a clear, strong message about this, no middle ground fiddling >> >> with names and definitions >> >> >> >> We can give them a choice between using the latest stable vs the >> >> latest development, but beyond this we're giving too much choice. >> >> >> >> Yet I do believe we should make it "not-hard" for people looking for >> >> details of other recent versions; could we consider them all >> >> "archived" ? Some drop downs on key areas like the ones in ORM today >> >> would still be welcome to make it easy to find - but let's remove the >> >> version choice from the "primary navigation path". >> >> >> >> There are some exceptional cases coming to mind which would need some >> >> mitigation; for example the fact that OGM won't work with the latest >> >> Search and ORM releases! >> >> But there are better solutions than to pollute the website experience >> >> by making the matching versions too visible, for example bundle it >> >> with OGM, link to the right versions from the OGM pages, or have the >> >> modules eventually pull-in the required dependencies, etc... >> >> (technical details irrelevant in this context). >> >> >> >> Thanks, >> >> Sanne >> >> >> >> >> >> >> >> >> >> On 22 September 2017 at 12:21, Guillaume Smet >> >> >> >> wrote: >> >> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero >> >> > >> >> > wrote: >> >> >> >> >> >> *IF* you are willing to improve a minor point: I didn't expect the >> >> >> "Releases" menu to be expanded when not being in any of these >> >> >> sections. >> >> > >> >> > >> >> > Let's keep that one for another time. >> >> > >> >> >> >> >> >> Related: I wouldn't highlight both the current release and the >> >> >> "Releases" label, the shading looks odd and misaligned. >> >> > >> >> > >> >> > Yoann fixed it. >> >> > >> >> > Could we push that version to production and iterate after if >> >> > required? >> >> > >> >> > It's a tad better than what we have now and I don't see a reason to >> >> > delay it >> >> > more. >> >> > >> >> > Emmanuel? >> >> > >> >> > -- >> >> > Guillaume >> >> > >> > >> > > > From davide at hibernate.org Tue Sep 26 09:47:26 2017 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 26 Sep 2017 14:47:26 +0100 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: Overall it looks great and I think it can be merged as it is and wee can fix anything else later. The major thing that I don't think it is working is the use of the coloured background in some texts. I think this page highlights well the problem: http://new.hibernate.org/ogm/documentation/ There is a background behind the title, the subtitle, the release version and the "Documentation". The end result is that it's hard to understand what's a link or button and therefore can be clicked. I think it would work better without any background colour. I like the documentation page, I was surprised that we didn't use the same approach for the releases page. Thanks, Davide On Tue, Sep 26, 2017 at 12:37 PM, Christian Beikov wrote: > I like it, good work! > > As you already noticed yourself, there are some problems on mobile > devices like images overlapping text and the menus being expanded, but > other than that it already looks fine! > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 26.09.2017 um 13:19 schrieb Guillaume Smet: >> Hi, >> >> Following Yoann's work and based on it, I tried to work on a new layout for >> the website. >> >> The idea was to make it more modern while not starting a full discussion >> about the content. I think we could benefit from making more iterative >> improvements. >> >> I know a few things bother some people to who I already presented this >> work, but this is what I would like to present as "my proposal for a new >> website". >> >> I tried to take into account the remarks I found consistent with my vision >> (which unfortunately prevents you to see my first ugly try at a new home >> page, blame Sanne for that :)). >> >> I didn't change the content (except for reorganizing a few links in the >> menu to put "Source code" before "Wiki" for instance). That's not the point >> of this exercise. >> >> I added a short baseline on each About page. They are just placeholders, >> better propositions very welcome! >> The hero text below coming from the old site can also probably be tweaked >> for the new layout. >> >> Generally I think some changes are due to the content but that's for >> another day and for another discussion. >> >> To play with it: >> http://new.hibernate.org/ >> with >> 54.174.65.136 new.hibernate.org >> in your /etc/hosts >> >> The branch on GitHub is "new-layout". >> >> I consider the conversion work completed, so if you see any issue, it's not >> normal, please report it. >> >> The only thing I have in mind for the near future is to improve the mobile >> experience but I think it can be kept as a second step. It's usable as of >> now, even if not perfect. >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Sep 26 11:58:44 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 26 Sep 2017 17:58:44 +0200 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: I pushed some improvements for mobile. It now has a specific menu with all the elements in it. Easier to navigate and saves a lot of space. We can probably make some more improvements regarding the font size of the title and so on but I think it's good enough for now. -- Guillaume On Tue, Sep 26, 2017 at 1:37 PM, Christian Beikov < christian.beikov at gmail.com> wrote: > I like it, good work! > > As you already noticed yourself, there are some problems on mobile > devices like images overlapping text and the menus being expanded, but > other than that it already looks fine! > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 26.09.2017 um 13:19 schrieb Guillaume Smet: > > Hi, > > > > Following Yoann's work and based on it, I tried to work on a new layout > for > > the website. > > > > The idea was to make it more modern while not starting a full discussion > > about the content. I think we could benefit from making more iterative > > improvements. > > > > I know a few things bother some people to who I already presented this > > work, but this is what I would like to present as "my proposal for a new > > website". > > > > I tried to take into account the remarks I found consistent with my > vision > > (which unfortunately prevents you to see my first ugly try at a new home > > page, blame Sanne for that :)). > > > > I didn't change the content (except for reorganizing a few links in the > > menu to put "Source code" before "Wiki" for instance). That's not the > point > > of this exercise. > > > > I added a short baseline on each About page. They are just placeholders, > > better propositions very welcome! > > The hero text below coming from the old site can also probably be tweaked > > for the new layout. > > > > Generally I think some changes are due to the content but that's for > > another day and for another discussion. > > > > To play with it: > > http://new.hibernate.org/ > > with > > 54.174.65.136 new.hibernate.org > > in your /etc/hosts > > > > The branch on GitHub is "new-layout". > > > > I consider the conversion work completed, so if you see any issue, it's > not > > normal, please report it. > > > > The only thing I have in mind for the near future is to improve the > mobile > > experience but I think it can be kept as a second step. It's usable as of > > now, even if not perfect. > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Sep 26 12:08:03 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 26 Sep 2017 18:08:03 +0200 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: On Tue, Sep 26, 2017 at 3:47 PM, Davide D'Alto wrote: > There is a background behind the title, the subtitle, the release > version and the "Documentation". > The end result is that it's hard to understand what's a link or button > and therefore can be clicked. > > I think it would work better without any background colour. > Yes, as you know, I disagree. I think it makes the website more colourful and the header less empty. I think the buttons have a proper style you can't really mix with a simple background. As for the documentation page, I must agree there is maybe a bit too much of background in the content of the page but it's really not easy to make it look appealing. Note that I just pushed a commit to make the buttons look consistent everywhere with the icon at the right so that they are more easily recognizable. I hope it helps a bit. > I like the documentation page, I was surprised that we didn't use the > same approach for the releases page. > We might discuss that later. For now, it's basically the same pages Yoann pushed this morning, just a bit more colourful. -- Guillaume From sanne at hibernate.org Tue Sep 26 16:03:17 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 26 Sep 2017 21:03:17 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? Message-ID: This property is defined in hibernate-ogm-core and while it's quite self-explanatory with other NoSQL stores, it doesn't translate nicely to the Infinispan scenario. I'd be tempted to introduce ad-hoc properties for each Dialect so that their effect is clear, allowing to pick more fitting names. We also like to keep configuration properties to the minimun. In fact I'd like to simply use Environment.HBM2DDL_AUTO to create / define Caches ? Conceptually in Infinispan they are closer to "tables" than "databases", except they are all schema less and we deploy a schema using a different operation.. Let the fight begin! Thanks, Sanne From guillaume.smet at gmail.com Wed Sep 27 04:55:14 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 27 Sep 2017 10:55:14 +0200 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero wrote: > In fact > I'd like to simply use Environment.HBM2DDL_AUTO to create / define > Caches ? > Makes sense to me. -- Guillaume From davide at hibernate.org Wed Sep 27 05:23:11 2017 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 27 Sep 2017 10:23:11 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: > Let the fight begin! I don't think we have to fight about it: https://hibernate.atlassian.net/browse/OGM-571 It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced the property, it should be possible now. I'll have a look at it. It seems gunnar had a branch with something already done. Davide On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet wrote: > On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero > wrote: > >> In fact >> I'd like to simply use Environment.HBM2DDL_AUTO to create / define >> Caches ? >> > > Makes sense to me. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Sep 27 05:26:35 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Sep 2017 10:26:35 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: On 27 September 2017 at 10:23, Davide D'Alto wrote: >> Let the fight begin! > > I don't think we have to fight about it: > https://hibernate.atlassian.net/browse/OGM-571 > > It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced > the property, > it should be possible now. > > I'll have a look at it. It seems gunnar had a branch with something > already done. Thanks, but before you jump onto specifics of feasability, do we agree that "create_database" as a name is not good for Infinispan ? Sanne > > Davide > > On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet > wrote: >> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero >> wrote: >> >>> In fact >>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define >>> Caches ? >>> >> >> Makes sense to me. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Wed Sep 27 06:12:42 2017 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 27 Sep 2017 11:12:42 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: > Thanks, but before you jump onto specifics of feasability, do we agree > that "create_database" as a name is not good for Infinispan ? Well, we are using infinispan as a database, it's not an ideal name but it is not so terrible considering that we are trying to use a single property for all the dialects. I guess I didn't understand what you are proposing, the issue I linked is about: 1. Use HBM2DDL_AUTO for database and "table" creation 2. Remove create_database Isn't that what you asked initially? I'm inclined to have a distinct property for each dialect, the only thing that I don't like about it is that we will have several properties doing the same thing (basically, create what's missing). On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero wrote: > On 27 September 2017 at 10:23, Davide D'Alto wrote: >>> Let the fight begin! >> >> I don't think we have to fight about it: >> https://hibernate.atlassian.net/browse/OGM-571 >> >> It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced >> the property, >> it should be possible now. >> >> I'll have a look at it. It seems gunnar had a branch with something >> already done. > > Thanks, but before you jump onto specifics of feasability, do we agree > that "create_database" as a name is not good for Infinispan ? > > Sanne > >> >> Davide >> >> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet >> wrote: >>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero >>> wrote: >>> >>>> In fact >>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define >>>> Caches ? >>>> >>> >>> Makes sense to me. >>> >>> -- >>> Guillaume >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Sep 27 07:14:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Sep 2017 12:14:50 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: On 27 September 2017 at 11:12, Davide D'Alto wrote: >> Thanks, but before you jump onto specifics of feasability, do we agree >> that "create_database" as a name is not good for Infinispan ? > > Well, we are using infinispan as a database, it's not an ideal name > but it is not so terrible considering > that we are trying to use a single property for all the dialects. You just served me with a great example. You write "using infinispan as a database" but then the property name is "create database" then obviously I'm not suggesting that users are fools and think we're going to "create an Infinispan" but you can see where this is heading: it's unclear what it is really creating and the terminology is too overloaded. "create database" is good for storage systems like MySQL as there's a SQL command which literally says "CREATE DATABASE {name};" to express a group of related tables. Apparently it works fine with MongoDB too, as "collections" are grouped in databases. Infinispan doesn't have the notion of related tables; we as OGM team are experimenting with different approaches in embedded mode: storing all entities in the same Infinispan Cache, among 3 specially configured Infinispan Caches (entities, relation tables, IDs) or have a "cache per table" strategy. Either way, there might be more Caches on the system and there's no isolation, so essentially it's a crossing-fingers strategy that we're not going to overwrite or otherwise mess with the content of other Infinispan Caches. The main point being that there's no "database" in the typical logical sense so - as a user - I'm confused on what this property will do in the Infinispan Hot Rod context. > I guess I didn't understand what you are proposing, the issue I linked is about: > > 1. Use HBM2DDL_AUTO for database and "table" creation > 2. Remove create_database > > Isn't that what you asked initially? Yes I'm proposing both 1. and 2. Just pointing out that I got no answer from you about "2." and I wouldn't want to do 1. if there's no agreement on both points. > I'm inclined to have a distinct property for each dialect, the only > thing that I don't like about it > is that we will have several properties doing the same thing > (basically, create what's missing). Right, that's my same doubt. My proposal would be to have both good names which clearly express what we're going to do in each Dialect, and also apply the DDL_AUTO option so that Quickstarts, demos and newcomers can get up and running without needing to know them all. This is why I proposed both points 1. and 2. in the same thread, as we want to make the properties clearer but ideally we don't want the require the users to know about all these properties for the most common use cases. Thanks! Sanne > > On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero wrote: >> On 27 September 2017 at 10:23, Davide D'Alto wrote: >>>> Let the fight begin! >>> >>> I don't think we have to fight about it: >>> https://hibernate.atlassian.net/browse/OGM-571 >>> >>> It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced >>> the property, >>> it should be possible now. >>> >>> I'll have a look at it. It seems gunnar had a branch with something >>> already done. >> >> Thanks, but before you jump onto specifics of feasability, do we agree >> that "create_database" as a name is not good for Infinispan ? >> >> Sanne >> >>> >>> Davide >>> >>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet >>> wrote: >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero >>>> wrote: >>>> >>>>> In fact >>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define >>>>> Caches ? >>>>> >>>> >>>> Makes sense to me. >>>> >>>> -- >>>> Guillaume >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Sep 27 08:08:37 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 27 Sep 2017 14:08:37 +0200 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: I'd suggest to * simply ignore "create database" for Infinispan (not all OGM-defined properties are supported for all stores) * implement support for HBM2DDL_AUTO to create tables (or caches etc.) *within* the chosen database (which will be ISPN's global namespace as there is no notion of databases there) I would not make database creation part of the HBM2DDL_AUTO implementation, since that's not the case on ORM either (AFAIK, one would specify some parameter to the connection URL for having the database created if needed). --Gunnar 2017-09-27 13:14 GMT+02:00 Sanne Grinovero : > On 27 September 2017 at 11:12, Davide D'Alto wrote: > >> Thanks, but before you jump onto specifics of feasability, do we agree > >> that "create_database" as a name is not good for Infinispan ? > > > > Well, we are using infinispan as a database, it's not an ideal name > > but it is not so terrible considering > > that we are trying to use a single property for all the dialects. > > You just served me with a great example. You write "using infinispan > as a database" but then the property name is "create database" then > obviously I'm not suggesting that users are fools and think we're > going to "create an Infinispan" but you can see where this is heading: > it's unclear what it is really creating and the terminology is too > overloaded. > > "create database" is good for storage systems like MySQL as there's a > SQL command which literally says "CREATE DATABASE {name};" to express > a group of related tables. > > Apparently it works fine with MongoDB too, as "collections" are > grouped in databases. > > Infinispan doesn't have the notion of related tables; we as OGM team > are experimenting with different approaches in embedded mode: storing > all entities in the same Infinispan Cache, among 3 specially > configured Infinispan Caches (entities, relation tables, IDs) or have > a "cache per table" strategy. Either way, there might be more Caches > on the system and there's no isolation, so essentially it's a > crossing-fingers strategy that we're not going to overwrite or > otherwise mess with the content of other Infinispan Caches. > > The main point being that there's no "database" in the typical logical > sense so - as a user - I'm confused on what this property will do in > the Infinispan Hot Rod context. > > > I guess I didn't understand what you are proposing, the issue I linked > is about: > > > > 1. Use HBM2DDL_AUTO for database and "table" creation > > 2. Remove create_database > > > > Isn't that what you asked initially? > > Yes I'm proposing both 1. and 2. > Just pointing out that I got no answer from you about "2." and I > wouldn't want to do 1. if there's no agreement on both points. > > > I'm inclined to have a distinct property for each dialect, the only > > thing that I don't like about it > > is that we will have several properties doing the same thing > > (basically, create what's missing). > > Right, that's my same doubt. > My proposal would be to have both good names which clearly express > what we're going to do in each Dialect, and also apply the DDL_AUTO > option so that Quickstarts, demos and newcomers can get up and running > without needing to know them all. This is why I proposed both points > 1. and 2. in the same thread, as we want to make the properties > clearer but ideally we don't want the require the users to know about > all these properties for the most common use cases. > > Thanks! > > Sanne > > > > > > On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero > wrote: > >> On 27 September 2017 at 10:23, Davide D'Alto > wrote: > >>>> Let the fight begin! > >>> > >>> I don't think we have to fight about it: > >>> https://hibernate.atlassian.net/browse/OGM-571 > >>> > >>> It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced > >>> the property, > >>> it should be possible now. > >>> > >>> I'll have a look at it. It seems gunnar had a branch with something > >>> already done. > >> > >> Thanks, but before you jump onto specifics of feasability, do we agree > >> that "create_database" as a name is not good for Infinispan ? > >> > >> Sanne > >> > >>> > >>> Davide > >>> > >>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet > >>> wrote: > >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero < > sanne at hibernate.org> > >>>> wrote: > >>>> > >>>>> In fact > >>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define > >>>>> Caches ? > >>>>> > >>>> > >>>> Makes sense to me. > >>>> > >>>> -- > >>>> Guillaume > >>>> _______________________________________________ > >>>> hibernate-dev mailing list > >>>> hibernate-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Sep 27 08:19:11 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Sep 2017 13:19:11 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: Thanks Gunnar, at an high level that's pretty much on the same page than everyone else, but some details are relevant: On 27 September 2017 at 13:08, Gunnar Morling wrote: > I'd suggest to > > * simply ignore "create database" for Infinispan (not all OGM-defined > properties are supported for all stores) > * implement support for HBM2DDL_AUTO to create tables (or caches etc.) > *within* the chosen database (which will be ISPN's global namespace as there > is no notion of databases there) > > I would not make database creation part of the HBM2DDL_AUTO implementation, > since that's not the case on ORM either (AFAIK, one would specify some > parameter to the connection URL for having the database created if needed). I'm confused. You say we should create the "tables" but we should NOT create the "database" when this property is enabled. My previous email just explained that Infinispan has neither tables nor databases; we conceptually conflate both concepts into "Cache", were making a distinction is a grey area. So what are you suggesting we do? Thanks, Sanne > > --Gunnar > > 2017-09-27 13:14 GMT+02:00 Sanne Grinovero : >> >> On 27 September 2017 at 11:12, Davide D'Alto wrote: >> >> Thanks, but before you jump onto specifics of feasability, do we agree >> >> that "create_database" as a name is not good for Infinispan ? >> > >> > Well, we are using infinispan as a database, it's not an ideal name >> > but it is not so terrible considering >> > that we are trying to use a single property for all the dialects. >> >> You just served me with a great example. You write "using infinispan >> as a database" but then the property name is "create database" then >> obviously I'm not suggesting that users are fools and think we're >> going to "create an Infinispan" but you can see where this is heading: >> it's unclear what it is really creating and the terminology is too >> overloaded. >> >> "create database" is good for storage systems like MySQL as there's a >> SQL command which literally says "CREATE DATABASE {name};" to express >> a group of related tables. >> >> Apparently it works fine with MongoDB too, as "collections" are >> grouped in databases. >> >> Infinispan doesn't have the notion of related tables; we as OGM team >> are experimenting with different approaches in embedded mode: storing >> all entities in the same Infinispan Cache, among 3 specially >> configured Infinispan Caches (entities, relation tables, IDs) or have >> a "cache per table" strategy. Either way, there might be more Caches >> on the system and there's no isolation, so essentially it's a >> crossing-fingers strategy that we're not going to overwrite or >> otherwise mess with the content of other Infinispan Caches. >> >> The main point being that there's no "database" in the typical logical >> sense so - as a user - I'm confused on what this property will do in >> the Infinispan Hot Rod context. >> >> > I guess I didn't understand what you are proposing, the issue I linked >> > is about: >> > >> > 1. Use HBM2DDL_AUTO for database and "table" creation >> > 2. Remove create_database >> > >> > Isn't that what you asked initially? >> >> Yes I'm proposing both 1. and 2. >> Just pointing out that I got no answer from you about "2." and I >> wouldn't want to do 1. if there's no agreement on both points. >> >> > I'm inclined to have a distinct property for each dialect, the only >> > thing that I don't like about it >> > is that we will have several properties doing the same thing >> > (basically, create what's missing). >> >> Right, that's my same doubt. >> My proposal would be to have both good names which clearly express >> what we're going to do in each Dialect, and also apply the DDL_AUTO >> option so that Quickstarts, demos and newcomers can get up and running >> without needing to know them all. This is why I proposed both points >> 1. and 2. in the same thread, as we want to make the properties >> clearer but ideally we don't want the require the users to know about >> all these properties for the most common use cases. >> >> Thanks! >> >> Sanne >> >> >> > >> > On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero >> > wrote: >> >> On 27 September 2017 at 10:23, Davide D'Alto >> >> wrote: >> >>>> Let the fight begin! >> >>> >> >>> I don't think we have to fight about it: >> >>> https://hibernate.atlassian.net/browse/OGM-571 >> >>> >> >>> It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced >> >>> the property, >> >>> it should be possible now. >> >>> >> >>> I'll have a look at it. It seems gunnar had a branch with something >> >>> already done. >> >> >> >> Thanks, but before you jump onto specifics of feasability, do we agree >> >> that "create_database" as a name is not good for Infinispan ? >> >> >> >> Sanne >> >> >> >>> >> >>> Davide >> >>> >> >>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet >> >>> wrote: >> >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero >> >>>> >> >>>> wrote: >> >>>> >> >>>>> In fact >> >>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define >> >>>>> Caches ? >> >>>>> >> >>>> >> >>>> Makes sense to me. >> >>>> >> >>>> -- >> >>>> Guillaume >> >>>> _______________________________________________ >> >>>> hibernate-dev mailing list >> >>>> hibernate-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From gunnar at hibernate.org Wed Sep 27 08:29:40 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 27 Sep 2017 14:29:40 +0200 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: 2017-09-27 14:19 GMT+02:00 Sanne Grinovero : > Thanks Gunnar, at an high level that's pretty much on the same page > than everyone else, but some details are relevant: > > On 27 September 2017 at 13:08, Gunnar Morling > wrote: > > I'd suggest to > > > > * simply ignore "create database" for Infinispan (not all OGM-defined > > properties are supported for all stores) > > * implement support for HBM2DDL_AUTO to create tables (or caches etc.) > > *within* the chosen database (which will be ISPN's global namespace as > there > > is no notion of databases there) > > > > I would not make database creation part of the HBM2DDL_AUTO > implementation, > > since that's not the case on ORM either (AFAIK, one would specify some > > parameter to the connection URL for having the database created if > needed). > > I'm confused. You say we should create the "tables" but we should NOT > create the "database" when this property is enabled. > > My previous email just explained that Infinispan has neither tables > nor databases; we conceptually conflate both concepts into "Cache", > were making a distinction is a grey area. > So what are you suggesting we do? > In my picture of our usage, caches are ISPN's counterpart to tables in an RDBMS. Hence the proposal to control cache creation via HBM2DDL, akin to ORM's semantics of that option. AFAIU, thinking about database creation doesn't make sense for ISPN, as this concept just doesn't exist (or, one can think of it as exactly one "database" which always exists). Btw. > ... different approaches in embedded mode: storing all entities in the same Infinispan Cache That sounds kinda weird, isn't it like storing all entities in a single table in an RDMBS? It seems rather (space)-inefficient, as you always need to store the entity type as part of the key. With some distance, using one cache per entity (ignoring inheritance for a moment) seems like the most sensible mapping to me. > Thanks, > Sanne > > > > > > > --Gunnar > > > > 2017-09-27 13:14 GMT+02:00 Sanne Grinovero : > >> > >> On 27 September 2017 at 11:12, Davide D'Alto > wrote: > >> >> Thanks, but before you jump onto specifics of feasability, do we > agree > >> >> that "create_database" as a name is not good for Infinispan ? > >> > > >> > Well, we are using infinispan as a database, it's not an ideal name > >> > but it is not so terrible considering > >> > that we are trying to use a single property for all the dialects. > >> > >> You just served me with a great example. You write "using infinispan > >> as a database" but then the property name is "create database" then > >> obviously I'm not suggesting that users are fools and think we're > >> going to "create an Infinispan" but you can see where this is heading: > >> it's unclear what it is really creating and the terminology is too > >> overloaded. > >> > >> "create database" is good for storage systems like MySQL as there's a > >> SQL command which literally says "CREATE DATABASE {name};" to express > >> a group of related tables. > >> > >> Apparently it works fine with MongoDB too, as "collections" are > >> grouped in databases. > >> > >> Infinispan doesn't have the notion of related tables; we as OGM team > >> are experimenting with different approaches in embedded mode: storing > >> all entities in the same Infinispan Cache, among 3 specially > >> configured Infinispan Caches (entities, relation tables, IDs) or have > >> a "cache per table" strategy. Either way, there might be more Caches > >> on the system and there's no isolation, so essentially it's a > >> crossing-fingers strategy that we're not going to overwrite or > >> otherwise mess with the content of other Infinispan Caches. > >> > >> The main point being that there's no "database" in the typical logical > >> sense so - as a user - I'm confused on what this property will do in > >> the Infinispan Hot Rod context. > >> > >> > I guess I didn't understand what you are proposing, the issue I linked > >> > is about: > >> > > >> > 1. Use HBM2DDL_AUTO for database and "table" creation > >> > 2. Remove create_database > >> > > >> > Isn't that what you asked initially? > >> > >> Yes I'm proposing both 1. and 2. > >> Just pointing out that I got no answer from you about "2." and I > >> wouldn't want to do 1. if there's no agreement on both points. > >> > >> > I'm inclined to have a distinct property for each dialect, the only > >> > thing that I don't like about it > >> > is that we will have several properties doing the same thing > >> > (basically, create what's missing). > >> > >> Right, that's my same doubt. > >> My proposal would be to have both good names which clearly express > >> what we're going to do in each Dialect, and also apply the DDL_AUTO > >> option so that Quickstarts, demos and newcomers can get up and running > >> without needing to know them all. This is why I proposed both points > >> 1. and 2. in the same thread, as we want to make the properties > >> clearer but ideally we don't want the require the users to know about > >> all these properties for the most common use cases. > >> > >> Thanks! > >> > >> Sanne > >> > >> > >> > > >> > On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero < > sanne at hibernate.org> > >> > wrote: > >> >> On 27 September 2017 at 10:23, Davide D'Alto > >> >> wrote: > >> >>>> Let the fight begin! > >> >>> > >> >>> I don't think we have to fight about it: > >> >>> https://hibernate.atlassian.net/browse/OGM-571 > >> >>> > >> >>> It wasn't possible to use Environment.HBM2DDL_AUTO when we > introduced > >> >>> the property, > >> >>> it should be possible now. > >> >>> > >> >>> I'll have a look at it. It seems gunnar had a branch with something > >> >>> already done. > >> >> > >> >> Thanks, but before you jump onto specifics of feasability, do we > agree > >> >> that "create_database" as a name is not good for Infinispan ? > >> >> > >> >> Sanne > >> >> > >> >>> > >> >>> Davide > >> >>> > >> >>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet > >> >>> wrote: > >> >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero > >> >>>> > >> >>>> wrote: > >> >>>> > >> >>>>> In fact > >> >>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define > >> >>>>> Caches ? > >> >>>>> > >> >>>> > >> >>>> Makes sense to me. > >> >>>> > >> >>>> -- > >> >>>> Guillaume > >> >>>> _______________________________________________ > >> >>>> hibernate-dev mailing list > >> >>>> hibernate-dev at lists.jboss.org > >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From sanne at hibernate.org Wed Sep 27 08:55:53 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Sep 2017 13:55:53 +0100 Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose? In-Reply-To: References: Message-ID: On 27 September 2017 at 13:29, Gunnar Morling wrote: > > > 2017-09-27 14:19 GMT+02:00 Sanne Grinovero : >> >> Thanks Gunnar, at an high level that's pretty much on the same page >> than everyone else, but some details are relevant: >> >> On 27 September 2017 at 13:08, Gunnar Morling >> wrote: >> > I'd suggest to >> > >> > * simply ignore "create database" for Infinispan (not all OGM-defined >> > properties are supported for all stores) >> > * implement support for HBM2DDL_AUTO to create tables (or caches etc.) >> > *within* the chosen database (which will be ISPN's global namespace as >> > there >> > is no notion of databases there) >> > >> > I would not make database creation part of the HBM2DDL_AUTO >> > implementation, >> > since that's not the case on ORM either (AFAIK, one would specify some >> > parameter to the connection URL for having the database created if >> > needed). >> >> I'm confused. You say we should create the "tables" but we should NOT >> create the "database" when this property is enabled. >> >> My previous email just explained that Infinispan has neither tables >> nor databases; we conceptually conflate both concepts into "Cache", >> were making a distinction is a grey area. >> So what are you suggesting we do? > > > In my picture of our usage, caches are ISPN's counterpart to tables in an > RDBMS. Hence the proposal to control cache creation via HBM2DDL, akin to > ORM's semantics of that option. AFAIU, thinking about database creation > doesn't make sense for ISPN, as this concept just doesn't exist (or, one can > think of it as exactly one "database" which always exists). > > Btw. > >> ... different approaches in embedded mode: storing all entities in the >> same Infinispan Cache > > That sounds kinda weird, isn't it like storing all entities in a single > table in an RDMBS? It seems rather (space)-inefficient, as you always need > to store the entity type as part of the key. With some distance, using one > cache per entity (ignoring inheritance for a moment) seems like the most > sensible mapping to me. Yes this might sound weird if you look at them as tables, but that's just one way of looking at it. We can both agree that this is "sensible" but beyond our small team this is not knowledge that people will have when they start using OGM so I wouldn't assume the table-Cache match, especially not to explain further concepts. Also remember that in this case we're talking about "creating the table" as a "storage space". The schema and definitions of the table content types are actually managed separately in Infinispan.. I didn't want to bring this up as the thread is complex enough but it might help us to realize that we can't just consider all these concepts as one and swipe the differences under the carpet, as the user will need to understand some critical points, e.g. how to evolve the schema over time. But essentially looks we're on the same page about using HBM2DDL_AUTO and ignoring "create_database" for the sake of practical usage. Thanks for the brainstorming! Sanne > >> >> Thanks, >> Sanne >> >> >> >> > >> > --Gunnar >> > >> > 2017-09-27 13:14 GMT+02:00 Sanne Grinovero : >> >> >> >> On 27 September 2017 at 11:12, Davide D'Alto >> >> wrote: >> >> >> Thanks, but before you jump onto specifics of feasability, do we >> >> >> agree >> >> >> that "create_database" as a name is not good for Infinispan ? >> >> > >> >> > Well, we are using infinispan as a database, it's not an ideal name >> >> > but it is not so terrible considering >> >> > that we are trying to use a single property for all the dialects. >> >> >> >> You just served me with a great example. You write "using infinispan >> >> as a database" but then the property name is "create database" then >> >> obviously I'm not suggesting that users are fools and think we're >> >> going to "create an Infinispan" but you can see where this is heading: >> >> it's unclear what it is really creating and the terminology is too >> >> overloaded. >> >> >> >> "create database" is good for storage systems like MySQL as there's a >> >> SQL command which literally says "CREATE DATABASE {name};" to express >> >> a group of related tables. >> >> >> >> Apparently it works fine with MongoDB too, as "collections" are >> >> grouped in databases. >> >> >> >> Infinispan doesn't have the notion of related tables; we as OGM team >> >> are experimenting with different approaches in embedded mode: storing >> >> all entities in the same Infinispan Cache, among 3 specially >> >> configured Infinispan Caches (entities, relation tables, IDs) or have >> >> a "cache per table" strategy. Either way, there might be more Caches >> >> on the system and there's no isolation, so essentially it's a >> >> crossing-fingers strategy that we're not going to overwrite or >> >> otherwise mess with the content of other Infinispan Caches. >> >> >> >> The main point being that there's no "database" in the typical logical >> >> sense so - as a user - I'm confused on what this property will do in >> >> the Infinispan Hot Rod context. >> >> >> >> > I guess I didn't understand what you are proposing, the issue I >> >> > linked >> >> > is about: >> >> > >> >> > 1. Use HBM2DDL_AUTO for database and "table" creation >> >> > 2. Remove create_database >> >> > >> >> > Isn't that what you asked initially? >> >> >> >> Yes I'm proposing both 1. and 2. >> >> Just pointing out that I got no answer from you about "2." and I >> >> wouldn't want to do 1. if there's no agreement on both points. >> >> >> >> > I'm inclined to have a distinct property for each dialect, the only >> >> > thing that I don't like about it >> >> > is that we will have several properties doing the same thing >> >> > (basically, create what's missing). >> >> >> >> Right, that's my same doubt. >> >> My proposal would be to have both good names which clearly express >> >> what we're going to do in each Dialect, and also apply the DDL_AUTO >> >> option so that Quickstarts, demos and newcomers can get up and running >> >> without needing to know them all. This is why I proposed both points >> >> 1. and 2. in the same thread, as we want to make the properties >> >> clearer but ideally we don't want the require the users to know about >> >> all these properties for the most common use cases. >> >> >> >> Thanks! >> >> >> >> Sanne >> >> >> >> >> >> > >> >> > On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero >> >> > >> >> > wrote: >> >> >> On 27 September 2017 at 10:23, Davide D'Alto >> >> >> wrote: >> >> >>>> Let the fight begin! >> >> >>> >> >> >>> I don't think we have to fight about it: >> >> >>> https://hibernate.atlassian.net/browse/OGM-571 >> >> >>> >> >> >>> It wasn't possible to use Environment.HBM2DDL_AUTO when we >> >> >>> introduced >> >> >>> the property, >> >> >>> it should be possible now. >> >> >>> >> >> >>> I'll have a look at it. It seems gunnar had a branch with something >> >> >>> already done. >> >> >> >> >> >> Thanks, but before you jump onto specifics of feasability, do we >> >> >> agree >> >> >> that "create_database" as a name is not good for Infinispan ? >> >> >> >> >> >> Sanne >> >> >> >> >> >>> >> >> >>> Davide >> >> >>> >> >> >>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet >> >> >>> wrote: >> >> >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero >> >> >>>> >> >> >>>> wrote: >> >> >>>> >> >> >>>>> In fact >> >> >>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / >> >> >>>>> define >> >> >>>>> Caches ? >> >> >>>>> >> >> >>>> >> >> >>>> Makes sense to me. >> >> >>>> >> >> >>>> -- >> >> >>>> Guillaume >> >> >>>> _______________________________________________ >> >> >>>> hibernate-dev mailing list >> >> >>>> hibernate-dev at lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > > > From emmanuel at hibernate.org Tue Sep 26 10:36:01 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 26 Sep 2017 16:36:01 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> Message-ID: <20170926143601.GD70406@hibernate.org> All I wanted initially was to be able to get a description of what each series provided so that when I jump from my version to the latest, I can see what's going on. Then you guys wanted to expose the matrix of compatibilities as e.g. people do consume Search with a given version of ORM. With that being said, here is what I think are the series with value to users today: * Search: 5.8 (latest), 5.6 (ORM 5.0/5.1), maybe whatever the version in WF is * Validator: 6.0 (latest), maybe whatever the version in WF is * OGM: 5.2 (dev), 5.1 (stable) * ORM: 5.2, 5.1, maybe the WF version if it's not 5.1 As a user, I still need to be able to go to a given series page to understand what was done (see my initial use case). But they can be in a older series section in small vs big boxes. BTW tools has a Downloads link, not Releases. Emmanuel On Fri 17-09-22 17:03, Yoann Rodiere wrote: >Ok, this will never end... It was good to merge less than 24h ago and now >you're arguing against the very point of this work: provide users with more >information regarding each series, so that they know what's new. (see the >first email by Emmanuel) > >Please make concrete, exhaustive proposals. From what I understand, your >concerns could be addressed with only simple changes to the menu (hide >older series, add an "archived series" entry), but I don't know what to >think anymore. > > >Yoann Rodi?re >Hibernate NoORM Team >yoann at hibernate.org > >On 22 September 2017 at 16:49, Sanne Grinovero wrote: > >> After some chats and a night of sleep on this, I think we need to stop >> obsessing about guiding people into the choice among multiple minor >> versions: it's hard enough that they have to pick a project. >> >> We need to encourage people to use the latest versions and we need to >> send a clear, strong message about this, no middle ground fiddling >> with names and definitions >> >> We can give them a choice between using the latest stable vs the >> latest development, but beyond this we're giving too much choice. >> >> Yet I do believe we should make it "not-hard" for people looking for >> details of other recent versions; could we consider them all >> "archived" ? Some drop downs on key areas like the ones in ORM today >> would still be welcome to make it easy to find - but let's remove the >> version choice from the "primary navigation path". >> >> There are some exceptional cases coming to mind which would need some >> mitigation; for example the fact that OGM won't work with the latest >> Search and ORM releases! >> But there are better solutions than to pollute the website experience >> by making the matching versions too visible, for example bundle it >> with OGM, link to the right versions from the OGM pages, or have the >> modules eventually pull-in the required dependencies, etc... >> (technical details irrelevant in this context). >> >> Thanks, >> Sanne >> >> >> >> >> On 22 September 2017 at 12:21, Guillaume Smet >> wrote: >> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero >> > wrote: >> >> >> >> *IF* you are willing to improve a minor point: I didn't expect the >> >> "Releases" menu to be expanded when not being in any of these >> >> sections. >> > >> > >> > Let's keep that one for another time. >> > >> >> >> >> Related: I wouldn't highlight both the current release and the >> >> "Releases" label, the shading looks odd and misaligned. >> > >> > >> > Yoann fixed it. >> > >> > Could we push that version to production and iterate after if required? >> > >> > It's a tad better than what we have now and I don't see a reason to >> delay it >> > more. >> > >> > Emmanuel? >> > >> > -- >> > Guillaume >> > >> >_______________________________________________ >hibernate-dev mailing list >hibernate-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Sep 27 15:29:56 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 27 Sep 2017 21:29:56 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: <20170926143601.GD70406@hibernate.org> References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On Tue, Sep 26, 2017 at 4:36 PM, Emmanuel Bernard wrote: > As a user, I still need to be able to go to a given series page to > understand what was done (see my initial use case). But they can be in a > older series section in small vs big boxes. > This is currently missing. > BTW tools has a Downloads link, not Releases. Yes, Tools is different as it's just a link to the Downloads page. The Tools section of the site is basically links to external resources. -- Guillaume From sanne at hibernate.org Wed Sep 27 16:59:21 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Sep 2017 21:59:21 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: <20170926143601.GD70406@hibernate.org> References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On 26 September 2017 at 15:36, Emmanuel Bernard wrote: > All I wanted initially was to be able to get a description of what each > series provided so that when I jump from my version to the latest, I can > see what's going on. Then you guys wanted to expose the matrix of > compatibilities as e.g. people do consume Search with a given version of > ORM. > > With that being said, here is what I think are the series with value to > users today: > > * Search: 5.8 (latest), 5.6 (ORM 5.0/5.1), maybe whatever the version in > WF is > * Validator: 6.0 (latest), maybe whatever the version in WF is > * OGM: 5.2 (dev), 5.1 (stable) > * ORM: 5.2, 5.1, maybe the WF version if it's not 5.1 > > As a user, I still need to be able to go to a given series page to > understand what was done (see my initial use case). But they can be in a > older series section in small vs big boxes. +1 that's my preference Nothing to change right now, but we'll need to evolve a bit when we'll want to prune the series being shown in the main area right now. It starts to get crowded and WF having 5.5 (rather old) I want people to be able to find details about it yet not "push" the version. Say we want to prune 5.7 - not being in your above list - people will still want to be able to find it when upgrading from 5.6 -> 5.8 Thanks, Sanne > > BTW tools has a Downloads link, not Releases. > > Emmanuel > > > On Fri 17-09-22 17:03, Yoann Rodiere wrote: >> >> Ok, this will never end... It was good to merge less than 24h ago and now >> you're arguing against the very point of this work: provide users with >> more >> information regarding each series, so that they know what's new. (see the >> first email by Emmanuel) >> >> Please make concrete, exhaustive proposals. From what I understand, your >> concerns could be addressed with only simple changes to the menu (hide >> older series, add an "archived series" entry), but I don't know what to >> think anymore. >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 22 September 2017 at 16:49, Sanne Grinovero >> wrote: >> >>> After some chats and a night of sleep on this, I think we need to stop >>> obsessing about guiding people into the choice among multiple minor >>> versions: it's hard enough that they have to pick a project. >>> >>> We need to encourage people to use the latest versions and we need to >>> send a clear, strong message about this, no middle ground fiddling >>> with names and definitions >>> >>> We can give them a choice between using the latest stable vs the >>> latest development, but beyond this we're giving too much choice. >>> >>> Yet I do believe we should make it "not-hard" for people looking for >>> details of other recent versions; could we consider them all >>> "archived" ? Some drop downs on key areas like the ones in ORM today >>> would still be welcome to make it easy to find - but let's remove the >>> version choice from the "primary navigation path". >>> >>> There are some exceptional cases coming to mind which would need some >>> mitigation; for example the fact that OGM won't work with the latest >>> Search and ORM releases! >>> But there are better solutions than to pollute the website experience >>> by making the matching versions too visible, for example bundle it >>> with OGM, link to the right versions from the OGM pages, or have the >>> modules eventually pull-in the required dependencies, etc... >>> (technical details irrelevant in this context). >>> >>> Thanks, >>> Sanne >>> >>> >>> >>> >>> On 22 September 2017 at 12:21, Guillaume Smet >>> wrote: >>> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero >>> > wrote: >>> >> >>> >> *IF* you are willing to improve a minor point: I didn't expect the >>> >> "Releases" menu to be expanded when not being in any of these >>> >> sections. >>> > >>> > >>> > Let's keep that one for another time. >>> > >>> >> >>> >> Related: I wouldn't highlight both the current release and the >>> >> "Releases" label, the shading looks odd and misaligned. >>> > >>> > >>> > Yoann fixed it. >>> > >>> > Could we push that version to production and iterate after if required? >>> > >>> > It's a tad better than what we have now and I don't see a reason to >>> delay it >>> > more. >>> > >>> > Emmanuel? >>> > >>> > -- >>> > Guillaume >>> > >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From thomas at reinhardt.com Wed Sep 27 17:33:15 2017 From: thomas at reinhardt.com (Thomas Reinhardt) Date: Wed, 27 Sep 2017 23:33:15 +0200 Subject: [hibernate-dev] Too simple a solution for HHH-11147 ? Message-ID: <953660b1-5fea-21b8-62a4-4a486aa55084@reinhardt.com> Hello, I investigated HHH-11147 (Allow enhanced entities to be returned in a completely uninitialized state) and have a very small fix for that issue. I want your feedback if I am going the correct route here. Seems too easy and lazy loading is a pretty important piece of hibernate. To spare everyone opening the issue just to get an overview here is a short summary: The use case is an entity with a simple relation: @Entity @Proxy(lazy=true) class MyEntity { @ManyToOne(fetch=FetchType.LAZY) OtherEntity other; } Both entities are bytecode enhanced at compiletime with enableLazyInitialization=true. The problem is that the "other" entity is fetched despite being annotated as lazy. My quick fix is actually only two changed lines. A proper diff (HHH-11147-quick-and-dirty.diff) is attached to the issue. I did specifically not make a PR just for this discussion but if requested I can of course make one. A pseudo-diff can be found below. I did test this fix on our main application and it seems to work. There are two main questions: 1) could there be cases where we create a proxyFactory without need? 2) am I killing the benefits of the bytecode enhancement by using a proxy or do I still get things like association handling? Sorry for the wall of text but I thought this discussion does not belong in the issue itself. Correct me if I am wrong. Greetings, Thomas Pseudo-diff: org.hibernate.event.internal.DefaultLoadEventListener proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadType) { ... // this class has no proxies (so do a shortcut) - if ( !persister.hasProxy() ) { + if ( !persister.getEntityMetamodel().isLazy() ) { return load( event, persister, keyToLoad, options ); ... } org.hibernate.tuple.entity.AbstractEntityTuplizer public AbstractEntityTuplizer(...) { ... instantiator = buildInstantiator( entityMetamodel, mappingInfo ); - if ( entityMetamodel.isLazy() && - !entityMetamodel.getBytecodeEnhancementMetadata() - .isEnhancedForLazyLoading() ) { + if ( entityMetamodel.isLazy() ) { proxyFactory = buildProxyFactory( ... ); ... } From mihalcea.vlad at gmail.com Thu Sep 28 00:51:04 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 28 Sep 2017 07:51:04 +0300 Subject: [hibernate-dev] Too simple a solution for HHH-11147 ? In-Reply-To: <953660b1-5fea-21b8-62a4-4a486aa55084@reinhardt.com> References: <953660b1-5fea-21b8-62a4-4a486aa55084@reinhardt.com> Message-ID: Hi Thomas, You can send a Pull Request. I'll ask Luis Barreiro to review it since he's the expert in this area. Thanks, Vlad On Thu, Sep 28, 2017 at 12:33 AM, Thomas Reinhardt wrote: > > Hello, > > I investigated HHH-11147 (Allow enhanced entities to be returned in a > completely uninitialized state) and have a very small fix for that issue. > I want your feedback if I am going the correct route here. Seems too > easy and lazy loading is a pretty important piece of hibernate. > > To spare everyone opening the issue just to get an overview here is a > short summary: > > > > The use case is an entity with a simple relation: > > @Entity > @Proxy(lazy=true) > class MyEntity { > @ManyToOne(fetch=FetchType.LAZY) > OtherEntity other; > } > > Both entities are bytecode enhanced at compiletime with > enableLazyInitialization=true. The problem is that the "other" entity is > fetched despite being annotated as lazy. > > > > My quick fix is actually only two changed lines. A proper diff > (HHH-11147-quick-and-dirty.diff) is attached to the issue. I did > specifically not make a PR just for this discussion but if requested I > can of course make one. A pseudo-diff can be found below. > > I did test this fix on our main application and it seems to work. There > are two main questions: > 1) could there be cases where we create a proxyFactory without need? > 2) am I killing the benefits of the bytecode enhancement by using a > proxy or do I still get things like association handling? > > > Sorry for the wall of text but I thought this discussion does not belong > in the issue itself. Correct me if I am wrong. > > Greetings, > Thomas > > > > Pseudo-diff: > > org.hibernate.event.internal.DefaultLoadEventListener > proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadType) { > ... > // this class has no proxies (so do a shortcut) > - if ( !persister.hasProxy() ) { > + if ( !persister.getEntityMetamodel().isLazy() ) { > return load( event, persister, keyToLoad, options ); > ... > } > > > > org.hibernate.tuple.entity.AbstractEntityTuplizer > public AbstractEntityTuplizer(...) { > ... > instantiator = buildInstantiator( entityMetamodel, mappingInfo ); > - if ( entityMetamodel.isLazy() && > - !entityMetamodel.getBytecodeEnhancementMetadata() > - .isEnhancedForLazyLoading() ) { > + if ( entityMetamodel.isLazy() ) { > proxyFactory = buildProxyFactory( ... ); > ... > } > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Thu Sep 28 02:47:20 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 28 Sep 2017 08:47:20 +0200 Subject: [hibernate-dev] "Hibernate Types" project Message-ID: Hey Vlad, I recently learned about your "Hibernate Types" project [1]. It's great to see support for JSON, arrays, etc! Out of curiosity, though, why did you decide to make it a separate project instead of adding these very useful types to Hibernate itself? Seems it'd be easier for people to us them that way. Cheers, --Gunnar [1] https://vladmihalcea.com/2017/09/25/the-hibernate-types-open-source-project-is-born/ From yoann at hibernate.org Thu Sep 28 03:00:56 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 28 Sep 2017 09:00:56 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: > > > As a user, I still need to be able to go to a given series page to > understand what was done (see my initial use case). But they can be in a > > older series section in small vs big boxes. > This is currently missing. NO, it is not missing. At least, the concept is there. The "What's new" section has been here the whole time: http://staging. hibernate.org/search/releases/5.8/#whats_new, with a big-ass "What's new" link at the top of the series page. So, yes, it's quite empty for now. You need to add content to the page /yourproject/releases/yourseries/index.adoc. I added content for Search 5.8 only for now, and I'll find some time to do the same for other Search series. And yes, there's too much content in this section for Search 5.8, but that's mainly because there's too much content in 5.8 to begin with. But for other projects, surely each project's leader could take a bit of time to do that for his own project, or delegate? Some of us are even asking to remove that "What's new" section because it's too empty... Could we please all realize that content doesn't appear magically? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 27 September 2017 at 22:59, Sanne Grinovero wrote: > On 26 September 2017 at 15:36, Emmanuel Bernard > wrote: > > All I wanted initially was to be able to get a description of what each > > series provided so that when I jump from my version to the latest, I can > > see what's going on. Then you guys wanted to expose the matrix of > > compatibilities as e.g. people do consume Search with a given version of > > ORM. > > > > With that being said, here is what I think are the series with value to > > users today: > > > > * Search: 5.8 (latest), 5.6 (ORM 5.0/5.1), maybe whatever the version in > > WF is > > * Validator: 6.0 (latest), maybe whatever the version in WF is > > * OGM: 5.2 (dev), 5.1 (stable) > > * ORM: 5.2, 5.1, maybe the WF version if it's not 5.1 > > > > As a user, I still need to be able to go to a given series page to > > understand what was done (see my initial use case). But they can be in a > > older series section in small vs big boxes. > > +1 that's my preference > > Nothing to change right now, but we'll need to evolve a bit when we'll > want to prune the series being shown in the main area right now. > It starts to get crowded and WF having 5.5 (rather old) I want people > to be able to find details about it yet not "push" the version. > > Say we want to prune 5.7 - not being in your above list - people will > still want to be able to find it when upgrading from 5.6 -> 5.8 > > Thanks, > Sanne > > > > > BTW tools has a Downloads link, not Releases. > > > > Emmanuel > > > > > > On Fri 17-09-22 17:03, Yoann Rodiere wrote: > >> > >> Ok, this will never end... It was good to merge less than 24h ago and > now > >> you're arguing against the very point of this work: provide users with > >> more > >> information regarding each series, so that they know what's new. (see > the > >> first email by Emmanuel) > >> > >> Please make concrete, exhaustive proposals. From what I understand, your > >> concerns could be addressed with only simple changes to the menu (hide > >> older series, add an "archived series" entry), but I don't know what to > >> think anymore. > >> > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> yoann at hibernate.org > >> > >> On 22 September 2017 at 16:49, Sanne Grinovero > >> wrote: > >> > >>> After some chats and a night of sleep on this, I think we need to stop > >>> obsessing about guiding people into the choice among multiple minor > >>> versions: it's hard enough that they have to pick a project. > >>> > >>> We need to encourage people to use the latest versions and we need to > >>> send a clear, strong message about this, no middle ground fiddling > >>> with names and definitions > >>> > >>> We can give them a choice between using the latest stable vs the > >>> latest development, but beyond this we're giving too much choice. > >>> > >>> Yet I do believe we should make it "not-hard" for people looking for > >>> details of other recent versions; could we consider them all > >>> "archived" ? Some drop downs on key areas like the ones in ORM today > >>> would still be welcome to make it easy to find - but let's remove the > >>> version choice from the "primary navigation path". > >>> > >>> There are some exceptional cases coming to mind which would need some > >>> mitigation; for example the fact that OGM won't work with the latest > >>> Search and ORM releases! > >>> But there are better solutions than to pollute the website experience > >>> by making the matching versions too visible, for example bundle it > >>> with OGM, link to the right versions from the OGM pages, or have the > >>> modules eventually pull-in the required dependencies, etc... > >>> (technical details irrelevant in this context). > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> > >>> > >>> On 22 September 2017 at 12:21, Guillaume Smet < > guillaume.smet at gmail.com> > >>> wrote: > >>> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero < > sanne at hibernate.org> > >>> > wrote: > >>> >> > >>> >> *IF* you are willing to improve a minor point: I didn't expect the > >>> >> "Releases" menu to be expanded when not being in any of these > >>> >> sections. > >>> > > >>> > > >>> > Let's keep that one for another time. > >>> > > >>> >> > >>> >> Related: I wouldn't highlight both the current release and the > >>> >> "Releases" label, the shading looks odd and misaligned. > >>> > > >>> > > >>> > Yoann fixed it. > >>> > > >>> > Could we push that version to production and iterate after if > required? > >>> > > >>> > It's a tad better than what we have now and I don't see a reason to > >>> delay it > >>> > more. > >>> > > >>> > Emmanuel? > >>> > > >>> > -- > >>> > Guillaume > >>> > > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Thu Sep 28 03:17:03 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 28 Sep 2017 09:17:03 +0200 Subject: [hibernate-dev] [website] Specific series page Message-ID: Hello Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor proposals. In frequency, I think people go read the docs online much more than they want to know how to get it. So I would put the Documentation section at the top (or below the compatibility matrix if you won?t budge). In the natural flow of information discovery (I know it breaks my argument above), I would put the What?s new before the migration section. I know we have been going on and off over "Older releases?, what it is, is "Previous micro releases". So how about using that title. I imagine every one will understand. Emmanuel From emmanuel at hibernate.org Thu Sep 28 03:20:03 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 28 Sep 2017 09:20:03 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: <769C2EF0-2165-4035-8150-9D34D7C5B53E@hibernate.org> > On 28 Sep 2017, at 09:00, Yoann Rodiere wrote: > > And yes, there's too much content in this section for Search 5.8, but that's mainly because there's too much content in 5.8 to begin with. Ah, finally an objective measurement to force Sanne to release smaller but more often :D From emmanuel at hibernate.org Thu Sep 28 03:20:45 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 28 Sep 2017 09:20:45 +0200 Subject: [hibernate-dev] [website] Specific series page In-Reply-To: References: Message-ID: <9C5203FE-A207-4848-B867-11EED53C9D3D@hibernate.org> And I am +1 to push the new style today. These discussions are not linked. > On 28 Sep 2017, at 09:17, Emmanuel Bernard wrote: > > Hello > > Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor proposals. > > In frequency, I think people go read the docs online much more than they want to know how to get it. So I would put the Documentation section at the top (or below the compatibility matrix if you won?t budge). > > In the natural flow of information discovery (I know it breaks my argument above), I would put the What?s new before the migration section. > > I know we have been going on and off over "Older releases?, what it is, is "Previous micro releases". So how about using that title. I imagine every one will understand. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Sep 28 03:21:25 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 09:21:25 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On Thu, Sep 28, 2017 at 9:00 AM, Yoann Rodiere wrote: > > > > > As a user, I still need to be able to go to a given series page to > > > understand what was done (see my initial use case). But they can be in a > > > older series section in small vs big boxes. > > This is currently missing. > > > NO, it is not missing. At least, the concept is there. The "What's new" > section has been here the whole time: http://staging. > hibernate.org/search/releases/5.8/#whats_new, with a big-ass "What's new" > link at the top of the series page. > So, yes, it's quite empty for now. You need to add content to the page > /yourproject/releases/yourseries/index.adoc. I added content for Search > 5.8 > only for now, and I'll find some time to do the same for other Search > series. And yes, there's too much content in this section for Search 5.8, > but that's mainly because there's too much content in 5.8 to begin with. > But for other projects, surely each project's leader could take a bit of > time to do that for his own project, or delegate? Some of us are even > asking to remove that "What's new" section because it's too empty... Could > we please all realize that content doesn't appear magically? > I was talking about the ability to access the old series when they are not displayed in the overview. AFAICS, this is definitely missing and we would need either a page with all the series linked from the overview page or a button displaying the retired series. -- Guillaume From yoann at hibernate.org Thu Sep 28 03:43:53 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 28 Sep 2017 09:43:53 +0200 Subject: [hibernate-dev] [website] Specific series page In-Reply-To: References: <9C5203FE-A207-4848-B867-11EED53C9D3D@hibernate.org> Message-ID: So the order would be: * Compatibility * Documentation * How to get it * What's new * Migrate * Releases in this series (we just renamed it, I think it pretty much solves the issue we were having) Right? Seems ok to me, no strong opinion about that. As long as compatibility info stays at the top ;) Anyone against it? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 28 September 2017 at 09:42, Yoann Rodiere wrote: > So the order would be: > > * Compatibility > * Documentation > * How to get it > * What's new > * Migrate > * Releases in this series (we just renamed it, I think it pretty much > solves the issue we were having) > > Right? > > Seems ok to me, no strong opinion about that. As long as compatibility > info stays at the top ;) > > Anyone against it? > > > Yoann Rodi?re > Software Engineer, Hibernate NoORM Team > Red Hat > yrodiere at redhat.com > > On 28 September 2017 at 09:20, Emmanuel Bernard > wrote: > >> And I am +1 to push the new style today. These discussions are not linked. >> >> > On 28 Sep 2017, at 09:17, Emmanuel Bernard >> wrote: >> > >> > Hello >> > >> > Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor >> proposals. >> > >> > In frequency, I think people go read the docs online much more than >> they want to know how to get it. So I would put the Documentation section >> at the top (or below the compatibility matrix if you won?t budge). >> > >> > In the natural flow of information discovery (I know it breaks my >> argument above), I would put the What?s new before the migration section. >> > >> > I know we have been going on and off over "Older releases?, what it is, >> is "Previous micro releases". So how about using that title. I imagine >> every one will understand. >> > >> > Emmanuel >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Thu Sep 28 04:15:31 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 10:15:31 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi all, Better late that never, here are the minutes of this week's IRC meeting: 16:04 < jbott> Ending meeting. Generating minutes. Be patient :) 16:04 < jbott> Meeting ended Tue Sep 26 14:04:37 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:04 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-26-13.01.html 16:04 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-26-13.01.txt 16:04 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-26-13.01.log.html Have a nice day! -- Guillaume From guillaume.smet at gmail.com Thu Sep 28 05:13:40 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 11:13:40 +0200 Subject: [hibernate-dev] [website] Specific series page In-Reply-To: References: <9C5203FE-A207-4848-B867-11EED53C9D3D@hibernate.org> Message-ID: Looks OK to me! On Thu, Sep 28, 2017 at 9:43 AM, Yoann Rodiere wrote: > So the order would be: > > * Compatibility > * Documentation > * How to get it > * What's new > * Migrate > * Releases in this series (we just renamed it, I think it pretty much > solves the issue we were having) > > Right? > > Seems ok to me, no strong opinion about that. As long as compatibility info > stays at the top ;) > > Anyone against it? > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 28 September 2017 at 09:42, Yoann Rodiere wrote: > > > So the order would be: > > > > * Compatibility > > * Documentation > > * How to get it > > * What's new > > * Migrate > > * Releases in this series (we just renamed it, I think it pretty much > > solves the issue we were having) > > > > Right? > > > > Seems ok to me, no strong opinion about that. As long as compatibility > > info stays at the top ;) > > > > Anyone against it? > > > > > > Yoann Rodi?re > > Software Engineer, Hibernate NoORM Team > > Red Hat > > yrodiere at redhat.com > > > > On 28 September 2017 at 09:20, Emmanuel Bernard > > wrote: > > > >> And I am +1 to push the new style today. These discussions are not > linked. > >> > >> > On 28 Sep 2017, at 09:17, Emmanuel Bernard > >> wrote: > >> > > >> > Hello > >> > > >> > Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor > >> proposals. > >> > > >> > In frequency, I think people go read the docs online much more than > >> they want to know how to get it. So I would put the Documentation > section > >> at the top (or below the compatibility matrix if you won?t budge). > >> > > >> > In the natural flow of information discovery (I know it breaks my > >> argument above), I would put the What?s new before the migration > section. > >> > > >> > I know we have been going on and off over "Older releases?, what it > is, > >> is "Previous micro releases". So how about using that title. I imagine > >> every one will understand. > >> > > >> > Emmanuel > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Thu Sep 28 05:28:15 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 28 Sep 2017 12:28:15 +0300 Subject: [hibernate-dev] "Hibernate Types" project In-Reply-To: References: Message-ID: Hi, It's because not all database support ARRAY or JSON. We've been discussing this on the mailing list (around one year ago) and I remember we concluded that we can only add these types to ORM core if the vast majority of the Hibernate-supported database offer JSON or ARRAY. Also, even if we add support for them, it's improbable that we are going to backport it to 5.1, 5.0, 4.3, 4.2 and 4.1. So, since my blog readers requested me to provide these types via Maven Central, I decided to bundle them in a new library. If more and more databases add support for JSON, we could add support for it in 6.0. For ARRAY, I doubt that more DBs will support it if they haven't done it by now. Vlad On Thu, Sep 28, 2017 at 9:47 AM, Gunnar Morling wrote: > Hey Vlad, > > I recently learned about your "Hibernate Types" project [1]. It's great to > see support for JSON, arrays, etc! > > Out of curiosity, though, why did you decide to make it a separate project > instead of adding these very useful types to Hibernate itself? Seems it'd > be easier for people to us them that way. > > Cheers, > > --Gunnar > > [1] > https://vladmihalcea.com/2017/09/25/the-hibernate-types- > open-source-project-is-born/ > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Sep 28 05:51:24 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 11:51:24 +0200 Subject: [hibernate-dev] Website - Remove the Google+ links Message-ID: Hi, We have a couple of Google+ links here and there on the website. I was thinking we should probably remove them as they sound a bit 2010 and I don't think we are actively maintaining it. WDYT? -- Guillaume From sanne at hibernate.org Thu Sep 28 05:51:58 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 10:51:58 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On 28 September 2017 at 08:21, Guillaume Smet wrote: > On Thu, Sep 28, 2017 at 9:00 AM, Yoann Rodiere wrote: >> >> > >> > > As a user, I still need to be able to go to a given series page to >> >> > understand what was done (see my initial use case). But they can be in a >> > > older series section in small vs big boxes. >> > This is currently missing. >> >> >> NO, it is not missing. At least, the concept is there. The "What's new" >> section has been here the whole time: http://staging. >> hibernate.org/search/releases/5.8/#whats_new, with a big-ass "What's new" >> link at the top of the series page. >> So, yes, it's quite empty for now. You need to add content to the page >> /yourproject/releases/yourseries/index.adoc. I added content for Search >> 5.8 >> only for now, and I'll find some time to do the same for other Search >> series. And yes, there's too much content in this section for Search 5.8, >> but that's mainly because there's too much content in 5.8 to begin with. >> But for other projects, surely each project's leader could take a bit of >> time to do that for his own project, or delegate? Some of us are even >> asking to remove that "What's new" section because it's too empty... Could >> we please all realize that content doesn't appear magically? > > > I was talking about the ability to access the old series when they are not > displayed in the overview. > > AFAICS, this is definitely missing and we would need either a page with all > the series linked from the overview page or a button displaying the retired > series. +1 [same as I said above] > > -- > Guillaume > From sanne at hibernate.org Thu Sep 28 06:10:52 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 11:10:52 +0100 Subject: [hibernate-dev] Website - Remove the Google+ links In-Reply-To: References: Message-ID: On 28 September 2017 at 10:51, Guillaume Smet wrote: > Hi, > > We have a couple of Google+ links here and there on the website. > > I was thinking we should probably remove them as they sound a bit 2010 and > I don't think we are actively maintaining it. > > WDYT? Personally I'm more of a Twitter user but some other people actually used to advertise our stuff on G+ I think Steve manages that? Make sure to check with him before removing these. Thanks, Sanne From yoann at hibernate.org Thu Sep 28 06:11:57 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 28 Sep 2017 12:11:57 +0200 Subject: [hibernate-dev] Website - Remove the Google+ links In-Reply-To: References: Message-ID: +1. Either we properly mirror our tweets/blog posts to G+, or we stop advertising that account. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 28 September 2017 at 11:51, Guillaume Smet wrote: > Hi, > > We have a couple of Google+ links here and there on the website. > > I was thinking we should probably remove them as they sound a bit 2010 and > I don't think we are actively maintaining it. > > WDYT? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Thu Sep 28 06:39:05 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 28 Sep 2017 12:39:05 +0200 Subject: [hibernate-dev] "Hibernate Types" project In-Reply-To: References: Message-ID: 2017-09-28 11:28 GMT+02:00 Vlad Mihalcea : > Hi, > > It's because not all database support ARRAY or JSON. > > We've been discussing this on the mailing list (around one year ago) and I > remember we concluded that we can only add these types to ORM core > if the vast majority of the Hibernate-supported database offer JSON or > ARRAY. > I see. A separate project/repo under the Hibernate umbrella could be an alternative, too ("Hibernate Extras" or so). I.e. some middle ground between part of ORM proper and fully being 3rd party. Also, even if we add support for them, it's improbable that we are going to > backport it to 5.1, 5.0, 4.3, 4.2 and 4.1. So, since my blog readers > requested me to provide these types via Maven Central, I decided to bundle > them in a new library. > > If more and more databases add support for JSON, we could add support for > it in 6.0. > For ARRAY, I doubt that more DBs will support it if they haven't done it > by now. > > Vlad > > On Thu, Sep 28, 2017 at 9:47 AM, Gunnar Morling > wrote: > >> Hey Vlad, >> >> I recently learned about your "Hibernate Types" project [1]. It's great to >> see support for JSON, arrays, etc! >> >> Out of curiosity, though, why did you decide to make it a separate project >> instead of adding these very useful types to Hibernate itself? Seems it'd >> be easier for people to us them that way. >> >> Cheers, >> >> --Gunnar >> >> [1] >> https://vladmihalcea.com/2017/09/25/the-hibernate-types-open >> -source-project-is-born/ >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Thu Sep 28 07:12:07 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 13:12:07 +0200 Subject: [hibernate-dev] Website - Remove the Google+ links In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 12:10 PM, Sanne Grinovero wrote: > Personally I'm more of a Twitter user but some other people actually > used to advertise our stuff on G+ > > I think Steve manages that? Make sure to check with him before removing > these. > Ah yes, I should have taken a look. As we NoORM don't push anything there, I supposed noone did but it looks like the ORM team is actively pushing things there. So let's keep it for now, I suppose. -- Guillaume From sanne at hibernate.org Thu Sep 28 07:26:58 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 12:26:58 +0100 Subject: [hibernate-dev] Website - Remove the Google+ links In-Reply-To: References: Message-ID: On 28 September 2017 at 11:11, Yoann Rodiere wrote: > +1. Either we properly mirror our tweets/blog posts to G+, or we stop > advertising that account. Let's try using G+ a bit more? > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 28 September 2017 at 11:51, Guillaume Smet > wrote: > >> Hi, >> >> We have a couple of Google+ links here and there on the website. >> >> I was thinking we should probably remove them as they sound a bit 2010 and >> I don't think we are actively maintaining it. >> >> WDYT? >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Sep 28 07:29:45 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 13:29:45 +0200 Subject: [hibernate-dev] "Hibernate Types" project In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 12:39 PM, Gunnar Morling wrote: > I see. A separate project/repo under the Hibernate umbrella could be an > alternative, too ("Hibernate Extras" or so). I.e. some middle ground > between part of ORM proper and fully being 3rd party. > +1 to make it an official Hibernate project if Vlad is OK with that. From guillaume.smet at gmail.com Thu Sep 28 07:29:56 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 13:29:56 +0200 Subject: [hibernate-dev] [website] Specific series page In-Reply-To: References: <9C5203FE-A207-4848-B867-11EED53C9D3D@hibernate.org> Message-ID: Done. On Thu, Sep 28, 2017 at 11:13 AM, Guillaume Smet wrote: > Looks OK to me! > > On Thu, Sep 28, 2017 at 9:43 AM, Yoann Rodiere > wrote: > >> So the order would be: >> >> * Compatibility >> * Documentation >> * How to get it >> * What's new >> * Migrate >> * Releases in this series (we just renamed it, I think it pretty much >> solves the issue we were having) >> >> Right? >> >> Seems ok to me, no strong opinion about that. As long as compatibility >> info >> stays at the top ;) >> >> Anyone against it? >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 28 September 2017 at 09:42, Yoann Rodiere wrote: >> >> > So the order would be: >> > >> > * Compatibility >> > * Documentation >> > * How to get it >> > * What's new >> > * Migrate >> > * Releases in this series (we just renamed it, I think it pretty much >> > solves the issue we were having) >> > >> > Right? >> > >> > Seems ok to me, no strong opinion about that. As long as compatibility >> > info stays at the top ;) >> > >> > Anyone against it? >> > >> > >> > Yoann Rodi?re >> > Software Engineer, Hibernate NoORM Team >> > Red Hat >> > yrodiere at redhat.com >> > >> > On 28 September 2017 at 09:20, Emmanuel Bernard > > >> > wrote: >> > >> >> And I am +1 to push the new style today. These discussions are not >> linked. >> >> >> >> > On 28 Sep 2017, at 09:17, Emmanuel Bernard >> >> wrote: >> >> > >> >> > Hello >> >> > >> >> > Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor >> >> proposals. >> >> > >> >> > In frequency, I think people go read the docs online much more than >> >> they want to know how to get it. So I would put the Documentation >> section >> >> at the top (or below the compatibility matrix if you won?t budge). >> >> > >> >> > In the natural flow of information discovery (I know it breaks my >> >> argument above), I would put the What?s new before the migration >> section. >> >> > >> >> > I know we have been going on and off over "Older releases?, what it >> is, >> >> is "Previous micro releases". So how about using that title. I imagine >> >> every one will understand. >> >> > >> >> > Emmanuel >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Thu Sep 28 07:30:59 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 13:30:59 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet wrote: > I was talking about the ability to access the old series when they are not > displayed in the overview. > > AFAICS, this is definitely missing and we would need either a page with > all the series linked from the overview page or a button displaying the > retired series. > Done: I added a See older series button to the Releases / Overview page and to the Documentation page. -- Guillaume From sanne at hibernate.org Thu Sep 28 07:37:45 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 12:37:45 +0100 Subject: [hibernate-dev] "Hibernate Types" project In-Reply-To: References: Message-ID: On 28 September 2017 at 11:39, Gunnar Morling wrote: > 2017-09-28 11:28 GMT+02:00 Vlad Mihalcea : > >> Hi, >> >> It's because not all database support ARRAY or JSON. >> >> We've been discussing this on the mailing list (around one year ago) and I >> remember we concluded that we can only add these types to ORM core >> if the vast majority of the Hibernate-supported database offer JSON or >> ARRAY. >> > > I see. A separate project/repo under the Hibernate umbrella could be an > alternative, too ("Hibernate Extras" or so). I.e. some middle ground > between part of ORM proper and fully being 3rd party. I'd (eventually) aim to include it in the hibernate-orm repository, but as a separate jar? So people can take it or ignore it depending on their needs, yet we can all help making sure it keeps working for future releases. I would not incorporate it into the hibernate-core artifact so that we can exclude it from inclusion in e.g. WildFly until we feel it's ready for that. No rush though, I guess it would be easier to wait for some 6.0 branch to be stable. Thanks, Sanne > > Also, even if we add support for them, it's improbable that we are going to >> backport it to 5.1, 5.0, 4.3, 4.2 and 4.1. So, since my blog readers >> requested me to provide these types via Maven Central, I decided to bundle >> them in a new library. >> >> If more and more databases add support for JSON, we could add support for >> it in 6.0. >> For ARRAY, I doubt that more DBs will support it if they haven't done it >> by now. >> >> Vlad >> >> On Thu, Sep 28, 2017 at 9:47 AM, Gunnar Morling >> wrote: >> >>> Hey Vlad, >>> >>> I recently learned about your "Hibernate Types" project [1]. It's great to >>> see support for JSON, arrays, etc! >>> >>> Out of curiosity, though, why did you decide to make it a separate project >>> instead of adding these very useful types to Hibernate itself? Seems it'd >>> be easier for people to us them that way. >>> >>> Cheers, >>> >>> --Gunnar >>> >>> [1] >>> https://vladmihalcea.com/2017/09/25/the-hibernate-types-open >>> -source-project-is-born/ >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Thu Sep 28 07:42:14 2017 From: andrea at hibernate.org (andrea boriero) Date: Thu, 28 Sep 2017 12:42:14 +0100 Subject: [hibernate-dev] Website - Remove the Google+ links In-Reply-To: References: Message-ID: I think it would be a good idea to post on Google+ whenever we add a new blog article On 28 September 2017 at 12:26, Sanne Grinovero wrote: > On 28 September 2017 at 11:11, Yoann Rodiere wrote: > > +1. Either we properly mirror our tweets/blog posts to G+, or we stop > > advertising that account. > > Let's try using G+ a bit more? > > > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > On 28 September 2017 at 11:51, Guillaume Smet > > wrote: > > > >> Hi, > >> > >> We have a couple of Google+ links here and there on the website. > >> > >> I was thinking we should probably remove them as they sound a bit 2010 > and > >> I don't think we are actively maintaining it. > >> > >> WDYT? > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Thu Sep 28 07:45:33 2017 From: andrea at hibernate.org (andrea boriero) Date: Thu, 28 Sep 2017 12:45:33 +0100 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: I think the new layout is fine except for the gold background colour of the project names, I really do not like it. What about an opinion from the jboss.org design team? On 26 September 2017 at 17:08, Guillaume Smet wrote: > On Tue, Sep 26, 2017 at 3:47 PM, Davide D'Alto > wrote: > > > There is a background behind the title, the subtitle, the release > > version and the "Documentation". > > The end result is that it's hard to understand what's a link or button > > and therefore can be clicked. > > > > I think it would work better without any background colour. > > > > Yes, as you know, I disagree. I think it makes the website more colourful > and the header less empty. > > I think the buttons have a proper style you can't really mix with a simple > background. > > As for the documentation page, I must agree there is maybe a bit too much > of background in the content of the page but it's really not easy to make > it look appealing. > > Note that I just pushed a commit to make the buttons look consistent > everywhere with the icon at the right so that they are more easily > recognizable. I hope it helps a bit. > > > > I like the documentation page, I was surprised that we didn't use the > > same approach for the releases page. > > > > We might discuss that later. For now, it's basically the same pages Yoann > pushed this morning, just a bit more colourful. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 28 08:11:49 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 12:11:49 +0000 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: Overall the new design looks amazing. I do agree with Andrea about the gold backgrounds - that looks anything but modern and does not match the rest of the site design imo. For another iteration... "Getting started" is another group of information that is version specific. A minor thing that I can probably change myself somewhere... I very much dislike "Your relational databases. Handy." I'm sure everyone will have an opinion like when we discussed "Everything data" refrain. Some initial thoughts (with varying punctuation options): 1. Your relational data. Objectively. 2. Your relational data - objectively 3. Object/Relational Mapping 4. All your (relational data)base are belong to us - just for fun :) On Thu, Sep 28, 2017 at 6:49 AM andrea boriero wrote: > I think the new layout is fine except for the gold background colour of the > project names, I really do not like it. > What about an opinion from the jboss.org design team? > > On 26 September 2017 at 17:08, Guillaume Smet > wrote: > > > On Tue, Sep 26, 2017 at 3:47 PM, Davide D'Alto > > wrote: > > > > > There is a background behind the title, the subtitle, the release > > > version and the "Documentation". > > > The end result is that it's hard to understand what's a link or button > > > and therefore can be clicked. > > > > > > I think it would work better without any background colour. > > > > > > > Yes, as you know, I disagree. I think it makes the website more colourful > > and the header less empty. > > > > I think the buttons have a proper style you can't really mix with a > simple > > background. > > > > As for the documentation page, I must agree there is maybe a bit too much > > of background in the content of the page but it's really not easy to make > > it look appealing. > > > > Note that I just pushed a commit to make the buttons look consistent > > everywhere with the icon at the right so that they are more easily > > recognizable. I hope it helps a bit. > > > > > > > I like the documentation page, I was surprised that we didn't use the > > > same approach for the releases page. > > > > > > > We might discuss that later. For now, it's basically the same pages Yoann > > pushed this morning, just a bit more colourful. > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 28 08:16:55 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 12:16:55 +0000 Subject: [hibernate-dev] "Hibernate Types" project In-Reply-To: References: Message-ID: I'm not so sure a single "extras" artifact/module makes the most sense though. Since some involve pulling in driver jars - I think (if we do this) we ought to have `hibernate-extras-base` as well as db-specific extensions (`hibernate-extras-pgsql`, ...). We had a similar discussion recently on HipChat or mailing list (can't remember which exactly) On Thu, Sep 28, 2017 at 6:43 AM Sanne Grinovero wrote: > On 28 September 2017 at 11:39, Gunnar Morling > wrote: > > 2017-09-28 11:28 GMT+02:00 Vlad Mihalcea : > > > >> Hi, > >> > >> It's because not all database support ARRAY or JSON. > >> > >> We've been discussing this on the mailing list (around one year ago) > and I > >> remember we concluded that we can only add these types to ORM core > >> if the vast majority of the Hibernate-supported database offer JSON or > >> ARRAY. > >> > > > > I see. A separate project/repo under the Hibernate umbrella could be an > > alternative, too ("Hibernate Extras" or so). I.e. some middle ground > > between part of ORM proper and fully being 3rd party. > > I'd (eventually) aim to include it in the hibernate-orm repository, > but as a separate jar? > > So people can take it or ignore it depending on their needs, yet we > can all help making sure it keeps working for future releases. > > I would not incorporate it into the hibernate-core artifact so that we > can exclude it from inclusion in e.g. WildFly until we feel it's ready > for that. > > No rush though, I guess it would be easier to wait for some 6.0 branch > to be stable. > > Thanks, > Sanne > > > > > Also, even if we add support for them, it's improbable that we are going > to > >> backport it to 5.1, 5.0, 4.3, 4.2 and 4.1. So, since my blog readers > >> requested me to provide these types via Maven Central, I decided to > bundle > >> them in a new library. > >> > >> If more and more databases add support for JSON, we could add support > for > >> it in 6.0. > >> For ARRAY, I doubt that more DBs will support it if they haven't done it > >> by now. > >> > >> Vlad > >> > >> On Thu, Sep 28, 2017 at 9:47 AM, Gunnar Morling > >> wrote: > >> > >>> Hey Vlad, > >>> > >>> I recently learned about your "Hibernate Types" project [1]. It's > great to > >>> see support for JSON, arrays, etc! > >>> > >>> Out of curiosity, though, why did you decide to make it a separate > project > >>> instead of adding these very useful types to Hibernate itself? Seems > it'd > >>> be easier for people to us them that way. > >>> > >>> Cheers, > >>> > >>> --Gunnar > >>> > >>> [1] > >>> https://vladmihalcea.com/2017/09/25/the-hibernate-types-open > >>> -source-project-is-born/ > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 28 08:30:18 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 12:30:18 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: Do y'all really think it makes sense to have JPA versions in this ORM "compatibility matrix"? My concern is that it is more involved (as we then try to convey in the section below that matrix) than a cell in a matrix/table with just a version number. If we end up treating JPA compatibility differently (removing from table) then the table is just made up of "Java compatibility", which we can probably illustrate simpler than a single vertical row of versions. On Thu, Sep 28, 2017 at 6:37 AM Guillaume Smet wrote: > On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet > wrote: > > > I was talking about the ability to access the old series when they are > not > > displayed in the overview. > > > > AFAICS, this is definitely missing and we would need either a page with > > all the series linked from the overview page or a button displaying the > > retired series. > > > > Done: I added a See older series button to the Releases / Overview page and > to the Documentation page. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Thu Sep 28 08:39:30 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 28 Sep 2017 14:39:30 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: What's in the matrix is up to each project. You can remove content by editing the .yml file for each series, and removing elements from site.yml under projects.orm.integrations. I'd argue that moving away from the matrix for ORM just because Java compatibility is "not enough" will force us to add a special case just for ORM, and I'm not particularly interested in doing that. But feel free to do so, or to remove the compatibility matrix completely for ORM. I think there could be more in that matrix than just Java though, like the compatibility with various major RDBMSs, or with some connection pools. But again, it's your call. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 28 September 2017 at 14:30, Steve Ebersole wrote: > Do y'all really think it makes sense to have JPA versions in this ORM > "compatibility matrix"? > > My concern is that it is more involved (as we then try to convey in the > section below that matrix) than a cell in a matrix/table with just a > version number. > > If we end up treating JPA compatibility differently (removing from table) > then the table is just made up of "Java compatibility", which we can > probably illustrate simpler than a single vertical row of versions. > > On Thu, Sep 28, 2017 at 6:37 AM Guillaume Smet > wrote: > >> On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet > > >> wrote: >> >> > I was talking about the ability to access the old series when they are >> not >> > displayed in the overview. >> > >> > AFAICS, this is definitely missing and we would need either a page with >> > all the series linked from the overview page or a button displaying the >> > retired series. >> > >> >> Done: I added a See older series button to the Releases / Overview page >> and >> to the Documentation page. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From sanne at hibernate.org Thu Sep 28 09:00:26 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 14:00:26 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On 28 September 2017 at 13:30, Steve Ebersole wrote: > Do y'all really think it makes sense to have JPA versions in this ORM > "compatibility matrix"? I think it's useful. Try booting a recent ORM version with an out of date JPA api jar: you'll get really weird exceptions and it's hard to figure out what's wrong. https://forum.hibernate.org/viewtopic.php?f=1&t=1043938 Hopefully in future having a single JPA API distribution (in terms of Maven coordinates) would make such issues a thing of the past, but it's going to take a while yet. > > My concern is that it is more involved (as we then try to convey in the > section below that matrix) than a cell in a matrix/table with just a > version number. > > If we end up treating JPA compatibility differently (removing from table) > then the table is just made up of "Java compatibility", which we can > probably illustrate simpler than a single vertical row of versions. > > On Thu, Sep 28, 2017 at 6:37 AM Guillaume Smet > wrote: > >> On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet >> wrote: >> >> > I was talking about the ability to access the old series when they are >> not >> > displayed in the overview. >> > >> > AFAICS, this is definitely missing and we would need either a page with >> > all the series linked from the overview page or a button displaying the >> > retired series. >> > >> >> Done: I added a See older series button to the Releases / Overview page and >> to the Documentation page. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Sep 28 09:09:25 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 14:09:25 +0100 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: On 28 September 2017 at 13:11, Steve Ebersole wrote: > Overall the new design looks amazing. I do agree with Andrea about the > gold backgrounds - that looks anything but modern and does not match the > rest of the site design imo. > > For another iteration... "Getting started" is another group of information > that is version specific. > > A minor thing that I can probably change myself somewhere... I very much > dislike "Your relational databases. Handy." I'm sure everyone will have an > opinion like when we discussed "Everything data" refrain. Some initial > thoughts (with varying punctuation options): > > > 1. Your relational data. Objectively. > 2. Your relational data - objectively > 3. Object/Relational Mapping > 4. All your (relational data)base are belong to us - just for fun :) I love the fun expression in proposal #4 but I think it would be more effective if we can avoid the usage of parentheses. "All your data are belong to us" ? I've also been wondering if we could better exploit the amazing name we have. "Winter is coming, have your object hibernate safely". > > > > > On Thu, Sep 28, 2017 at 6:49 AM andrea boriero wrote: > >> I think the new layout is fine except for the gold background colour of the >> project names, I really do not like it. >> What about an opinion from the jboss.org design team? >> >> On 26 September 2017 at 17:08, Guillaume Smet >> wrote: >> >> > On Tue, Sep 26, 2017 at 3:47 PM, Davide D'Alto >> > wrote: >> > >> > > There is a background behind the title, the subtitle, the release >> > > version and the "Documentation". >> > > The end result is that it's hard to understand what's a link or button >> > > and therefore can be clicked. >> > > >> > > I think it would work better without any background colour. >> > > >> > >> > Yes, as you know, I disagree. I think it makes the website more colourful >> > and the header less empty. >> > >> > I think the buttons have a proper style you can't really mix with a >> simple >> > background. >> > >> > As for the documentation page, I must agree there is maybe a bit too much >> > of background in the content of the page but it's really not easy to make >> > it look appealing. >> > >> > Note that I just pushed a commit to make the buttons look consistent >> > everywhere with the icon at the right so that they are more easily >> > recognizable. I hope it helps a bit. >> > >> > >> > > I like the documentation page, I was surprised that we didn't use the >> > > same approach for the releases page. >> > > >> > >> > We might discuss that later. For now, it's basically the same pages Yoann >> > pushed this morning, just a bit more colourful. >> > >> > -- >> > Guillaume >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Sep 28 09:10:43 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 14:10:43 +0100 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: On 28 September 2017 at 14:09, Sanne Grinovero wrote: > On 28 September 2017 at 13:11, Steve Ebersole wrote: >> Overall the new design looks amazing. I do agree with Andrea about the >> gold backgrounds - that looks anything but modern and does not match the >> rest of the site design imo. >> >> For another iteration... "Getting started" is another group of information >> that is version specific. >> >> A minor thing that I can probably change myself somewhere... I very much >> dislike "Your relational databases. Handy." I'm sure everyone will have an >> opinion like when we discussed "Everything data" refrain. Some initial >> thoughts (with varying punctuation options): >> >> >> 1. Your relational data. Objectively. >> 2. Your relational data - objectively >> 3. Object/Relational Mapping >> 4. All your (relational data)base are belong to us - just for fun :) > > I love the fun expression in proposal #4 but I think it would be more > effective if we can avoid the usage of parentheses. > > "All your data are belong to us" ? > > I've also been wondering if we could better exploit the amazing name we have. > > "Winter is coming, have your object hibernate safely". Meant this in plural form of course: "Winter is coming, have your objects hibernate safely". > >> >> >> >> >> On Thu, Sep 28, 2017 at 6:49 AM andrea boriero wrote: >> >>> I think the new layout is fine except for the gold background colour of the >>> project names, I really do not like it. >>> What about an opinion from the jboss.org design team? >>> >>> On 26 September 2017 at 17:08, Guillaume Smet >>> wrote: >>> >>> > On Tue, Sep 26, 2017 at 3:47 PM, Davide D'Alto >>> > wrote: >>> > >>> > > There is a background behind the title, the subtitle, the release >>> > > version and the "Documentation". >>> > > The end result is that it's hard to understand what's a link or button >>> > > and therefore can be clicked. >>> > > >>> > > I think it would work better without any background colour. >>> > > >>> > >>> > Yes, as you know, I disagree. I think it makes the website more colourful >>> > and the header less empty. >>> > >>> > I think the buttons have a proper style you can't really mix with a >>> simple >>> > background. >>> > >>> > As for the documentation page, I must agree there is maybe a bit too much >>> > of background in the content of the page but it's really not easy to make >>> > it look appealing. >>> > >>> > Note that I just pushed a commit to make the buttons look consistent >>> > everywhere with the icon at the right so that they are more easily >>> > recognizable. I hope it helps a bit. >>> > >>> > >>> > > I like the documentation page, I was surprised that we didn't use the >>> > > same approach for the releases page. >>> > > >>> > >>> > We might discuss that later. For now, it's basically the same pages Yoann >>> > pushed this morning, just a bit more colourful. >>> > >>> > -- >>> > Guillaume >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Sep 28 09:23:54 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 15:23:54 +0200 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole wrote: > Overall the new design looks amazing. I do agree with Andrea about the > gold backgrounds - that looks anything but modern and does not match the > rest of the site design imo. > Frankly, it feels weird without. So if anyone has a proposition, maybe a different color. My initial inspiration for this was: http://wildfly-swarm.io/ . I personally very much like it and fought with Davide about keeping it :). > For another iteration... "Getting started" is another group of information > that is version specific. > The initial reasoning for that is that you would probably start with the latest version if you are going to start a new project/experiment with Hibernate. Not sure it's worth complicating things for that. > > A minor thing that I can probably change myself somewhere... I very much > dislike "Your relational databases. Handy." I'm sure everyone will have an > opinion like when we discussed "Everything data" refrain. Some initial > thoughts (with varying punctuation options): > > > 1. Your relational data. Objectively. > 2. Your relational data - objectively > 3. Object/Relational Mapping > 4. All your (relational data)base are belong to us - just for fun :) > > Yeah, as explained in my original post, it was just placeholders. Happy to change it. I like "Your relational data. Objectively.". Better than Sanne's proposal which is not going to age well :). -- Guillaume From guillaume.smet at gmail.com Thu Sep 28 09:32:54 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 15:32:54 +0200 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet wrote: > On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole > wrote: > >> Overall the new design looks amazing. I do agree with Andrea about the >> gold backgrounds - that looks anything but modern and does not match the >> rest of the site design imo. >> > > Frankly, it feels weird without. So if anyone has a proposition, maybe a > different color. > > My initial inspiration for this was: http://wildfly-swarm.io/ . > > I personally very much like it and fought with Davide about keeping it :). > Pushed a different version to http://staging.hibernate.org/search/ using something softer for the main title. Personally, I prefer the golden version. And I disagree it's not modern by the way. Backgrounds are coming back \o/. -- Guillaume From steve at hibernate.org Thu Sep 28 09:53:05 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 13:53:05 +0000 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: The question is not about whether to have that information. The question is whether a one row table spanning horizontally across the screen is the best presentation for that info. On Thu, Sep 28, 2017 at 8:01 AM Sanne Grinovero wrote: > On 28 September 2017 at 13:30, Steve Ebersole wrote: > > Do y'all really think it makes sense to have JPA versions in this ORM > > "compatibility matrix"? > > I think it's useful. Try booting a recent ORM version with an out of > date JPA api jar: you'll get really weird exceptions and it's hard to > figure out what's wrong. > > https://forum.hibernate.org/viewtopic.php?f=1&t=1043938 > > Hopefully in future having a single JPA API distribution (in terms of > Maven coordinates) would make such issues a thing of the past, but > it's going to take a while yet. > > > > > My concern is that it is more involved (as we then try to convey in the > > section below that matrix) than a cell in a matrix/table with just a > > version number. > > > > If we end up treating JPA compatibility differently (removing from table) > > then the table is just made up of "Java compatibility", which we can > > probably illustrate simpler than a single vertical row of versions. > > > > On Thu, Sep 28, 2017 at 6:37 AM Guillaume Smet > > > wrote: > > > >> On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet < > guillaume.smet at gmail.com> > >> wrote: > >> > >> > I was talking about the ability to access the old series when they are > >> not > >> > displayed in the overview. > >> > > >> > AFAICS, this is definitely missing and we would need either a page > with > >> > all the series linked from the overview page or a button displaying > the > >> > retired series. > >> > > >> > >> Done: I added a See older series button to the Releases / Overview page > and > >> to the Documentation page. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 28 09:55:55 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 13:55:55 +0000 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: Ah, so its retro-modern ;) So what happens if you remove the gold/light-gray completely and just use the dark-gray as background for the white-lettered words? Seems like that would JustWork. On Thu, Sep 28, 2017 at 8:33 AM Guillaume Smet wrote: > On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet > wrote: > >> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole >> wrote: >> >>> Overall the new design looks amazing. I do agree with Andrea about the >>> gold backgrounds - that looks anything but modern and does not match the >>> rest of the site design imo. >>> >> >> Frankly, it feels weird without. So if anyone has a proposition, maybe a >> different color. >> >> My initial inspiration for this was: http://wildfly-swarm.io/ . >> >> I personally very much like it and fought with Davide about keeping it :). >> > > Pushed a different version to http://staging.hibernate.org/search/ using > something softer for the main title. > > Personally, I prefer the golden version. > > And I disagree it's not modern by the way. Backgrounds are coming back \o/. > > -- > Guillaume > From chris at hibernate.org Thu Sep 28 09:56:14 2017 From: chris at hibernate.org (Chris Cranford) Date: Thu, 28 Sep 2017 09:56:14 -0400 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: <2a53d864-22b5-06df-eaec-66b5f4bb23e8@hibernate.org> Guillaume - If we must keep a background color, I think the new color you've changed on staging feels like it flows much more than the gold and is far more appealing to the eye, imo. Chris On 09/28/2017 09:32 AM, Guillaume Smet wrote: > On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet > wrote: > >> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole >> wrote: >> >>> Overall the new design looks amazing. I do agree with Andrea about the >>> gold backgrounds - that looks anything but modern and does not match the >>> rest of the site design imo. >>> >> Frankly, it feels weird without. So if anyone has a proposition, maybe a >> different color. >> >> My initial inspiration for this was: http://wildfly-swarm.io/ . >> >> I personally very much like it and fought with Davide about keeping it :). >> > Pushed a different version to http://staging.hibernate.org/search/ using > something softer for the main title. > > Personally, I prefer the golden version. > > And I disagree it's not modern by the way. Backgrounds are coming back \o/. > From steve at hibernate.org Thu Sep 28 09:56:35 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 13:56:35 +0000 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: Message-ID: P.S. Sorry, I would TIAS but my CSS skills are slight better than those of an ocelot. On Thu, Sep 28, 2017 at 8:55 AM Steve Ebersole wrote: > Ah, so its retro-modern ;) > > So what happens if you remove the gold/light-gray completely and just use > the dark-gray as background for the white-lettered words? Seems like that > would JustWork. > > > On Thu, Sep 28, 2017 at 8:33 AM Guillaume Smet > wrote: > >> On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet > > wrote: >> >>> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole >>> wrote: >>> >>>> Overall the new design looks amazing. I do agree with Andrea about the >>>> gold backgrounds - that looks anything but modern and does not match the >>>> rest of the site design imo. >>>> >>> >>> Frankly, it feels weird without. So if anyone has a proposition, maybe a >>> different color. >>> >>> My initial inspiration for this was: http://wildfly-swarm.io/ . >>> >>> I personally very much like it and fought with Davide about keeping it >>> :). >>> >> >> Pushed a different version to http://staging.hibernate.org/search/ using >> something softer for the main title. >> >> Personally, I prefer the golden version. >> >> And I disagree it's not modern by the way. Backgrounds are coming back >> \o/. >> >> -- >> Guillaume >> > From guillaume.smet at gmail.com Thu Sep 28 10:08:52 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 16:08:52 +0200 Subject: [hibernate-dev] New layout for the website In-Reply-To: <2a53d864-22b5-06df-eaec-66b5f4bb23e8@hibernate.org> References: <2a53d864-22b5-06df-eaec-66b5f4bb23e8@hibernate.org> Message-ID: OK, let's settle on the grey one then. Sigh. :) On Thu, Sep 28, 2017 at 3:56 PM, Chris Cranford wrote: > Guillaume - > > If we must keep a background color, I think the new color you've changed > on staging > feels like it flows much more than the gold and is far more appealing to > the eye, imo. > > Chris > > On 09/28/2017 09:32 AM, Guillaume Smet wrote: > > On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet < > guillaume.smet at gmail.com> > > wrote: > > > >> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole > >> wrote: > >> > >>> Overall the new design looks amazing. I do agree with Andrea about the > >>> gold backgrounds - that looks anything but modern and does not match > the > >>> rest of the site design imo. > >>> > >> Frankly, it feels weird without. So if anyone has a proposition, maybe a > >> different color. > >> > >> My initial inspiration for this was: http://wildfly-swarm.io/ . > >> > >> I personally very much like it and fought with Davide about keeping it > :). > >> > > Pushed a different version to http://staging.hibernate.org/search/ using > > something softer for the main title. > > > > Personally, I prefer the golden version. > > > > And I disagree it's not modern by the way. Backgrounds are coming back > \o/. > > > > From steve at hibernate.org Thu Sep 28 10:10:40 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 14:10:40 +0000 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: <2a53d864-22b5-06df-eaec-66b5f4bb23e8@hibernate.org> Message-ID: If you really like the gold, why not try making that whole banner gold? On Thu, Sep 28, 2017 at 9:09 AM Guillaume Smet wrote: > OK, let's settle on the grey one then. > > Sigh. :) > > On Thu, Sep 28, 2017 at 3:56 PM, Chris Cranford > wrote: > >> Guillaume - >> >> If we must keep a background color, I think the new color you've changed >> on staging >> feels like it flows much more than the gold and is far more appealing to >> the eye, imo. >> >> Chris >> >> On 09/28/2017 09:32 AM, Guillaume Smet wrote: >> > On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet < >> guillaume.smet at gmail.com> >> > wrote: >> > >> >> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole >> >> wrote: >> >> >> >>> Overall the new design looks amazing. I do agree with Andrea about >> the >> >>> gold backgrounds - that looks anything but modern and does not match >> the >> >>> rest of the site design imo. >> >>> >> >> Frankly, it feels weird without. So if anyone has a proposition, maybe >> a >> >> different color. >> >> >> >> My initial inspiration for this was: http://wildfly-swarm.io/ . >> >> >> >> I personally very much like it and fought with Davide about keeping it >> :). >> >> >> > Pushed a different version to http://staging.hibernate.org/search/ >> using >> > something softer for the main title. >> > >> > Personally, I prefer the golden version. >> > >> > And I disagree it's not modern by the way. Backgrounds are coming back >> \o/. >> > >> >> > From guillaume.smet at gmail.com Thu Sep 28 10:21:13 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 16:21:13 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On Thu, Sep 28, 2017 at 3:53 PM, Steve Ebersole wrote: > The question is not about whether to have that information. The question > is whether a one row table spanning horizontally across the screen is the > best presentation for that info. > Yeah, the example of ORM is not the best one for this table. Here is how it looks for Search: http://hibernate.org/search/releases/ Not sure it's worth doing something specific for ORM and maintain another separate template. -- Guillaume From guillaume.smet at gmail.com Thu Sep 28 10:25:15 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 16:25:15 +0200 Subject: [hibernate-dev] ORM release process Message-ID: Hi ORM guys, So with a new website comes new responsabilities. I updated the NoORM release process but I don't know where you put these information for ORM. So basically, when you release a new MAJOR version, you will have to take care of adding a *data/projects/orm/releases/series.yml *file and a *orm* */releases//index.adoc* file. Basically, you have to do the same thing for the release page than what you already do with your custom documentation page. We already created them for the existing releases so you already have templates you just have to adjust when publishing a new major release. -- Guillaume From sanne at hibernate.org Thu Sep 28 10:26:16 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 15:26:16 +0100 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On 28 September 2017 at 14:53, Steve Ebersole wrote: > The question is not about whether to have that information. The question is > whether a one row table spanning horizontally across the screen is the best > presentation for that info. TBH I don't remember myself which ORM series is JPA 2.2 and which one is 2.1, I often have to doublecheck.. I just think regular users would have this need even more often. But I see how this can be far fetched, while there are objectinve benefits from having a cleaner table, so feel free to remove it. > On Thu, Sep 28, 2017 at 8:01 AM Sanne Grinovero wrote: >> >> On 28 September 2017 at 13:30, Steve Ebersole wrote: >> > Do y'all really think it makes sense to have JPA versions in this ORM >> > "compatibility matrix"? >> >> I think it's useful. Try booting a recent ORM version with an out of >> date JPA api jar: you'll get really weird exceptions and it's hard to >> figure out what's wrong. >> >> https://forum.hibernate.org/viewtopic.php?f=1&t=1043938 >> >> Hopefully in future having a single JPA API distribution (in terms of >> Maven coordinates) would make such issues a thing of the past, but >> it's going to take a while yet. >> >> > >> > My concern is that it is more involved (as we then try to convey in the >> > section below that matrix) than a cell in a matrix/table with just a >> > version number. >> > >> > If we end up treating JPA compatibility differently (removing from >> > table) >> > then the table is just made up of "Java compatibility", which we can >> > probably illustrate simpler than a single vertical row of versions. >> > >> > On Thu, Sep 28, 2017 at 6:37 AM Guillaume Smet >> > >> > wrote: >> > >> >> On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet >> >> >> >> wrote: >> >> >> >> > I was talking about the ability to access the old series when they >> >> > are >> >> not >> >> > displayed in the overview. >> >> > >> >> > AFAICS, this is definitely missing and we would need either a page >> >> > with >> >> > all the series linked from the overview page or a button displaying >> >> > the >> >> > retired series. >> >> > >> >> >> >> Done: I added a See older series button to the Releases / Overview page >> >> and >> >> to the Documentation page. >> >> >> >> -- >> >> Guillaume >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Sep 28 10:27:11 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Sep 2017 15:27:11 +0100 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: <2a53d864-22b5-06df-eaec-66b5f4bb23e8@hibernate.org> Message-ID: On 28 September 2017 at 15:10, Steve Ebersole wrote: > If you really like the gold, why not try making that whole banner gold? It's expensive! > > > On Thu, Sep 28, 2017 at 9:09 AM Guillaume Smet > wrote: > >> OK, let's settle on the grey one then. >> >> Sigh. :) >> >> On Thu, Sep 28, 2017 at 3:56 PM, Chris Cranford >> wrote: >> >>> Guillaume - >>> >>> If we must keep a background color, I think the new color you've changed >>> on staging >>> feels like it flows much more than the gold and is far more appealing to >>> the eye, imo. >>> >>> Chris >>> >>> On 09/28/2017 09:32 AM, Guillaume Smet wrote: >>> > On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet < >>> guillaume.smet at gmail.com> >>> > wrote: >>> > >>> >> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole >>> >> wrote: >>> >> >>> >>> Overall the new design looks amazing. I do agree with Andrea about >>> the >>> >>> gold backgrounds - that looks anything but modern and does not match >>> the >>> >>> rest of the site design imo. >>> >>> >>> >> Frankly, it feels weird without. So if anyone has a proposition, maybe >>> a >>> >> different color. >>> >> >>> >> My initial inspiration for this was: http://wildfly-swarm.io/ . >>> >> >>> >> I personally very much like it and fought with Davide about keeping it >>> :). >>> >> >>> > Pushed a different version to http://staging.hibernate.org/search/ >>> using >>> > something softer for the main title. >>> > >>> > Personally, I prefer the golden version. >>> > >>> > And I disagree it's not modern by the way. Backgrounds are coming back >>> \o/. >>> > >>> >>> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Sep 28 10:33:21 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 16:33:21 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: On Thu, Sep 28, 2017 at 4:26 PM, Sanne Grinovero wrote: > But I see how this can be far fetched, while there are objectinve > benefits from having a cleaner table, so feel free to remove it. > Well not really. I personally don't want to maintain specific templates for each project, and I'm pretty sure Yoann doesn't either. I don't think it's that annoying to have it. Definitely better than having to maintain special templates or special cases in the template. Please, let's keep it simple. -- Guillaume From guillaume.smet at gmail.com Thu Sep 28 10:46:15 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 16:46:15 +0200 Subject: [hibernate-dev] [Search and more] What is new in a give release In-Reply-To: References: <20170914083839.GB12444@hibernate.org> <20170926143601.GD70406@hibernate.org> Message-ID: <4746BAC6-F5A4-484D-94BF-D414653B7984@gmail.com> Btw, it's not ? one line array, you also have he Java version. So maybe what's missing is a header to make it clearer? > Le 28 sept. 2017 ? 16:33, Guillaume Smet a ?crit : > >> On Thu, Sep 28, 2017 at 4:26 PM, Sanne Grinovero wrote: >> But I see how this can be far fetched, while there are objectinve >> benefits from having a cleaner table, so feel free to remove it. > > Well not really. > > I personally don't want to maintain specific templates for each project, and I'm pretty sure Yoann doesn't either. > > I don't think it's that annoying to have it. Definitely better than having to maintain special templates or special cases in the template. > > Please, let's keep it simple. > > -- > Guillaume > From crancran at gmail.com Thu Sep 28 11:58:39 2017 From: crancran at gmail.com (Chris Cranford) Date: Thu, 28 Sep 2017 11:58:39 -0400 Subject: [hibernate-dev] ORM release process In-Reply-To: References: Message-ID: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Thanks Guillaume. On 09/28/2017 10:25 AM, Guillaume Smet wrote: > Hi ORM guys, > > So with a new website comes new responsabilities. > > I updated the NoORM release process but I don't know where you put these > information for ORM. > > So basically, when you release a new MAJOR version, you will have to take > care of adding a *data/projects/orm/releases/series.yml *file and a *orm* > */releases//index.adoc* file. > > Basically, you have to do the same thing for the release page than what you > already do with your custom documentation page. > > We already created them for the existing releases so you already have > templates you just have to adjust when publishing a new major release. > From steve at hibernate.org Thu Sep 28 12:22:13 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 16:22:13 +0000 Subject: [hibernate-dev] New layout for the website In-Reply-To: References: <2a53d864-22b5-06df-eaec-66b5f4bb23e8@hibernate.org> Message-ID: That was a rich joke Sanne... On Thu, Sep 28, 2017 at 9:27 AM Sanne Grinovero wrote: > On 28 September 2017 at 15:10, Steve Ebersole wrote: > > If you really like the gold, why not try making that whole banner gold? > > It's expensive! > > > > > > > On Thu, Sep 28, 2017 at 9:09 AM Guillaume Smet > > > wrote: > > > >> OK, let's settle on the grey one then. > >> > >> Sigh. :) > >> > >> On Thu, Sep 28, 2017 at 3:56 PM, Chris Cranford > >> wrote: > >> > >>> Guillaume - > >>> > >>> If we must keep a background color, I think the new color you've > changed > >>> on staging > >>> feels like it flows much more than the gold and is far more appealing > to > >>> the eye, imo. > >>> > >>> Chris > >>> > >>> On 09/28/2017 09:32 AM, Guillaume Smet wrote: > >>> > On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet < > >>> guillaume.smet at gmail.com> > >>> > wrote: > >>> > > >>> >> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole < > steve at hibernate.org> > >>> >> wrote: > >>> >> > >>> >>> Overall the new design looks amazing. I do agree with Andrea about > >>> the > >>> >>> gold backgrounds - that looks anything but modern and does not > match > >>> the > >>> >>> rest of the site design imo. > >>> >>> > >>> >> Frankly, it feels weird without. So if anyone has a proposition, > maybe > >>> a > >>> >> different color. > >>> >> > >>> >> My initial inspiration for this was: http://wildfly-swarm.io/ . > >>> >> > >>> >> I personally very much like it and fought with Davide about keeping > it > >>> :). > >>> >> > >>> > Pushed a different version to http://staging.hibernate.org/search/ > >>> using > >>> > something softer for the main title. > >>> > > >>> > Personally, I prefer the golden version. > >>> > > >>> > And I disagree it's not modern by the way. Backgrounds are coming > back > >>> \o/. > >>> > > >>> > >>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From dreborier at gmail.com Thu Sep 28 12:30:04 2017 From: dreborier at gmail.com (andrea boriero) Date: Thu, 28 Sep 2017 17:30:04 +0100 Subject: [hibernate-dev] ORM release process In-Reply-To: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: Thanks Guillame the *orm/releases//index.adoc* file should be changed only in case of a major or minor not for a micro, am I right? On 28 September 2017 at 16:58, Chris Cranford wrote: > Thanks Guillaume. > > On 09/28/2017 10:25 AM, Guillaume Smet wrote: > > Hi ORM guys, > > > > So with a new website comes new responsabilities. > > > > I updated the NoORM release process but I don't know where you put these > > information for ORM. > > > > So basically, when you release a new MAJOR version, you will have to take > > care of adding a *data/projects/orm/releases/series.yml *file and a > *orm* > > */releases//index.adoc* file. > > > > Basically, you have to do the same thing for the release page than what > you > > already do with your custom documentation page. > > > > We already created them for the existing releases so you already have > > templates you just have to adjust when publishing a new major release. > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Sep 28 12:41:36 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Sep 2017 16:41:36 +0000 Subject: [hibernate-dev] ORM release process In-Reply-To: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: To be honest, I think that is perfect process Guillaume. I can now define all that content and information in one place, which is a huge win. Which make me think of a future nice-to-have we could consider... to drive the release announcements (blog, emails, twitter, etc) from the content of a series.yml. Thanks again for all your work on these changes. It really does look a lot better I think. On Thu, Sep 28, 2017 at 11:16 AM Chris Cranford wrote: > Thanks Guillaume. > > On 09/28/2017 10:25 AM, Guillaume Smet wrote: > > Hi ORM guys, > > > > So with a new website comes new responsabilities. > > > > I updated the NoORM release process but I don't know where you put these > > information for ORM. > > > > So basically, when you release a new MAJOR version, you will have to take > > care of adding a *data/projects/orm/releases/series.yml *file and a *orm* > > */releases//index.adoc* file. > > > > Basically, you have to do the same thing for the release page than what > you > > already do with your custom documentation page. > > > > We already created them for the existing releases so you already have > > templates you just have to adjust when publishing a new major release. > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Sep 28 12:47:10 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 18:47:10 +0200 Subject: [hibernate-dev] ORM release process In-Reply-To: References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: You just need to create it for a major. It's this page: http://hibernate.org/orm/releases/5.2/ presenting the whole major. You can keep it simple or add content to it presenting the major as done here in the What's new section: http://hibernate.org/search/releases/5.8/. For a minor or a micro, you just need to create the X.Y.Z.yml file as usual. BTW, with the work Yoann did, you don't really need to mark the previous micros as displayed: false anymore. -- Guillaume On Thu, Sep 28, 2017 at 6:30 PM, andrea boriero wrote: > Thanks Guillame > > the *orm/releases//index.adoc* file should be changed only in > case of a major or minor not for a micro, am I right? > > > > On 28 September 2017 at 16:58, Chris Cranford wrote: > >> Thanks Guillaume. >> >> On 09/28/2017 10:25 AM, Guillaume Smet wrote: >> > Hi ORM guys, >> > >> > So with a new website comes new responsabilities. >> > >> > I updated the NoORM release process but I don't know where you put these >> > information for ORM. >> > >> > So basically, when you release a new MAJOR version, you will have to >> take >> > care of adding a *data/projects/orm/releases/series.yml *file and a >> *orm* >> > */releases//index.adoc* file. >> > >> > Basically, you have to do the same thing for the release page than what >> you >> > already do with your custom documentation page. >> > >> > We already created them for the existing releases so you already have >> > templates you just have to adjust when publishing a new major release. >> > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Thu Sep 28 12:48:21 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Sep 2017 18:48:21 +0200 Subject: [hibernate-dev] ORM release process In-Reply-To: References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: On Thu, Sep 28, 2017 at 6:41 PM, Steve Ebersole wrote: > To be honest, I think that is perfect process Guillaume. I can now > define all that content and information in one place, which is a huge win. > Which make me think of a future nice-to-have we could consider... to drive > the release announcements (blog, emails, twitter, etc) from the content of > a series.yml. > > Thanks again for all your work on these changes. It really does look a > lot better I think. > The release work is Yoann's. I just worked on the new layout. So kudos go to him for the Releases page improvement! -- Guillaume From andrea at hibernate.org Thu Sep 28 13:08:46 2017 From: andrea at hibernate.org (andrea boriero) Date: Thu, 28 Sep 2017 18:08:46 +0100 Subject: [hibernate-dev] ORM release process In-Reply-To: References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: Thanks a lot Guillaume and Yoann, great work. On 28 September 2017 at 17:41, Steve Ebersole wrote: > To be honest, I think that is perfect process Guillaume. I can now define > all that content and information in one place, which is a huge win. Which > make me think of a future nice-to-have we could consider... to drive the > release announcements (blog, emails, twitter, etc) from the content of a > series.yml. > > Thanks again for all your work on these changes. It really does look a lot > better I think. > > On Thu, Sep 28, 2017 at 11:16 AM Chris Cranford > wrote: > > > Thanks Guillaume. > > > > On 09/28/2017 10:25 AM, Guillaume Smet wrote: > > > Hi ORM guys, > > > > > > So with a new website comes new responsabilities. > > > > > > I updated the NoORM release process but I don't know where you put > these > > > information for ORM. > > > > > > So basically, when you release a new MAJOR version, you will have to > take > > > care of adding a *data/projects/orm/releases/series.yml *file and a > *orm* > > > */releases//index.adoc* file. > > > > > > Basically, you have to do the same thing for the release page than what > > you > > > already do with your custom documentation page. > > > > > > We already created them for the existing releases so you already have > > > templates you just have to adjust when publishing a new major release. > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Fri Sep 29 04:22:02 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 29 Sep 2017 10:22:02 +0200 Subject: [hibernate-dev] ORM release process In-Reply-To: References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: Hi, Thanks Guillaume for stepping up to explain this. I should have done it but I guess I forgot :) > You just need to create it for a major. > It's this page: http://hibernate.org/orm/releases/5.2/ presenting the > whole > major. I think there's a confusion between major, minor an micro here. Our version numbers are: major.minor.micro. As far as I understood, 5 is a major version, 5.2 is a minor version, 5.2.1 is a micro. To sum up: - New micro/alpha/beta/CR/whatever: just add a new _data/orm/releases//.yml file like you used to. No need to change/remove the previous ones, and in fact you shouldn't remove them: removing files will break stuff. - New major or minor: - add a new _data/orm/releases//series.yml file - add a new _data/orm/releases//.yml file. - add a new orm/releases//index.adoc file. It can be empty except for the AsciiDoc metadata, but ideally you would put in there a description of the minor. The content will appear in the "What's new" section on the series page. For example: http://hibernate.org/search/releases/5.8/#whats-new. Obviously you'll want to keep yours shorter, I'm just not good at summarizing ;) Thanks, Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 28 September 2017 at 19:08, andrea boriero wrote: > Thanks a lot Guillaume and Yoann, great work. > > On 28 September 2017 at 17:41, Steve Ebersole wrote: > > > To be honest, I think that is perfect process Guillaume. I can now > define > > all that content and information in one place, which is a huge win. > Which > > make me think of a future nice-to-have we could consider... to drive the > > release announcements (blog, emails, twitter, etc) from the content of a > > series.yml. > > > > Thanks again for all your work on these changes. It really does look a > lot > > better I think. > > > > On Thu, Sep 28, 2017 at 11:16 AM Chris Cranford > > wrote: > > > > > Thanks Guillaume. > > > > > > On 09/28/2017 10:25 AM, Guillaume Smet wrote: > > > > Hi ORM guys, > > > > > > > > So with a new website comes new responsabilities. > > > > > > > > I updated the NoORM release process but I don't know where you put > > these > > > > information for ORM. > > > > > > > > So basically, when you release a new MAJOR version, you will have to > > take > > > > care of adding a *data/projects/orm/releases/series.yml *file and a > > *orm* > > > > */releases//index.adoc* file. > > > > > > > > Basically, you have to do the same thing for the release page than > what > > > you > > > > already do with your custom documentation page. > > > > > > > > We already created them for the existing releases so you already have > > > > templates you just have to adjust when publishing a new major > release. > > > > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Fri Sep 29 04:38:43 2017 From: andrea at hibernate.org (andrea boriero) Date: Fri, 29 Sep 2017 09:38:43 +0100 Subject: [hibernate-dev] ORM release process In-Reply-To: References: <279f1895-9221-3f88-830e-aa1868539d3c@gmail.com> Message-ID: Yoann your understood of major, minor and micro seems correct to me at least it is what I understood too and Thanks for the sum up, really clear. On 29 September 2017 at 09:22, Yoann Rodiere wrote: > Hi, > > Thanks Guillaume for stepping up to explain this. I should have done it > but I guess I forgot :) > > >> You just need to create it for a major. >> It's this page: http://hibernate.org/orm/releases/5.2/ presenting the >> whole >> major. > > > I think there's a confusion between major, minor an micro here. > > Our version numbers are: major.minor.micro. As far as I understood, 5 is a > major version, 5.2 is a minor version, 5.2.1 is a micro. > > To sum up: > > - New micro/alpha/beta/CR/whatever: just add a new > _data/orm/releases// FinalOrAlphaOrBetaOrWhatever>.yml file like you used to. No need to > change/remove the previous ones, and in fact you shouldn't remove them: > removing files will break stuff. > - New major or minor: > - add a new _data/orm/releases//series.yml file > - add a new _data/orm/releases// FinalOrAlphaOrBetaOrWhatever>.yml file. > - add a new orm/releases//index.adoc file. It can be > empty except for the AsciiDoc metadata, but ideally you would put in there > a description of the minor. The content will appear in the "What's new" > section on the series page. For example: http://hibernate.org/ > search/releases/5.8/#whats-new. Obviously you'll want to keep yours > shorter, I'm just not good at summarizing ;) > > Thanks, > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 28 September 2017 at 19:08, andrea boriero > wrote: > >> Thanks a lot Guillaume and Yoann, great work. >> >> On 28 September 2017 at 17:41, Steve Ebersole >> wrote: >> >> > To be honest, I think that is perfect process Guillaume. I can now >> define >> > all that content and information in one place, which is a huge win. >> Which >> > make me think of a future nice-to-have we could consider... to drive the >> > release announcements (blog, emails, twitter, etc) from the content of a >> > series.yml. >> > >> > Thanks again for all your work on these changes. It really does look a >> lot >> > better I think. >> > >> > On Thu, Sep 28, 2017 at 11:16 AM Chris Cranford >> > wrote: >> > >> > > Thanks Guillaume. >> > > >> > > On 09/28/2017 10:25 AM, Guillaume Smet wrote: >> > > > Hi ORM guys, >> > > > >> > > > So with a new website comes new responsabilities. >> > > > >> > > > I updated the NoORM release process but I don't know where you put >> > these >> > > > information for ORM. >> > > > >> > > > So basically, when you release a new MAJOR version, you will have to >> > take >> > > > care of adding a *data/projects/orm/releases/series.yml *file and a >> > *orm* >> > > > */releases//index.adoc* file. >> > > > >> > > > Basically, you have to do the same thing for the release page than >> what >> > > you >> > > > already do with your custom documentation page. >> > > > >> > > > We already created them for the existing releases so you already >> have >> > > > templates you just have to adjust when publishing a new major >> release. >> > > > >> > > >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From guillaume.smet at gmail.com Fri Sep 29 13:57:07 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 29 Sep 2017 19:57:07 +0200 Subject: [hibernate-dev] New layout for in.relation.to Message-ID: Hi! I converted in.relation.to to the new layout and pushed it to http://staging.in.relation.to/ . Please take a look at it so that we can make progress quickly. Note that I still have some work to do on the mobile side. Will do once the dust has settled and we agree on the layout. The home page: http://staging.in.relation.to/ The blog post page: the idea here is to just present the content in a very minimal way: http://staging.in.relation.to/2017/09/25/hibernate-community-newsletter-2017-18/ While it's not validated, please be careful when cherry-picking your new blog post to production, don't merge my commits by mistake! Note that it doesn't change anything to the blog posts so business can continue as usual and you can safely cherry-pick your blog post from staging to production. Looking forward to your feedback. -- Guillaume From chris at hibernate.org Fri Sep 29 16:16:31 2017 From: chris at hibernate.org (Chris Cranford) Date: Fri, 29 Sep 2017 16:16:31 -0400 Subject: [hibernate-dev] New layout for in.relation.to In-Reply-To: References: Message-ID: <440ff667-2201-3908-f1bc-a50c6914e4c1@hibernate.org> Was curious if we would carry the new style to in.relation.to.? It looks superb. Chris On 09/29/2017 01:57 PM, Guillaume Smet wrote: > Hi! > > I converted in.relation.to to the new layout and pushed it to > http://staging.in.relation.to/ . > > Please take a look at it so that we can make progress quickly. > > Note that I still have some work to do on the mobile side. Will do once the > dust has settled and we agree on the layout. > > The home page: > http://staging.in.relation.to/ > > The blog post page: the idea here is to just present the content in a very > minimal way: > http://staging.in.relation.to/2017/09/25/hibernate-community-newsletter-2017-18/ > > While it's not validated, please be careful when cherry-picking your new > blog post to production, don't merge my commits by mistake! > > Note that it doesn't change anything to the blog posts so business can > continue as usual and you can safely cherry-pick your blog post from > staging to production. > > Looking forward to your feedback. > From steve at hibernate.org Fri Sep 29 17:47:49 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 29 Sep 2017 21:47:49 +0000 Subject: [hibernate-dev] New layout for in.relation.to In-Reply-To: <440ff667-2201-3908-f1bc-a50c6914e4c1@hibernate.org> References: <440ff667-2201-3908-f1bc-a50c6914e4c1@hibernate.org> Message-ID: +1 Great job (again) On Fri, Sep 29, 2017 at 3:36 PM Chris Cranford wrote: > Was curious if we would carry the new style to in.relation.to. > It looks superb. > > Chris > > On 09/29/2017 01:57 PM, Guillaume Smet wrote: > > Hi! > > > > I converted in.relation.to to the new layout and pushed it to > > http://staging.in.relation.to/ . > > > > Please take a look at it so that we can make progress quickly. > > > > Note that I still have some work to do on the mobile side. Will do once > the > > dust has settled and we agree on the layout. > > > > The home page: > > http://staging.in.relation.to/ > > > > The blog post page: the idea here is to just present the content in a > very > > minimal way: > > > http://staging.in.relation.to/2017/09/25/hibernate-community-newsletter-2017-18/ > > > > While it's not validated, please be careful when cherry-picking your new > > blog post to production, don't merge my commits by mistake! > > > > Note that it doesn't change anything to the blog posts so business can > > continue as usual and you can safely cherry-pick your blog post from > > staging to production. > > > > Looking forward to your feedback. > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev