Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
Hi, That's a great initiative. Have you considered to make this a more general effort, esp. should this rather be a repo / group id under the WildFly reign instead of Hibernate? As you say, the modules may be interesting to people not using Hibernate Search, so a group id not tied to Hibernate would be less confusing: org. wildfly.modules.lucene. --Gunnar 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : > Hi all, > > I'm proposing the use of the `org.hibernate.lucene-modules` group id > for the stuff which we'll be releasing from this repository: > - https://github.com/hibernate/lucene-modules > > Context: Hibernate Search has been packaging Apache Lucene as a > WildFly module, essentially including the Lucene modules as part of > the Hibernate Search modules. > > We want to separate these modules, for various reasons; the main > driver being the build of Infinispan is much simpler if they can > source the Lucene modules "out of band" from the Search release > version. Sometimes we need some more flexibility, and it's getting > close to mission impossible to workaround the tight coupling. > > This might also help other projects use Lucene when not necessarily > interested in Hibernate Search, or in using the Lucene versions which > Search would allow (a subset of the Lucene releases). > > Finally, since we release these modules with name "org.apache.lucene", > it might just make sense for them to be independent and just contain > Apache Lucene. > > If you're interested more details, have a look at PR number 1: > - https://github.com/hibernate/lucene-modules/pull/1/files > > In Hibernate Search this would imply: > - > https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
On 17 February 2017 at 09:42, Gunnar Morling wrote: > Hi, > > That's a great initiative. Thanks! Credit to Gustavo - he created the project idea - I actually failed to follow up for a long time. I wasn't fully convinced, especially as we were waiting for directions on the area, but convinced now that we should at least split it out even if we don't know the recommended modules format and WildFly strategies going forward. > Have you considered to make this a more > general effort, esp. should this rather be a repo / group id under the > WildFly reign instead of Hibernate? Yes, the "org.hibernate" organization prefix is a deliberate choice. The main reason is that we're the ones maintaining and - hopefully - releasing this module set. Proper organization namespacing is important within the Maven modules world. N.B. the modules id still is "org.apache.lucene": only the Maven group id is prefixed by the Hibernate id. My intent is really to "sign" the provenance only, while the package purpose is general. > > As you say, the modules may be interesting to people not using > Hibernate Search, so a group id not tied to Hibernate would be less > confusing: org. wildfly.modules.lucene. In an ideal world, I would contribute this to the Lucene project: what people need is such a moduleset for each single Lucene release, so you might as well have the Lucene release process provide one. But I think it's premature for that; not least because: - I doubt this format is yet popular enough to be a compelling feature for the Lucene team - we need them to be "retro-active", i.e. to re-package existing Lucene versions - should we use the patch format instead? A feature pack? A fraction? etc.. Many such details need to be ironed out, then I'd be happy to propose it to the Lucene project for inclusion, but this might take some year yet and we need this right now. -- Sanne > > --Gunnar > > > > 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >> Hi all, >> >> I'm proposing the use of the `org.hibernate.lucene-modules` group id >> for the stuff which we'll be releasing from this repository: >> - https://github.com/hibernate/lucene-modules >> >> Context: Hibernate Search has been packaging Apache Lucene as a >> WildFly module, essentially including the Lucene modules as part of >> the Hibernate Search modules. >> >> We want to separate these modules, for various reasons; the main >> driver being the build of Infinispan is much simpler if they can >> source the Lucene modules "out of band" from the Search release >> version. Sometimes we need some more flexibility, and it's getting >> close to mission impossible to workaround the tight coupling. >> >> This might also help other projects use Lucene when not necessarily >> interested in Hibernate Search, or in using the Lucene versions which >> Search would allow (a subset of the Lucene releases). >> >> Finally, since we release these modules with name "org.apache.lucene", >> it might just make sense for them to be independent and just contain >> Apache Lucene. >> >> If you're interested more details, have a look at PR number 1: >> - https://github.com/hibernate/lucene-modules/pull/1/files >> >> In Hibernate Search this would imply: >> - >> https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >> >> Thanks, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Starting 5.2.8 release
Please do not push anything to master branch. Thanks, Andrea ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
2017-02-17 11:04 GMT+01:00 Sanne Grinovero : > On 17 February 2017 at 09:42, Gunnar Morling wrote: >> Hi, >> >> That's a great initiative. > > Thanks! Credit to Gustavo - he created the project idea - I actually > failed to follow > up for a long time. > > I wasn't fully convinced, especially as we were waiting for directions > on the area, > but convinced now that we should at least split it out even if we don't know > the recommended modules format and WildFly strategies going forward. > >> Have you considered to make this a more >> general effort, esp. should this rather be a repo / group id under the >> WildFly reign instead of Hibernate? > > Yes, the "org.hibernate" organization prefix is a deliberate choice. > > The main reason is that we're the ones maintaining and - hopefully - releasing > this module set. > Proper organization namespacing is important within the Maven modules world. I don't see why we couldn't maintain it when using something under "org.wildfly". Yes, it'll require a bit more work upfront to agree on it. But ideally, WF could even pick up the modules from that project for its own distribution, so it seems like a good fit. > > N.B. the modules id still is "org.apache.lucene": only the Maven group id > is prefixed by the Hibernate id. My intent is really to "sign" the provenance > only, while the package purpose is general. > >> >> As you say, the modules may be interesting to people not using >> Hibernate Search, so a group id not tied to Hibernate would be less >> confusing: org. wildfly.modules.lucene. > > In an ideal world, I would contribute this to the Lucene project: > what people need is such a moduleset for each single Lucene release, > so you might as well have the Lucene release process provide one. I don't think it belongs into Lucene. At least I wouldn't like the idea of maintaining support for downstream integrators like this, were I a Lucene developer :) > > But I think it's premature for that; not least because: > - I doubt this format is yet popular enough to be a compelling > feature for the Lucene team > - we need them to be "retro-active", i.e. to re-package existing > Lucene versions > - should we use the patch format instead? A feature pack? A fraction? etc.. > > Many such details need to be ironed out, then I'd be happy to propose > it to the Lucene > project for inclusion, but this might take some year yet and we need > this right now. > > -- Sanne > >> >> --Gunnar >> >> >> >> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>> Hi all, >>> >>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>> for the stuff which we'll be releasing from this repository: >>> - https://github.com/hibernate/lucene-modules >>> >>> Context: Hibernate Search has been packaging Apache Lucene as a >>> WildFly module, essentially including the Lucene modules as part of >>> the Hibernate Search modules. >>> >>> We want to separate these modules, for various reasons; the main >>> driver being the build of Infinispan is much simpler if they can >>> source the Lucene modules "out of band" from the Search release >>> version. Sometimes we need some more flexibility, and it's getting >>> close to mission impossible to workaround the tight coupling. >>> >>> This might also help other projects use Lucene when not necessarily >>> interested in Hibernate Search, or in using the Lucene versions which >>> Search would allow (a subset of the Lucene releases). >>> >>> Finally, since we release these modules with name "org.apache.lucene", >>> it might just make sense for them to be independent and just contain >>> Apache Lucene. >>> >>> If you're interested more details, have a look at PR number 1: >>> - https://github.com/hibernate/lucene-modules/pull/1/files >>> >>> In Hibernate Search this would imply: >>> - >>> https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >>> >>> Thanks, >>> Sanne >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
On 17 February 2017 at 10:16, Gunnar Morling wrote: > 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : >> On 17 February 2017 at 09:42, Gunnar Morling wrote: >>> Hi, >>> >>> That's a great initiative. >> >> Thanks! Credit to Gustavo - he created the project idea - I actually >> failed to follow >> up for a long time. >> >> I wasn't fully convinced, especially as we were waiting for directions >> on the area, >> but convinced now that we should at least split it out even if we don't know >> the recommended modules format and WildFly strategies going forward. >> >>> Have you considered to make this a more >>> general effort, esp. should this rather be a repo / group id under the >>> WildFly reign instead of Hibernate? >> >> Yes, the "org.hibernate" organization prefix is a deliberate choice. >> >> The main reason is that we're the ones maintaining and - hopefully - >> releasing >> this module set. >> Proper organization namespacing is important within the Maven modules world. > > I don't see why we couldn't maintain it when using something under > "org.wildfly". Yes, it'll require a bit more work upfront to agree on > it. But ideally, WF could even pick up the modules from that project > for its own distribution, so it seems like a good fit. Let's assume we do that. You'd also want me to move this repository to github.com/wildfly ? I'm concerned we're making this maintenance much more "out of reach" for us, just to polish an identifier. For example, the pom metadata I created suggests using this mailing list for any comment, and while I read the WildFly ML periodically, I don't read it as often: - https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 Mind you, it's not the goal of this project to be popular. It just has to work for our purposes: if having the wrong identifier will lose it some % of users I will still sleep at night just fine. Possibly being useful to other people is nice, but is secondary. > >> >> N.B. the modules id still is "org.apache.lucene": only the Maven group id >> is prefixed by the Hibernate id. My intent is really to "sign" the provenance >> only, while the package purpose is general. >> >>> >>> As you say, the modules may be interesting to people not using >>> Hibernate Search, so a group id not tied to Hibernate would be less >>> confusing: org. wildfly.modules.lucene. >> >> In an ideal world, I would contribute this to the Lucene project: >> what people need is such a moduleset for each single Lucene release, >> so you might as well have the Lucene release process provide one. > > I don't think it belongs into Lucene. At least I wouldn't like the > idea of maintaining support for downstream integrators like this, were > I a Lucene developer :) > >> >> But I think it's premature for that; not least because: >> - I doubt this format is yet popular enough to be a compelling >> feature for the Lucene team >> - we need them to be "retro-active", i.e. to re-package existing >> Lucene versions >> - should we use the patch format instead? A feature pack? A fraction? etc.. >> >> Many such details need to be ironed out, then I'd be happy to propose >> it to the Lucene >> project for inclusion, but this might take some year yet and we need >> this right now. >> >> -- Sanne >> >>> >>> --Gunnar >>> >>> >>> >>> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : Hi all, I'm proposing the use of the `org.hibernate.lucene-modules` group id for the stuff which we'll be releasing from this repository: - https://github.com/hibernate/lucene-modules Context: Hibernate Search has been packaging Apache Lucene as a WildFly module, essentially including the Lucene modules as part of the Hibernate Search modules. We want to separate these modules, for various reasons; the main driver being the build of Infinispan is much simpler if they can source the Lucene modules "out of band" from the Search release version. Sometimes we need some more flexibility, and it's getting close to mission impossible to workaround the tight coupling. This might also help other projects use Lucene when not necessarily interested in Hibernate Search, or in using the Lucene versions which Search would allow (a subset of the Lucene releases). Finally, since we release these modules with name "org.apache.lucene", it might just make sense for them to be independent and just contain Apache Lucene. If you're interested more details, have a look at PR number 1: - https://github.com/hibernate/lucene-modules/pull/1/files In Hibernate Search this would imply: - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/li
Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
2017-02-17 11:30 GMT+01:00 Sanne Grinovero : > On 17 February 2017 at 10:16, Gunnar Morling wrote: >> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : >>> On 17 February 2017 at 09:42, Gunnar Morling wrote: Hi, That's a great initiative. >>> >>> Thanks! Credit to Gustavo - he created the project idea - I actually >>> failed to follow >>> up for a long time. >>> >>> I wasn't fully convinced, especially as we were waiting for directions >>> on the area, >>> but convinced now that we should at least split it out even if we don't know >>> the recommended modules format and WildFly strategies going forward. >>> Have you considered to make this a more general effort, esp. should this rather be a repo / group id under the WildFly reign instead of Hibernate? >>> >>> Yes, the "org.hibernate" organization prefix is a deliberate choice. >>> >>> The main reason is that we're the ones maintaining and - hopefully - >>> releasing >>> this module set. >>> Proper organization namespacing is important within the Maven modules world. >> >> I don't see why we couldn't maintain it when using something under >> "org.wildfly". Yes, it'll require a bit more work upfront to agree on >> it. But ideally, WF could even pick up the modules from that project >> for its own distribution, so it seems like a good fit. > > Let's assume we do that. You'd also want me to move this repository to > github.com/wildfly ? Yes, that'd be idea. > > I'm concerned we're making this maintenance much more "out of reach" for us, > just to polish an identifier. It's more than that, it'd also allow WF to consume these modules instead of maintaining them twice. > > For example, the pom metadata I created suggests using this mailing > list for any comment, > and while I read the WildFly ML periodically, I don't read it as often: > - > https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 Sorry, but I wouldn't base the decision on which mailing list to read. > > Mind you, it's not the goal of this project to be popular. > It just has to work for our purposes: if having the wrong identifier > will lose it some % of users I will still sleep at night just fine. > Possibly being useful to other people is nice, but is secondary. Ok, it sounded general purpose to me in the beginning. The usage by WF remains. Would be interesting to hear what others think. > >> >>> >>> N.B. the modules id still is "org.apache.lucene": only the Maven group id >>> is prefixed by the Hibernate id. My intent is really to "sign" the >>> provenance >>> only, while the package purpose is general. >>> As you say, the modules may be interesting to people not using Hibernate Search, so a group id not tied to Hibernate would be less confusing: org. wildfly.modules.lucene. >>> >>> In an ideal world, I would contribute this to the Lucene project: >>> what people need is such a moduleset for each single Lucene release, >>> so you might as well have the Lucene release process provide one. >> >> I don't think it belongs into Lucene. At least I wouldn't like the >> idea of maintaining support for downstream integrators like this, were >> I a Lucene developer :) >> >>> >>> But I think it's premature for that; not least because: >>> - I doubt this format is yet popular enough to be a compelling >>> feature for the Lucene team >>> - we need them to be "retro-active", i.e. to re-package existing >>> Lucene versions >>> - should we use the patch format instead? A feature pack? A fraction? etc.. >>> >>> Many such details need to be ironed out, then I'd be happy to propose >>> it to the Lucene >>> project for inclusion, but this might take some year yet and we need >>> this right now. >>> >>> -- Sanne >>> --Gunnar 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : > Hi all, > > I'm proposing the use of the `org.hibernate.lucene-modules` group id > for the stuff which we'll be releasing from this repository: > - https://github.com/hibernate/lucene-modules > > Context: Hibernate Search has been packaging Apache Lucene as a > WildFly module, essentially including the Lucene modules as part of > the Hibernate Search modules. > > We want to separate these modules, for various reasons; the main > driver being the build of Infinispan is much simpler if they can > source the Lucene modules "out of band" from the Search release > version. Sometimes we need some more flexibility, and it's getting > close to mission impossible to workaround the tight coupling. > > This might also help other projects use Lucene when not necessarily > interested in Hibernate Search, or in using the Lucene versions which > Search would allow (a subset of the Lucene releases). > > Finally, since we release these modules with name "org.apache.lucene", > it might just make sense for them to be independent and just co
Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
On 17 February 2017 at 11:04, Gunnar Morling wrote: > 2017-02-17 11:30 GMT+01:00 Sanne Grinovero : >> On 17 February 2017 at 10:16, Gunnar Morling wrote: >>> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : On 17 February 2017 at 09:42, Gunnar Morling wrote: > Hi, > > That's a great initiative. Thanks! Credit to Gustavo - he created the project idea - I actually failed to follow up for a long time. I wasn't fully convinced, especially as we were waiting for directions on the area, but convinced now that we should at least split it out even if we don't know the recommended modules format and WildFly strategies going forward. > Have you considered to make this a more > general effort, esp. should this rather be a repo / group id under the > WildFly reign instead of Hibernate? Yes, the "org.hibernate" organization prefix is a deliberate choice. The main reason is that we're the ones maintaining and - hopefully - releasing this module set. Proper organization namespacing is important within the Maven modules world. >>> >>> I don't see why we couldn't maintain it when using something under >>> "org.wildfly". Yes, it'll require a bit more work upfront to agree on >>> it. But ideally, WF could even pick up the modules from that project >>> for its own distribution, so it seems like a good fit. >> >> Let's assume we do that. You'd also want me to move this repository to >> github.com/wildfly ? > > Yes, that'd be idea. > >> >> I'm concerned we're making this maintenance much more "out of reach" for us, >> just to polish an identifier. > > It's more than that, it'd also allow WF to consume these modules > instead of maintaining them twice. They will not consume it. Remember the prime directive? - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html I'm assuming the previous direction stands, and I'd like to move forward until we know better. This initiative has been stuck for more than a year already, waiting for such input or a better home. > >> >> For example, the pom metadata I created suggests using this mailing >> list for any comment, >> and while I read the WildFly ML periodically, I don't read it as often: >> - >> https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 > > Sorry, but I wouldn't base the decision on which mailing list to read. > >> >> Mind you, it's not the goal of this project to be popular. >> It just has to work for our purposes: if having the wrong identifier >> will lose it some % of users I will still sleep at night just fine. >> Possibly being useful to other people is nice, but is secondary. > > Ok, it sounded general purpose to me in the beginning. The usage by WF > remains. > > Would be interesting to hear what others think. > >> >>> N.B. the modules id still is "org.apache.lucene": only the Maven group id is prefixed by the Hibernate id. My intent is really to "sign" the provenance only, while the package purpose is general. > > As you say, the modules may be interesting to people not using > Hibernate Search, so a group id not tied to Hibernate would be less > confusing: org. wildfly.modules.lucene. In an ideal world, I would contribute this to the Lucene project: what people need is such a moduleset for each single Lucene release, so you might as well have the Lucene release process provide one. >>> >>> I don't think it belongs into Lucene. At least I wouldn't like the >>> idea of maintaining support for downstream integrators like this, were >>> I a Lucene developer :) >>> But I think it's premature for that; not least because: - I doubt this format is yet popular enough to be a compelling feature for the Lucene team - we need them to be "retro-active", i.e. to re-package existing Lucene versions - should we use the patch format instead? A feature pack? A fraction? etc.. Many such details need to be ironed out, then I'd be happy to propose it to the Lucene project for inclusion, but this might take some year yet and we need this right now. -- Sanne > > --Gunnar > > > > 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >> Hi all, >> >> I'm proposing the use of the `org.hibernate.lucene-modules` group id >> for the stuff which we'll be releasing from this repository: >> - https://github.com/hibernate/lucene-modules >> >> Context: Hibernate Search has been packaging Apache Lucene as a >> WildFly module, essentially including the Lucene modules as part of >> the Hibernate Search modules. >> >> We want to separate these modules, for various reasons; the main >> driver being the build of Infinispan is much simpler if they can >> source the Lucene modules "out of band" fr
Re: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules
I've sent a related proposal to the WildFly mailing list: - http://lists.jboss.org/pipermail/wildfly-dev/2017-February/005768.html If they welcome it, that's great. Otherwise I'll release this pack as-is, but for sure ownership is not cast in stone. Thanks, Sanne On 17 February 2017 at 11:10, Sanne Grinovero wrote: > On 17 February 2017 at 11:04, Gunnar Morling wrote: >> 2017-02-17 11:30 GMT+01:00 Sanne Grinovero : >>> On 17 February 2017 at 10:16, Gunnar Morling wrote: 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : > On 17 February 2017 at 09:42, Gunnar Morling wrote: >> Hi, >> >> That's a great initiative. > > Thanks! Credit to Gustavo - he created the project idea - I actually > failed to follow > up for a long time. > > I wasn't fully convinced, especially as we were waiting for directions > on the area, > but convinced now that we should at least split it out even if we don't > know > the recommended modules format and WildFly strategies going forward. > >> Have you considered to make this a more >> general effort, esp. should this rather be a repo / group id under the >> WildFly reign instead of Hibernate? > > Yes, the "org.hibernate" organization prefix is a deliberate choice. > > The main reason is that we're the ones maintaining and - hopefully - > releasing > this module set. > Proper organization namespacing is important within the Maven modules > world. I don't see why we couldn't maintain it when using something under "org.wildfly". Yes, it'll require a bit more work upfront to agree on it. But ideally, WF could even pick up the modules from that project for its own distribution, so it seems like a good fit. >>> >>> Let's assume we do that. You'd also want me to move this repository to >>> github.com/wildfly ? >> >> Yes, that'd be idea. >> >>> >>> I'm concerned we're making this maintenance much more "out of reach" for us, >>> just to polish an identifier. >> >> It's more than that, it'd also allow WF to consume these modules >> instead of maintaining them twice. > > They will not consume it. Remember the prime directive? > > - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html > > I'm assuming the previous direction stands, and I'd like to move > forward until we know better. > > This initiative has been stuck for more than a year already, waiting > for such input or a better home. > >> >>> >>> For example, the pom metadata I created suggests using this mailing >>> list for any comment, >>> and while I read the WildFly ML periodically, I don't read it as often: >>> - >>> https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 >> >> Sorry, but I wouldn't base the decision on which mailing list to read. >> >>> >>> Mind you, it's not the goal of this project to be popular. >>> It just has to work for our purposes: if having the wrong identifier >>> will lose it some % of users I will still sleep at night just fine. >>> Possibly being useful to other people is nice, but is secondary. >> >> Ok, it sounded general purpose to me in the beginning. The usage by WF >> remains. >> >> Would be interesting to hear what others think. >> >>> > > N.B. the modules id still is "org.apache.lucene": only the Maven group id > is prefixed by the Hibernate id. My intent is really to "sign" the > provenance > only, while the package purpose is general. > >> >> As you say, the modules may be interesting to people not using >> Hibernate Search, so a group id not tied to Hibernate would be less >> confusing: org. wildfly.modules.lucene. > > In an ideal world, I would contribute this to the Lucene project: > what people need is such a moduleset for each single Lucene release, > so you might as well have the Lucene release process provide one. I don't think it belongs into Lucene. At least I wouldn't like the idea of maintaining support for downstream integrators like this, were I a Lucene developer :) > > But I think it's premature for that; not least because: > - I doubt this format is yet popular enough to be a compelling > feature for the Lucene team > - we need them to be "retro-active", i.e. to re-package existing > Lucene versions > - should we use the patch format instead? A feature pack? A fraction? > etc.. > > Many such details need to be ironed out, then I'd be happy to propose > it to the Lucene > project for inclusion, but this might take some year yet and we need > this right now. > > -- Sanne > >> >> --Gunnar >> >> >> >> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>> Hi all, >>> >>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>> for the stuff which we'll be releasing from this r
[hibernate-dev] Hibernate ORM 5.2.8.Final has been released
For details: http://in.relation.to/2017/02/17/hibernate-orm-528-final-release ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] @Where clause and finding an entity
Hi, I'm testing the way @Where annotation works, and I found the following scenario: If we have an entity annotated like this: @Where(clause = "deleted = false") @SQLDelete(sql = "UPDATE tag set deleted = true where id = ?") If the entity was previously deleted and I try to load it in a new Persistence Context: assertNull(entityManager.find(Tag.class, "Misc")); The entity is fetched successfully, and the assert fails. The only way to make it work is if I override the load query using the @Loader annotation: @Loader(namedQuery = "findTagById") @NamedQuery(name = "findTagById", query = "select t from Tag t where t.id = ? and t.deleted = false") Is this the expected behavior or is it a bug? Vlad ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
For completeness: https://hibernate.atlassian.net/browse/HHH-11501. Let's
continue any discussion there...
On Mon, Oct 24, 2016 at 6:40 PM Steve Ebersole wrote:
> Still not really understanding what you are getting at. Do you have an
> example?
>
> The entity passed into the "DTO" would be managed. If they wanted to
> initialize stuff on that entity it would happen just as normal for a
> managed entity. Is that what you mean?
>
> On Mon, Oct 24, 2016, 4:34 PM Sanne Grinovero wrote:
>
> On 24 October 2016 at 21:49, Steve Ebersole wrote:
> > I'm not sure what you are getting at. This is a feature Hibernate has had
> > for close to 15 years. It's not a "new feature", I'm just proposing a
> new
> > behavior to be more consistent with what people generally expect.
>
> Yes I like the proposal; I'm just wondering if there might be some
> hidden complexities in allowing to initialise additional lazy
> properties during the query execution, as a side-effect of the
> constructor's code as I guess it might want to invoke various getters
> on the Person instance. If you say that's not a problem, then that's
> good news :)
>
> >
> >
> > On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero
> wrote:
> >>
> >> Option 2# looks very nice indeed, I'd like that as it would be useful
> >> to be able to create immutable DTOs directly from a query; but I'm
> >> wondering what kind of difficulties this might pose, for example I'd
> >> assume the DTO constructor would be able to trigger lazy loading of
> >> any property of Person?
> >>
> >> Also wondering, if we expose query results as streams in the future,
> >> would such a feature not become obsolete?
> >>
> >>
> >> On 24 October 2016 at 20:38, Steve Ebersole
> wrote:
> >> > So Person is your entity, e.g.:
> >> >
> >> > @Entity
> >> > class Person {
> >> > @Id
> >> > Long id;
> >> > ...
> >> > }
> >> >
> >> > For a query like `select new DTO( p ) from Person p` Hibernate
> expects a
> >> > DTO like:
> >> >
> >> > class DTO {
> >> > public DTO(Long id) {
> >> > ...
> >> > }
> >> > }
> >> >
> >> > in fact a DTO like:
> >> >
> >> > class DTO {
> >> > public DTO(Person person) {
> >> > ...
> >> > }
> >> > }
> >> >
> >> > will not work with Hibernate.
> >> >
> >> > What I was proposing was for adding some support for that in 6.0 based
> >> > on
> >> > the SQM work. "Support" here could mean either:
> >> > 1) add a flag that says whether to support legacy behavior, or this
> new
> >> > behavior
> >> > 2) attempt to dynamically infer what to do (looks at available ctors)
> >> >
> >> > (2) would be awesome I think. We'd still have to know how to handle
> >> > cases
> >> > where the "DTO" defined ctors matching both cases and which to prefer.
> >> >
> >> >
> >> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea <
> mihalcea.v...@gmail.com>
> >> > wrote:
> >> >
> >> >> Do you mean we should allow the dynamic instantiation to resolve
> >> >> entities
> >> >> when we pass the entity identifier?
> >> >>
> >> >> I think I saw this request on StackOverflow once.
> >> >>
> >> >> Did I understand the question properly?
> >> >>
> >> >> Vlad
> >> >> --
> >> >> From: Steve Ebersole
> >> >> Sent: 10/24/2016 22:21
> >> >> To: hibernate-dev
> >> >> Subject: [hibernate-dev] dynamic instantiation queries
> >> >>
> >> >> Historically (well before JPA) HIbernate would handle dynamic
> >> >> instantiation
> >> >> queries in cases where one of the arguments being an entity-reference
> >> >> by
> >> >> passing just the entity's identifier rather than a complete reference
> >> >> to
> >> >> the entity. To be clear, I am talking about a query like:
> >> >>
> >> >> select new DTO( p ) from Person p
> >> >>
> >> >> Hibernate implicitly treats this like:
> >> >>
> >> >> select new DTO( p.id ) from Person p
> >> >>
> >> >> and expects DTO to have a ctor taking the appropriate ID type.
> >> >>
> >> >> JPA came along and also defines support for dynamic instantiation
> >> >> queries,
> >> >> but does not specify one way or the other how this case should be
> >> >> handled.
> >> >> I have been told other providers interpret this the opposite way.
> >> >> Makes
> >> >> sense. I think it is time we at least allow that as an option. Or
> >> >> maybe a
> >> >> nicer implementation that looks for both and picks the available one
> >> >> (if
> >> >> that's not too much effort).
> >> >>
> >> >> What do y'all think?
> >> >> ___
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev@lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailm
Re: [hibernate-dev] HHH-11089
Hi Petar, We only do development against the master branch, hence we need to apply this on Hibernate 5.2. If Gail wants to backport it to 5.1, then it's up to her whether this change need to be applied to older branches. Can you open a PR with your latest changes against the master branch and I'll review it next week. Thanks, Vlad On Thu, Feb 16, 2017 at 5:42 PM, Petar Tahchiev wrote: > Hey guys, > > a while ago I opened this issue: > > https://hibernate.atlassian.net/browse/HHH-11089 > > which blocks me from using Hibernate with Oracle database (the well-known > issue with 30 chars limit for table/column/foreignkey/indexkey names). > While I managed to workaround the tablename/columnname by specifying a > custom PhysicalNamingStrategy. I also created a custom > ImplicitNamingStrategy, but figured out it is never invoked when I have > already specified a name for the foreign-key/indexkey. It is only called > when no name has been given for the foreign key or index. I made a pull > request, and you guys asked for some improvements. > > Long-story-short I just committed my improvements: > > https://github.com/hibernate/hibernate-orm/pull/1564/commits/ > 78edc44143e39b19668099ea57e9ccb1a3a02b13 > > to make sure that the implicit naming strategy is always invoked no matter > if the user has specified a name for the foreign key or have omitted it. > Can someone please review it? > > BTW I'm not able to build the 5.1 branch and my branch too because I get > thousands of checkstyle violations in files that I haven't worked on. I > also tried to exclude the checkstyle plugin but seems like my gradle > knowledge wasn't enough. > > Thank you and keep up the good work :) > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
