Sorry for the late and probably irrelevant response... We're using an in-house Artifactory instance at a gig and it's been trash. I can't speak to the UI or management end, nor Bintray, but Artifactory's platform doesn't seem as polished (can't believe I just said that) or stable (can't believe I said that either) as Nexus (what is happening). I use OSSRH for some minor projects and have generally had decent luck -- including a few interactions with the support team that went well. OSSRH != JBoss Nexus, although I definitely understand the wounds... On 12/19/17 8:34 AM, Steve Ebersole wrote: > HHH-12172 is about moving away from the JBoss Nexus repo for publishing our > artifacts. There is an open question about which service to use instead - > Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory). > > Personally I think Artifactory is far superior of a UI/platform. We all > know Nexus from the JBoss deployment of it, and we have all generally had > nothing good to say about it. > > But I am wondering if anyone has practical experience with either, or knows > persons/projects tyay do and could share their experiences. E.g., even > though I prefer Bintray in almost every regard, I am very nervous that it > seems next to impossible to get help/support with it. The same may be true > with OSSRH - I don't know, hence why I am asking ;) > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Personally I'm neutral. I surely wouldn't want to manage our own Artifactory, but since JFrog will do that I'm not concerned about the platform management being horrible. Artifactory looks better, OSSRH has the benefit of possibly having better integration with Maven. There are some benefits on staying to JBoss's nexus though; not expressing a strong opinion but let's clarify these. # Stats We need download statistics, which I understand they all offer, but an absolute number is not as useful as being able to compare the numbers in one dashboard across various others of our projects. Also not looking forward to have to login to multiple systems to gather it all. # Quality control of artifacts I'm understanding that JBoss Nexus does several strict validations on our poms; sure they have been in the way as it's not nice to see such failures *during* a release but there's an upside to them as well. AFAIK OSSRH also has similar rules, but the JBoss team one has different ones, plus a deal with Sonatype to deem our stuff good "pre-approved" so we don't have to satisfy the Sonatype rules too. # Signing Also I'm understanding that to release on OSSRH we need to sign all artifacts; not a bad idea but it's quite more papework and key management. Such paperwork is handled for us by the JBoss Nexus team. We'd need to install GPG on our release servers, get a organization RSA key signed, and people stubbornly releasing manually will have to create a key each, and have it approved by Sonatype.

