If you develop/contribute to hibernate tools core then you should update your svn checkouts to use https://svn.jboss.org/repos/hibernate/tools/trunk
hibernate tools core (i.e. *not* the eclipse plugins) is now in the same structure as all the other hibernate modules.
I've moved trunk and the 3.2. branch into https://svn.jboss.org/repos/hibernate/tools
I've left the old tags in place since they all rely on the old hibernateext structure so felt wrong/broken to have them in the new one
(I believe it is the same Emmanuel did when annotations/validator "moved" - if not let me know :)
I know this is a long overdue, but i'm now creating
and is trying to figure out how to make what were done in https://svn.jboss.org/repos/hibernate/branches/Branch_3_2/HibernateExt/to...
the new trunk (maintaing history etc.)
Is svn mv the only option ? (not liking that much since it removes the branch too..)
svn cp would give me the exact copy but not retain the revision info afaik.
Anyone remembers how it were done back in 2007 for core and the other modules ?
(svn history seem to indicate svn mv were used, but that were fine then because the branches and trunks were copied to corresponding branches and trunks)
Ok, I'm fed up. I am tired of having to clean up spam comments on our
blogs entries daily. I woke up this morning to 85 comments, the vast
majority of them spam! And this is after cleaning up0 yesterday.
So if someone knows how to make entries only commentable by *registered*
users, that would be great. If not, I think its time I look for a new
place to blog.
Steve Ebersole <steve(a)hibernate.org>
I assume that if I were to run the hibernate tools tests against the same database settings in hibernate core
there is a risk of midair collision on the database :)
So i'm interested in hearing who maintains/setup those databases so I could get one setup
to run the hibernate tools test suite on them.
Any pointers welcome.
On the branch using Gradle for builds I started working on folding together hibernate-core, hibernate-testing and hibernate-testsuite. Gradle makes this very flexible and without further considerations I would simply define a total of 4 sourceSets in the hibernate-core project:
Gradle would let me define the compilation output directory for each sourceSet and we'd be on our way.
But of course we want this easily workable in IDEs. IntelliJ for example would not like the fact that we would need to define a total of 4 different compilation output directories for a single project (what IntelliJ calls module). So we need to find the balance that works best in command line as well as IntelliJ and Eclipse.
I've put together a few proposals based on knowing what will work in IntelliJ and talking to Max and Hans.
1) As far as we can tell the above would actually work. In IntelliJ we'd split the project into 2 modules. There was some drawback to this in Eclipse as well though the details escape me atm (max?).
2) Only fold hibernate-testsuite back into hibernate-core and leave hibernate-testing separate. This creates a semi-circular dependency but Gradle and IntelliJ can deal with it because the nature of the deps is limited in such a way that hibernate-testing would depend on classes from hibernate-core and hibernate-core would depend on hibernate-testing for it's test-classes. No clue if this would work in Eclipse.
3) Another thing to consider is whether hibernate-testing still needs to be deployed on it's own. We did this as a convenience so that users could use it in their own project tests. To be honest I have no idea how much use it gets in that way. If the answer here is no then the problem becomes a little simpler in that we could just compile the hibernate-testing classes would just be part of hibernate-core/src/test/java and would get compiled along with the test classes into test-classes. Gradle itself has this set up so we have a template we could easily follow for this approach. Worst case we could use this approach and still build the additional hibernate-testing jar for upload using include/exclude definitions to get the correct classes into the jar.
All things considered I think I prefer (2) or (3) as the solution to implement. One concern I had with them that I need to verify works is compiling unit tests and intg tests into the same output directory and whether separate test tasks could really work there. Also I need to decide whether that really matters.
-- Sent from my Palm Pre
Hi Steve. Can you shed some light on the deprecation warnings that started
to appear in 3.5.2 in org.hibernate.Hibernate? I see they're related to type
system changes your making for 3.6 under HHH-5138 and HHH-5182, but it's not
clear what part of those landed in 3.5.x or what migration steps developers
need to take to get rid of the warnings. Nothing jumps out at me in the
I am looking into collection some statistics for HSearch. I am for example
interested in measuring the Lucene query execution time and the Hibernate
Core "object loading" time.
I could just wrap the calls I am interested in System.nanoTime() or I
could write a custom StopWatch class, but I was wondering whether there is
some sort of library I could use.
I found perf4j (http://perf4j.codehaus.org). Does anyone have experience
with this library? It looks nice, but I don't like it that the logging
approach it takes seems to
be bound to log4j atm.
who could tell me what a default data access should be used in case of
entity mapping through orm.xml (field/property)?
Is it written anywhere?
I ask because there is seems a bug in hibernate - it use "property"
access by default.