Re: [hibernate-dev] [Search] Useless dependency on solr-analysis-extras
Sounds reasonable to me. solr-analysis-extras contains the ICU [1] support classes which is in many cases are not needed. On the other hand most projects will include hibernate-search-analysers to get the basic analysers and at the moment get this additional dependencies as well. I guess it comes down to whether we think that by including hibernate-search-analysers you should get all Solr tokenizers [2] w/o adding additional dependencies or whether it is ok to ask users to explicitly add the solr-analysis-extras when required. I am fine with removing it, but maybe we need to sync the docs in this case as well. It says now: "all required Solr dependencies are now defined as dependencies of the artifact org.hibernate:hibernate-search-analysers; just add the following dependency" Either way you should create a Jira ticket. --Hardy [1] http://site.icu-project.org/ [2] http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters On 12 Jan 2012, at 11:36 PM, Guillaume Smet wrote: > Hi, > > solr-analysis-extras is a big package as it comes with the following > dependencies: > 3594568 2012-10-06 18:46 WEB-INF/lib/lucene-smartcn-3.6.1.jar > 511956 2012-10-06 18:46 WEB-INF/lib/lucene-stempel-3.6.1.jar > which is 4 MB of dependencies which are usually not that useful > (stempel is a polish stemmer, smartcn is for chinese). > > I checked and hibernate-search compiles perfectly when we remove the > dependency to solr-analysis-extras and we add a dependency to > solr-core as all the analyzers used by Hibernate Search (including > most of the locale dependent analyzers/stemmers) are now in > lucene-analyzers. IIRC, they were moved from solr-analysis-extras to > lucene-analyzers during the 3.x release cycle. > > Apart from the size of the jars, as a lot of new Java features > (Servlet 3 related features for instance) are based on classpath > scanning, removing this useless dependency looks worthwhile to me. > > So the plan is to replace the solr-analysis-extras dependency with > solr-core. I can work on a pull request if it looks sane to everyone. > > Thanks for your feedback. > > -- > Guillaume > ___ > 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] Useless dependency on solr-analysis-extras
Hi Hardy, On Thu, Dec 13, 2012 at 10:49 AM, Hardy Ferentschik wrote: > I am fine with removing it, but maybe we need to sync the docs in this case > as well. It says now: > > "all required Solr dependencies are now defined as dependencies of the > artifact org.hibernate:hibernate-search-analysers; > just add the following dependency" IIRC, this sentence is here because Hibernate Search used to package the analyzers extracted from Solr in a specific Jar. It was removed in favor of a dependency to Solr jars when they were pushed to Maven not so long ago. IMHO, the important word in this sentence is the "required" in "all *required* Solr dependencies": stempel, ICU and smartcn aren't required at all: if you want these specific analyzers, you just have to add a dependency to them, which isn't surprising. It doesn't seem like a bad idea to be consistent with how Lucene have rearranged their analyzers and to include all the lucene-analyzers + the Solr machinery used to wrap them. I think it's worth a note in the release notes though if we go this way. I'll go create a JIRA as you asked. Thanks. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [metamodel] why not just give a generated name to constraint if no one provided in the mapping?
talking about org.hibernate.metamodel.spi.relational.AbstractConstraint#getName
proposing this :
public String getName() {
if ( name == null ) {
name = getExportedName();
}
return name;
}
reason:
I have to copy all the constraints defined in the root table to the sub table
in a table-per-class hierarchy, w/o constraint name, it is hard to use "locate"
methods, and I don't want to calculate generatedName() method many times.
alternative:
we add a defaultName / internalName attribute to the constraint, and use it for
the internal constraint look up, the value is generated when constraint object
created
wdyt?
-
Best Regards,
Strong Liu
http://about.me/stliu/bio
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 4.1.9 delayed till tomorrow morning
I'll do some AS testing with the additional changes. On 12/12/2012 06:33 PM, Brett Meyer wrote: > All, I'll do the 4.1.9 release first thing tomorrow (Thurs.) morning. > There's a few tickets that are being finished up tonight. Tomorrow, please > do not push anything to the 4.1 branch until the release is tagged. Sorry > for the delay! > > Brett Meyer > Red Hat Software Engineer, Hibernate > +1 260.349.5732 > > ___ > 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] Hibernate ORM 4.1.9.Final released
Hibernate ORM 4.1.9.Final was released this morning (http://in.relation.to/Bloggers/HibernateORM419FinalReleased) Changelog: https://hibernate.onjira.com/secure/ReleaseNote.jspa?projectId=10031&version=12367 JBoss Nexus: https://repository.jboss.org/nexus/content/groups/public/org/hibernate Maven Central: http://repo1.maven.org/maven2/org/hibernate/hibernate-core (should update in a couple of days) SourceForge: https://sourceforge.net/projects/hibernate/files/hibernate4 Downloads: http://sourceforge.net/projects/hibernate/files/hibernate4/4.1.9.Final/hibernate-release-4.1.9.Final.zip/download http://sourceforge.net/projects/hibernate/files/hibernate4/4.1.9.Final/hibernate-release-4.1.9.Final.tgz/download Thank you for all of the contributions! Brett Meyer Red Hat Software Engineer, Hibernate +1 260.349.5732 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Regression in AS7 (master) cluster cache invalidation test after moving from Hibernate ORM 4.1.6 to 4.1.9
http://hudson.jboss.org/hudson/job/as7-param-pull/5123/ shows a failure with the second level cache not being invalidated as expected across a two node cluster. I'm able to reproduce locally, which is good. We will continue to use Hibernate 4.1.6 until we get past this regression (hopefully we can understand the test failure cause soon). https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/xpc/StatefulWithXPCFailoverTestCase.java#L276 is the line that is failing (yeah, the arguments to assertEquals are backwards but that isn't the root issue ;) It is possible that its a bug in the test also. The cluster has two nodes, each with their own in-memory database. The test assumes that it can create the same entity on both nodes (same primary key) and that for the purpose of testing the second level cache, we can expect cache invalidation to occur on both nodes when deleting the entity on one of the nodes. I believe that the cache invalidation should be synchronous but I'll probably try adding a sleep to see if it could be an async/timing issue. I hope to have more information soon (probably in the morning on Friday). Scott ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