Not against migrating if this is what you all want - just making sure we're keeping these into account. Thanks, Sanne On 12 January 2018 at 02:47, Brett Meyer <brett(a)hibernate.org&gt; wrote: > Sorry for the late and probably irrelevant response... > > We're using an in-house Artifactory instance at a gig and it's been > trash. I can't speak to the UI or management end, nor Bintray, but > Artifactory's platform doesn't seem as polished (can't believe I just > said that) or stable (can't believe I said that either) as Nexus (what > is happening). > > I use OSSRH for some minor projects and have generally had decent luck > -- including a few interactions with the support team that went well. > OSSRH != JBoss Nexus, although I definitely understand the wounds... > > > On 12/19/17 8:34 AM, Steve Ebersole wrote: >> HHH-12172 is about moving away from the JBoss Nexus repo for publishing our >> artifacts. There is an open question about which service to use instead - >> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory). >> >> Personally I think Artifactory is far superior of a UI/platform. We all >> know Nexus from the JBoss deployment of it, and we have all generally had >> nothing good to say about it. >> >> But I am wondering if anyone has practical experience with either, or knows >> persons/projects tyay do and could share their experiences. E.g., even >> though I prefer Bintray in almost every regard, I am very nervous that it >> seems next to impossible to get help/support with it. The same may be true >> with OSSRH - I don't know, hence why I am asking ;) >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Bintray said they would increase the storage limit to 30G for Hibernate. However that limit is per organization, which is the top-level thing ( https://bintray.com/hibernate). I think we'd eat that up in no time, especially if other projects plan on moving to Bintray at any time. One way around that would be to have each project be its own Bintray organization. On Fri, Jan 12, 2018 at 7:33 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2018-01-12 12:59 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > > > Personally I'm neutral. I surely wouldn't want to manage our own > > Artifactory, but since JFrog will do that I'm not concerned about the > > platform management being horrible. > > > > Artifactory looks better, OSSRH has the benefit of possibly having > > better integration with Maven. > > > > There are some benefits on staying to JBoss's nexus though; not > > expressing a strong opinion but let's clarify these. > > > > # Stats > > We need download statistics, which I understand they all offer, but an > > absolute number is not as useful as being able to compare the numbers > > in one dashboard across various others of our projects. > > Also not looking forward to have to login to multiple systems to gather > it > > all. > > > > # Quality control of artifacts > > I'm understanding that JBoss Nexus does several strict validations on > > our poms; sure they have been in the way as it's not nice to see such > > failures *during* a release but there's an upside to them as well. > > AFAIK OSSRH also has similar rules, but the JBoss team one has > > different ones, plus a deal with Sonatype to deem our stuff good > > "pre-approved" so we don't have to satisfy the Sonatype rules too. > > > > # Signing > > Also I'm understanding that to release on OSSRH we need to sign all > > artifacts; not a bad idea but it's quite more papework and key > > management. Such paperwork is handled for us by the JBoss Nexus team. > > We'd need to install GPG on our release servers, get a organization > > RSA key signed, and people stubbornly releasing manually will have to > > create a key each, and have it approved by Sonatype. > > > > Debezium already is released to OSSRH from our CI server. May be worth > chatting to Jiri (added him to CC) about the details of setup. Note > there's > no need for key approval by Sonatype (at least last time I did it), you > only need to publish them to some key server which you can do all by > yourself. > > > > > > Not against migrating if this is what you all want - just making sure > > we're keeping these into account. > > > > Thanks, > > Sanne > > > > > > On 12 January 2018 at 02:47, Brett Meyer <brett(a)hibernate.org&gt; wrote: > > > Sorry for the late and probably irrelevant response... > > > > > > We're using an in-house Artifactory instance at a gig and it's been > > > trash. I can't speak to the UI or management end, nor Bintray, but > > > Artifactory's platform doesn't seem as polished (can't believe I just > > > said that) or stable (can't believe I said that either) as Nexus (what > > > is happening). > > > > > > I use OSSRH for some minor projects and have generally had decent luck > > > -- including a few interactions with the support team that went well. > > > OSSRH != JBoss Nexus, although I definitely understand the wounds... > > > > > > > > > On 12/19/17 8:34 AM, Steve Ebersole wrote: > > >> HHH-12172 is about moving away from the JBoss Nexus repo for > publishing > > our > > >> artifacts. There is an open question about which service to use > > instead - > > >> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory). > > >> > > >> Personally I think Artifactory is far superior of a UI/platform. We > all > > >> know Nexus from the JBoss deployment of it, and we have all generally > > had > > >> nothing good to say about it. > > >> > > >> But I am wondering if anyone has practical experience with either, or > > knows > > >> persons/projects tyay do and could share their experiences. E.g., > even > > >> though I prefer Bintray in almost every regard, I am very nervous > that > > it > > >> seems next to impossible to get help/support with it. The same may > be > > true > > >> with OSSRH - I don't know, hence why I am asking ;) > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On 19 January 2018 at 13:05, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I sat down and did some calculations to get a better idea of whether this is > feasible. 5.3.0.Beta1 had a total size of 135M (31M in "maven artifacts", > 104 in release bundles). At 30G limit, we'd be able to do ~222 releases > before we hit that limit (30 / .135 = 222.2222) > > So if only ORM is going to move to Bintray, I think the 30G limit is not a > hindrance. Do we see other projects moving away from publishing to JBoss > Nexus, and if so what publishing repo do y'all plan to use? Yes, as I said before I'm neutral on which one we use, but I was somewhat expecting us to all eventually use the same solution. Seems important to be consistent for sake of end user's experience, but also for us to share tooling, scripts, practices, lessons learned.. That said we didn't start looking at that in other Hibernate projects so there would certainly be a lag. The work we're doing on feature-packs might significantly reduce the size of each release, but I think it will only have an impact on the "maven artifacts", which according to your estimates are not the main issue. Maybe we could stick to sourceforge for the release bundles? We all seems to agree that "release bundles" are meant for the more "old school" devs; I'd say they won't be swayed away from Sourceforge anyway, and we should probably keep some continuity there. That would also happen to solve the storage limit problem? Thanks, Sanne > > > On Thu, Jan 18, 2018 at 2:21 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> >> Bintray said they would increase the storage limit to 30G for Hibernate. >> However that limit is per organization, which is the top-level thing >> (https://bintray.com/hibernate). I think we'd eat that up in no time, >> especially if other projects plan on moving to Bintray at any time. >> >> One way around that would be to have each project be its own Bintray >> organization. >> >> >> On Fri, Jan 12, 2018 at 7:33 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >> wrote: >>> >>> 2018-01-12 12:59 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >>> >>> > Personally I'm neutral. I surely wouldn't want to manage our own >>> > Artifactory, but since JFrog will do that I'm not concerned about the >>> > platform management being horrible. >>> > >>> > Artifactory looks better, OSSRH has the benefit of possibly having >>> > better integration with Maven. >>> > >>> > There are some benefits on staying to JBoss's nexus though; not >>> > expressing a strong opinion but let's clarify these. >>> > >>> > # Stats >>> > We need download statistics, which I understand they all offer, but an >>> > absolute number is not as useful as being able to compare the numbers >>> > in one dashboard across various others of our projects. >>> > Also not looking forward to have to login to multiple systems to gather >>> > it >>> > all. >>> > >>> > # Quality control of artifacts >>> > I'm understanding that JBoss Nexus does several strict validations on >>> > our poms; sure they have been in the way as it's not nice to see such >>> > failures *during* a release but there's an upside to them as well. >>> > AFAIK OSSRH also has similar rules, but the JBoss team one has >>> > different ones, plus a deal with Sonatype to deem our stuff good >>> > "pre-approved" so we don't have to satisfy the Sonatype rules too. >>> > >>> > # Signing >>> > Also I'm understanding that to release on OSSRH we need to sign all >>> > artifacts; not a bad idea but it's quite more papework and key >>> > management. Such paperwork is handled for us by the JBoss Nexus team. >>> > We'd need to install GPG on our release servers, get a organization >>> > RSA key signed, and people stubbornly releasing manually will have to >>> > create a key each, and have it approved by Sonatype. >>> > >>> >>> Debezium already is released to OSSRH from our CI server. May be worth >>> chatting to Jiri (added him to CC) about the details of setup. Note >>> there's >>> no need for key approval by Sonatype (at least last time I did it), you >>> only need to publish them to some key server which you can do all by >>> yourself. >>> >>> >>> > >>> > Not against migrating if this is what you all want - just making sure >>> > we're keeping these into account. >>> > >>> > Thanks, >>> > Sanne >>> > >>> > >>> > On 12 January 2018 at 02:47, Brett Meyer <brett(a)hibernate.org&gt; wrote: >>> > > Sorry for the late and probably irrelevant response... >>> > > >>> > > We're using an in-house Artifactory instance at a gig and it's been >>> > > trash. I can't speak to the UI or management end, nor Bintray, but >>> > > Artifactory's platform doesn't seem as polished (can't believe I just >>> > > said that) or stable (can't believe I said that either) as Nexus >>> > > (what >>> > > is happening). >>> > > >>> > > I use OSSRH for some minor projects and have generally had decent >>> > > luck >>> > > -- including a few interactions with the support team that went well. >>> > > OSSRH != JBoss Nexus, although I definitely understand the wounds... >>> > > >>> > > >>> > > On 12/19/17 8:34 AM, Steve Ebersole wrote: >>> > >> HHH-12172 is about moving away from the JBoss Nexus repo for >>> > >> publishing >>> > our >>> > >> artifacts. There is an open question about which service to use >>> > instead - >>> > >> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory). >>> > >> >>> > >> Personally I think Artifactory is far superior of a UI/platform. We >>> > >> all >>> > >> know Nexus from the JBoss deployment of it, and we have all >>> > >> generally >>> > had >>> > >> nothing good to say about it. >>> > >> >>> > >> But I am wondering if anyone has practical experience with either, >>> > >> or >>> > knows >>> > >> persons/projects tyay do and could share their experiences. E.g., >>> > >> even >>> > >> though I prefer Bintray in almost every regard, I am very nervous >>> > >> that >>> > it >>> > >> seems next to impossible to get help/support with it. The same may >>> > >> be >>> > true >>> > >> with OSSRH - I don't know, hence why I am asking ;) >>> > >> _______________________________________________ >>> > >> hibernate-dev mailing list >>> > >> hibernate-dev(a)lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev(a)lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 19 January 2018 at 14:56, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I think it is reasonable to only publish the maven artifacts to Bintray and > continue to publish the bundles to SourceForge. Great, so that means we can have about a thousand releases on Bintray; should be enough for all our projects for at least 10 years. Thanks, Sanne > > > On Fri, Jan 19, 2018 at 7:19 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> >> On 19 January 2018 at 13:05, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> > I sat down and did some calculations to get a better idea of whether >> > this is >> > feasible. 5.3.0.Beta1 had a total size of 135M (31M in "maven >> > artifacts", >> > 104 in release bundles). At 30G limit, we'd be able to do ~222 releases >> > before we hit that limit (30 / .135 = 222.2222) >> > >> > So if only ORM is going to move to Bintray, I think the 30G limit is not >> > a >> > hindrance. Do we see other projects moving away from publishing to >> > JBoss >> > Nexus, and if so what publishing repo do y'all plan to use? >> >> Yes, as I said before I'm neutral on which one we use, but I was >> somewhat expecting us to all eventually use the same solution. >> Seems important to be consistent for sake of end user's experience, >> but also for us to share tooling, scripts, practices, lessons >> learned.. >> >> That said we didn't start looking at that in other Hibernate projects >> so there would certainly be a lag. >> >> The work we're doing on feature-packs might significantly reduce the >> size of each release, but I think it will only have an impact on the >> "maven artifacts", which according to your estimates are not the main >> issue. >> >> Maybe we could stick to sourceforge for the release bundles? We all >> seems to agree that "release bundles" are meant for the more "old >> school" devs; I'd say they won't be swayed away from Sourceforge >> anyway, and we should probably keep some continuity there. >> That would also happen to solve the storage limit problem? >> >> Thanks, >> Sanne >> >> >> >> >> > >> > >> > On Thu, Jan 18, 2018 at 2:21 PM Steve Ebersole <steve(a)hibernate.org&gt; >> > wrote: >> >> >> >> Bintray said they would increase the storage limit to 30G for >> >> Hibernate. >> >> However that limit is per organization, which is the top-level thing >> >> (https://bintray.com/hibernate). I think we'd eat that up in no time, >> >> especially if other projects plan on moving to Bintray at any time. >> >> >> >> One way around that would be to have each project be its own Bintray >> >> organization. >> >> >> >> >> >> On Fri, Jan 12, 2018 at 7:33 AM Gunnar Morling <gunnar(a)hibernate.org > >> >> wrote: >> >>> >> >>> 2018-01-12 12:59 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >>> >> >>> > Personally I'm neutral. I surely wouldn't want to manage our own >> >>> > Artifactory, but since JFrog will do that I'm not concerned about >> >>> > the >> >>> > platform management being horrible. >> >>> > >> >>> > Artifactory looks better, OSSRH has the benefit of possibly having >> >>> > better integration with Maven. >> >>> > >> >>> > There are some benefits on staying to JBoss's nexus though; not >> >>> > expressing a strong opinion but let's clarify these. >> >>> > >> >>> > # Stats >> >>> > We need download statistics, which I understand they all offer, but >> >>> > an >> >>> > absolute number is not as useful as being able to compare the >> >>> > numbers >> >>> > in one dashboard across various others of our projects. >> >>> > Also not looking forward to have to login to multiple systems to >> >>> > gather >> >>> > it >> >>> > all. >> >>> > >> >>> > # Quality control of artifacts >> >>> > I'm understanding that JBoss Nexus does several strict validations >> >>> > on >> >>> > our poms; sure they have been in the way as it's not nice to see >> >>> > such >> >>> > failures *during* a release but there's an upside to them as well. >> >>> > AFAIK OSSRH also has similar rules, but the JBoss team one has >> >>> > different ones, plus a deal with Sonatype to deem our stuff good >> >>> > "pre-approved" so we don't have to satisfy the Sonatype rules too. >> >>> > >> >>> > # Signing >> >>> > Also I'm understanding that to release on OSSRH we need to sign all >> >>> > artifacts; not a bad idea but it's quite more papework and key >> >>> > management. Such paperwork is handled for us by the JBoss Nexus >> >>> > team. >> >>> > We'd need to install GPG on our release servers, get a organization >> >>> > RSA key signed, and people stubbornly releasing manually will have >> >>> > to >> >>> > create a key each, and have it approved by Sonatype. >> >>> > >> >>> >> >>> Debezium already is released to OSSRH from our CI server. May be worth >> >>> chatting to Jiri (added him to CC) about the details of setup. Note >> >>> there's >> >>> no need for key approval by Sonatype (at least last time I did it), >> >>> you >> >>> only need to publish them to some key server which you can do all by >> >>> yourself. >> >>> >> >>> >> >>> > >> >>> > Not against migrating if this is what you all want - just making >> >>> > sure >> >>> > we're keeping these into account. >> >>> > >> >>> > Thanks, >> >>> > Sanne >> >>> > >> >>> > >> >>> > On 12 January 2018 at 02:47, Brett Meyer <brett(a)hibernate.org&gt; >> >>> > wrote: >> >>> > > Sorry for the late and probably irrelevant response... >> >>> > > >> >>> > > We're using an in-house Artifactory instance at a gig and it's >> >>> > > been >> >>> > > trash. I can't speak to the UI or management end, nor Bintray, >> >>> > > but >> >>> > > Artifactory's platform doesn't seem as polished (can't believe I >> >>> > > just >> >>> > > said that) or stable (can't believe I said that either) as Nexus >> >>> > > (what >> >>> > > is happening). >> >>> > > >> >>> > > I use OSSRH for some minor projects and have generally had decent >> >>> > > luck >> >>> > > -- including a few interactions with the support team that went >> >>> > > well. >> >>> > > OSSRH != JBoss Nexus, although I definitely understand the >> >>> > > wounds... >> >>> > > >> >>> > > >> >>> > > On 12/19/17 8:34 AM, Steve Ebersole wrote: >> >>> > >> HHH-12172 is about moving away from the JBoss Nexus repo for >> >>> > >> publishing >> >>> > our >> >>> > >> artifacts. There is an open question about which service to use >> >>> > instead - >> >>> > >> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory). >> >>> > >> >> >>> > >> Personally I think Artifactory is far superior of a UI/platform. >> >>> > >> We >> >>> > >> all >> >>> > >> know Nexus from the JBoss deployment of it, and we have all >> >>> > >> generally >> >>> > had >> >>> > >> nothing good to say about it. >> >>> > >> >> >>> > >> But I am wondering if anyone has practical experience with >> >>> > >> either, >> >>> > >> or >> >>> > knows >> >>> > >> persons/projects tyay do and could share their experiences. >> >>> > >> E.g., >> >>> > >> even >> >>> > >> though I prefer Bintray in almost every regard, I am very nervous >> >>> > >> that >> >>> > it >> >>> > >> seems next to impossible to get help/support with it. The same >> >>> > >> may >> >>> > >> be >> >>> > true >> >>> > >> with OSSRH - I don't know, hence why I am asking ;) >> >>> > >> _______________________________________________ >> >>> > >> hibernate-dev mailing list >> >>> > >> hibernate-dev(a)lists.jboss.org >> >>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> > > >> >>> > > >> >>> > > _______________________________________________ >> >>> > > hibernate-dev mailing list >> >>> > > hibernate-dev(a)lists.jboss.org >> >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> > _______________________________________________ >> >>> > hibernate-dev mailing list >> >>> > hibernate-dev(a)lists.jboss.org >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> > >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev(a)lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Fri, Jan 19, 2018 at 5:15 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Agreed. So unless someone has an argument against, I will plan on > switching over to Bintray publishing for the next 5.3 release. > Not an argument against but just to be sure, you will be able to synchronize artifacts from the org.hibernate groupId from Bintray to Central even with the others (Validator, Search) coming from the JBoss Nexus? -- Guillaume

On Fri, Jan 19, 2018 at 5:33 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > yessir > Nice, thanks for confirming.

no objection On 24 January 2018 at 15:51, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Do y'all mind then if I get rid of the hibernate/bundles[1] repo? It's a > "generic" Artifactory repo meant to hold release bundles. ORM[2] and > OGM[3] both have played with it, as we both have versions published there. > But for ORM at least those are also on SourceForge and its not important > that I keep this around. > > [1] https://bintray.com/hibernate/bundles > [2] https://bintray.com/hibernate/bundles/hibernate-orm > [3] https://bintray.com/hibernate/bundles/hibernate-ogm > > > On Fri, Jan 19, 2018 at 10:38 AM Guillaume Smet <guillaume.smet(a)gmail.com > > > wrote: > > > On Fri, Jan 19, 2018 at 5:33 PM, Steve Ebersole <steve(a)hibernate.org&gt; > > wrote: > > > >> yessir > >> > > > > Nice, thanks for confirming. > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >