Re: [hibernate-dev] Hibernate Search being integrated in WildFly
On 14 January 2014 15:46, Scott Marlow wrote: > I am a big fan of Hibernate technologies and the search capabilities. I am > concerned though that we are deferring how to untangle the Hibernate > Search/Infinispan/WildFly dependencies. > > I raised a few questions on the wildfly-dev mailing list, some that got > answered but one important issue didn't. The question is about scheduling > and how to coordinate the WildFly/Hibernate ORM/Hibernate Search/Infinispan > releases such that if one component breaks the others at the end of a > release cycle, how to deal with that. This isn't really my problem as I > don't schedule any of these components but it would be wrong of me not to > point this out. We'll try to coordinate version compatibility across projects; We do control the version being used in Infinispan and will keep it up to date as there are various good reasons to do that. The tricky part is that we don't control necessarily which versions of ORM and Infinispan are going to be picked in a specific WildFly release, but optimistically speaking I expect that this choice will always be at "same generation". To address the more pessimistic scenario, we'll need to be more flexible in having +1 / -1 version compatibility at SPI levels. Historically we'll have been quite good at keeping a level of flexibility, but you're right it is a concern and we'll be handling stricter compatibility checks via new CI jobs. Worst case, we'll always be able to deploy additional modules. > > Are there any infinispan-dev mailing list threads discussing how to remove > the Infinispan dependency on Hibernate Search in 2014, so that we aren't > forced into keeping Hibernate Search in WildFly 9? Not yet, if any now that it's being included I think it should stay there. A major release is a big change for our point of view but not a reason to completely disrupt users's experience, from their point of view it's not nice that the way to deploy something like this changes *that* frequently. > > > On 01/13/2014 06:06 PM, Sanne Grinovero wrote: >> >> Hello, >> as you might already know by following the WildFly developer's mailing >> list, most of the Hibernate Search jars and dependencies (Lucene) are >> now included in the application server as modules. >> >> This was not primarily driven by practical need of Hibernate users but >> rather because of clustering needs of the application server, and also >> CapeDwarf and other projects make extensive use of it. >> >> Just a couple of small adjustments are needed to make it possible for >> Hibernate users to also take advantage of it, so I'd think we should >> make these adjustments to make it more useful? >> >> This is what I'm thinking: >> - The hibernate-search-orm jar is missing (an essential jar for our >> purposes) >> -> add a module >> - No additional analyzers are included >> -> see how optional modules work, so that - while we won't ship all >> those dependencies - it's still easy to add when you need one >> - Jipijapa should help? > > > Jipijapa could help standardize how WildFly integrates with search > providers. I'm not sure if this is needed. I mean, I think it's probably Jipijapa's responsibility to inject the module on the classpath for Hibernate users. > > >> -> should we make Hibernate Search available to deployments >> whenever Hibernate ORM is made available? > > > Would this slow deployment down at all for applications that don't use > Hibernate Search? No, not at all. Sanne >> - Get it to a reasonable version: it's including 4.5.0.Alpha2 now >> -> we need to release a Beta soon, any volunteer? I'm stuck on an >> island with extremely slow connectivity. >> - Contribute some integration tests to WildFly: there aren't any >> today verifying the included modules >> >> What shall we do about our modules distribution? I think it would be >> nice to continue maintaining that, so that we can make frequent >> releases and that would allow users to use a different version than >> what they would get in WildFly - if they want to. >> >> -- 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] irc team meetings and jbott
We have been having a lot of trouble lately with relying on jbott to record the team meetings on irc. A few times jbott has not been in the room. A few times it refuses to start/end meetings. Max, is there anything to be done to make jbott more stable? If not, do we maybe want to look at using gitter for team meetings? We would not be able to delineate meetings (unless they have added that feature), but we would at least have the notes persistent. Any other thoughts? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] irc team meetings and jbott
On queue :) [07:25] <-- jbott has left this server (Ping timeout: 276 seconds). On Wed 15 Jan 2014 07:17:34 AM CST, Steve Ebersole wrote: > We have been having a lot of trouble lately with relying on jbott to > record the team meetings on irc. A few times jbott has not been in > the room. A few times it refuses to start/end meetings. > > Max, is there anything to be done to make jbott more stable? > > If not, do we maybe want to look at using gitter for team meetings? We > would not be able to delineate meetings (unless they have added that > feature), but we would at least have the notes persistent. > > Any other thoughts? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Haste makes waste - here comes Hibernate Validator 5.1.0.Beta1
Hibernate Validator 5.1.0.Beta1is out. More info on in.relation.to - http://in.relation.to/24788.lace —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search being integrated in WildFly
>>> I can do a release. Just wondering whether it should be a CR already? >>> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we >>> already upgraded now >>> to 4.3.0.Final (just not released yet). So it would really be time to get >>> 4.5.0.Final out. >>> We could cut a CR release and if nothing comes up promote it to 4.5 final >>> in a couple of weeks. >> >> We also have the Infinispan indexmanager on the roadmap. All work was >> done a year ago already, and the Infinispan issues which prevented me >> to merge it at the time are fixed, so I should only need to rebase it. >> >> I would love to merge it, but let's set a deadline for it.. if I can't >> make it we release without it again :-( >> >> Also I'm worried about HSEARCH-1260 and Guillaume's report. It would >> be nice to get rid of those issues by applying the cleanup I've >> suggested on that thread. >> >> I fundamentally agree that if we don't address these quickly, we >> should aim at a quick Final, still let's not rush it too much as >> WildFly doesn't stricly need a Final from us (or at least I wasn't >> asked for one). > > Don’t you think that a lot of users might hold of an upgrade, because they > want a final > or at least CR release? If we want people to use 4.5 we might need to give > them > a final sooner than later. I don’t see the mentioned issues addressed in the > near > future. Guillaume for example won’t be able to look at the mass indexer until > some > time February. Is it in this case not better to do a 4.5.0.Final and then add > the > mentioned features in a 4.5.x release? Have we decided on a version? Sanne, you still vote for a 4.5 Beta1? —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JdbcSession proposal
See inline... P.S. Latest revs pushed to my upstream repo On 01/06/2014 02:48 PM, Brett Meyer wrote: > * +1 for the "Operation API", over the granular set of boilerplate code. > Also, imo, I'd overload the API methods with the specific Operation impl > arguments (ex: #accept(PreparedStatementQueryOperation)), rather than only > one (ex: #accept(Operation)). I tend to think it's cleaner, removing type > checks, etc. I know there was already some debate about that, so just my > $.02. Operation is a "free flow" contract much like Work. Not sure what kind of "concrete impls" you see. Maybe you are thinking of the OperationSpec concept... But even for OperationSpec I am not sure overloading the methods is a good idea. I generally consider exploding an API 1+1 for new types is an anti-pattern. Let's just let the API evolve as we move further in the design and not force stuff up front... > * If you haven't already, define default Operation impls and use wherever > possible? Again, I think you are thinking of OperationSpec... > * There was some discussion comparing the difficulty of integrating each > possibility into ORM. Imo, *any* of them will be difficult. Removing the > proxy system was a gigantic, tedious pain. That being said, let's make sure > we identify all possible future needs, including the applicability of > DataStoreSession, and do them once. I'd hate to roll with something, then > have to change/extend it later on. The proposal process has already been > doing this, but it's worth mentioning. Not sure this is accurate. The "low-level API" is much closer to JDBC and would be much easier to swap in than the Operation-style approaches. Trivial? No, just much easier. As far as DataStoreSession, I've already reverted that work. There was no interest from those who it would have benefitted and it just muddied the waters for straight JDBC usage. And I whole-heartedly agree that I consider this as "that ship has sailed"; meaning I will not be going back and changing JdbcSession to an agnostic DataStoreSession down the road. While it would have been nice to do up-front, it would be just too much work to add on later. > * Relying on the JTA Synchronization makes sense conceptually, but have we > received any feedback from JBossTS? > * Regarding the above, +1 for (conceptually) not caring about Synchronization > failing for rollback-only and failing fast. But, just want to make sure > we're not overlooking something. Yep. I have discussed with Tom a few times. Scott and I are doing one last round of discussion with him just to re-re-re-confirm. > * How would CMT fit into this? Don't understand the question. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
