Re: [hibernate-dev] save the planet one non character stroke at a time
OK. Since there is no consensus. I'll keep doing so in my private repo and keep the current scheme for public pushes. Emmanuel On 14 juil. 2011, at 10:07, Hardy Ferentschik wrote: > +1 and I think this undueness applies not only to HHH ;-) > > On Wed, 13 Jul 2011 22:49:08 +0200, Steve Ebersole > wrote: > >> I guess maybe this is hassle based on which project key you are talking >> about. For HHH- that is not an undue burden imo. > ___ > 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] Hibernate4 artifact names, Persistence provider name, maven...
I agree with Steve. On 16 juil. 2011, at 19:07, Steve Ebersole wrote: > I am personally against this idea. You mention renaming one single > class, but in reality we would need different FQNs for each and every > class otherwise we run into a clash in the class loader as to which one > wins (the one from hibernate4 jar or the one from hibernate3 jar). > > This is a bad path to start down. > > As an illustration, we had the same issue with JBoss Cache for some > time and we simply had 2 sub-projects, one for each version. Which in > my mind is the perfectly reasonable approach. > > On Fri 15 Jul 2011 08:55:23 AM CDT, Scott Marlow wrote: >> If someone wanted to include both Hibernate 3 + Hibernate 4 in the same >> project, that might be easier if the Hibernate 4 artifacts had a version >> number in it or was changed for every new major release. I don't think >> Maven supports building two versions of the same artifact (at the same >> dependency level). >> >> For the persistence provider name, >> org.hibernate.ejb.HibernatePersistence, I'm wondering if we could have a >> org.hibernate.ejb.HibernatePersistence4 in addition, that could be used >> to uniquely reference Hibernate 4.x persistence providers. >> >> I assume this is too late in the Hibernate 4 cycle to change, but wanted >> to bring the idea up. >> >> Changing the artifact names would impact other projects that depends on >> Hibernate4 and would need to sync up with the changes as well. >> >> What do you think? >> >> Scott >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > st...@hibernate.org > http://hibernate.org > ___ > 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] Hibernate4 artifact names, Persistence provider name, maven...
You can use org.hibernate.Version.getVersionString() which is the version number + qualifier OR [WORKING] when a snapshot is used. Emmanuel On 16 juil. 2011, at 19:56, Scott Marlow wrote: > It doesn't cause me great pain to not have this, would just make a few > AS integration tasks simpler (when dealing with multiple versions of > Hibernate). > > I understand that there are more environments than just AS. For AS7, it > was more because I am using the persistence provider class name as a key > (in a hash map). I really should be using a composite key that includes > a version number but I don't have one (maybe I should look for one > inside the persistence provider jar and use the version information if > found). > > On 07/16/2011 01:07 PM, Steve Ebersole wrote: >> I am personally against this idea. You mention renaming one single >> class, but in reality we would need different FQNs for each and every >> class otherwise we run into a clash in the class loader as to which one >> wins (the one from hibernate4 jar or the one from hibernate3 jar). >> >> This is a bad path to start down. >> >> As an illustration, we had the same issue with JBoss Cache for some >> time and we simply had 2 sub-projects, one for each version. Which in >> my mind is the perfectly reasonable approach. >> >> On Fri 15 Jul 2011 08:55:23 AM CDT, Scott Marlow wrote: >>> If someone wanted to include both Hibernate 3 + Hibernate 4 in the same >>> project, that might be easier if the Hibernate 4 artifacts had a version >>> number in it or was changed for every new major release. I don't think >>> Maven supports building two versions of the same artifact (at the same >>> dependency level). >>> >>> For the persistence provider name, >>> org.hibernate.ejb.HibernatePersistence, I'm wondering if we could have a >>> org.hibernate.ejb.HibernatePersistence4 in addition, that could be used >>> to uniquely reference Hibernate 4.x persistence providers. >>> >>> I assume this is too late in the Hibernate 4 cycle to change, but wanted >>> to bring the idea up. >>> >>> Changing the artifact names would impact other projects that depends on >>> Hibernate4 and would need to sync up with the changes as well. >>> >>> What do you think? >>> >>> Scott >>> ___ >>> 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/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Future of branch 3.4.x
I'm fine with cherry-picking / backporting the most important fixes and releasing a 3.4.1. We are not going to release Hibernate Search 4 that soon. Sanne, could you list the most important issues to backport and we can share the work amongst the team. Emmanuel On 16 juil. 2011, at 17:57, Sanne Grinovero wrote: > Hello, > Are we going to release a 3.4.1 version of Hibernate Search at some point? > There are some community members asking if there is any plan, and if > there's an expected timeframe. > > There where some issues with the new features in 3.4.0, the most > urgent ones where quickly reported and fixed since that people is > using 3.5.0 snapshots. > > Some other fixes in the faceting are are still to be done, but I > remember Hardy mentioning they should be easy.. ideally we could merge > these too, iff there's such an intention. > > I had created a 3.4.x branch only recently from the 3.4.0 release tag: > this means it's not containing all of the fixes which are in master. > > Cheers, > Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Future of branch 3.4.x
+1 I am also fine with back porting important fixes. But we have to be careful how much time we invest. Preferably we should focused on "contained" bugs/features. --Hardy On Mon, 18 Jul 2011 10:43:20 +0200, Emmanuel Bernard wrote: > I'm fine with cherry-picking / backporting the most important fixes and > releasing a 3.4.1. We are not going to release Hibernate Search 4 that > soon. > > Sanne, could you list the most important issues to backport and we can > share the work amongst the team. > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Future of branch 3.4.x
This is my proposal of commits to backport: https://hibernate.onjira.com/browse/HSEARCH-741 (fix a NPE) https://hibernate.onjira.com/browse/HSEARCH-780 (contributed bugfix around Dirty analysis of collections) https://hibernate.onjira.com/browse/HSEARCH-779 (programmatic mapping API missing feature) This is a nice to have, since we're going through the effort of doing the release I'd propose to include it as well: https://hibernate.onjira.com/browse/HSEARCH-754 (expose a configuration option useful for Infinispan integration) This one needs coding : HSEARCH-745 (Hardy, a faceting issue) This is already in 3.4.x branch: https://hibernate.onjira.com/browse/HSEARCH-744 Now if anyone has the time to cherry pick the appropriate commits, I'll volunteer to review the pull request. Then I'll wait for Hardy to see if he can fix the faceting issues on both branches before actually starting the release.. Hardy could you review the faceting issues and see which ones should go in 3.4.1 by marking them on JIRA (if any other than HSEARCH-745) ? Cheers, Sanne 2011/7/18 Hardy Ferentschik : > +1 I am also fine with back porting important fixes. But we have to be > careful how much time we invest. > Preferably we should focused on "contained" bugs/features. > > --Hardy > > On Mon, 18 Jul 2011 10:43:20 +0200, Emmanuel Bernard > wrote: > >> I'm fine with cherry-picking / backporting the most important fixes and >> releasing a 3.4.1. We are not going to release Hibernate Search 4 that soon. >> >> Sanne, could you list the most important issues to backport and we can >> share the work amongst the team. >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] IRC Developer Meeting (7/18)
Meeting ended Mon Jul 18 15:40:53 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-07-18-15.01.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-07-18-15.01.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-07-18-15.01.log.html -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
