Weekly meeting (4/19)
by Steve Ebersole
First meeting. Went well.
1) We discussed our experiences with time-boxing in the 3.5 releases.
Generally positive. Some felt 2 weeks may have been a bit too often.
We will play with time moving forward to find the best balance which may
be an alternation: slow (alphas), fast (betas and crs), slow (past
final).
2) 3.6
2.a) will require at least JDK 1.5
2.b) merge annotation code into core module
2.c) will revist the idea of merging entitymanager into core module
during next meeting.
2.d) specj use case (eagerly loaded key-many-to-one)
3) Hudson plan
4) Documentation consolidation (core, annotations, jbc, envers,
entitymanager)
5) docs.jboss.org issues. Archiving release docs versus indexing
engines. index.html pages.
I have attached the log.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years
Public API of Hibernate Validator
by Gunnar Morling
Hi guys,
currently I'm experimenting a bit with integrating Bean Validation in
general and Hibernate Validator in particular with OSGi. In that context I
wondered, whether there is some sort of "public" API of Hibernate Validator.
The generated HV OSGi manifest (see HV-267) currently exports all packages,
but I think there should be a more fine-grained distinction, which
packages/classes should be publicly available.
For instance "org.hibernate.validator" and
"org.hibernate.validator.constraints" would be part of such a public API
(while "org.hibernate.validator.constraints.impl" wouldn't). Things are
getting more complicated when looking at "org.hibernate.validator.engine".
Most of the classes there should be considered private to HV, but at least
ResourceBundleMessageInterpolator (together with the new stuff related to
ResourceBundleLocator in "org.hibernate.validator.engine.resourceloading")
is of interest for users/integrators.
Using OSGi, one can control exported types on a class level, but presumably
it makes things easier, if certain complete packages make up the public API.
Also besides the OSGi scenario I think it's useful to explicitly describe
the public API. That way users would know, which HV classes they are
"allowed" to use (and therefore can rely on their stability) and which ones
not. We OTOH would know which classes we can modify without the need to
maintain backward compatibility.
WDYT? If we come to the conclusion that for instance
ResourceBundleMessageInterpolator should be moved to another package, I
think it might be a good idea to do that for 4.1, as right now the number of
concerned classes still seems very limited.
Gunnar
14 years
solidDB Hibernate dialect ?
by Niall DOWNEY
Hi All,
I work for IBM and we are investigating adding our solidDB dialect to the
existing set in Hibernate. Can someone tell me how we go about this and who
should we talk to ?.
Apologies if this is off-topic but it was suggested in the "Hibernate
Users" forum that I try posting here.
Regards,
Niall Downey
14 years
Weekly meetings on IRC
by Steve Ebersole
I wanted to start getting into doing weekly dev team meetings on irc.
Personally I think IRC is the best medium for such things. We can log
them, we can search them, etc. And everyone can participate. Things
seem to get resolved much more quickly using IRC compared to email IMO.
Of course many of us hang out there already. The problem is that not
all of us are there all the time obviously. So this will resent a block
of time when we will all be there and can discuss development plans/issues.
Considering I generally do releases on Wednesdays I think Monday makes
the most sense. I think an hour is generally going to be too long (we
shall see I guess) but lets say an hour for now. Would 10 am or 11 am
US Eastern Timezone work for everyone?
--
steve(a)hibernate.org
http://hibernate.org
14 years
FindBugs Community Review of Hibernate
by Nat Ayewah
Hello,
I am a PhD student working with the FindBugs project, at the University
of Maryland. FindBugs <http://findbugs.sourceforge.net/> is a popular
open source static analysis tool that can analyze Java software and
identify bugs. We recently analyzed *Hibernate*, and identified about 59
warnings that might be of interest to the project. You can launch an
instance of FindBugs and evaluate each warning using this link (requires
Java): http://findbugs.cs.umd.edu/cloud/hibernate.jnlp
FindBugs has recently started a community review of several open source
projects. This is similar to a recently completed review
<http://findbugs.sourceforge.net/> at Google in which almost 300
engineers reviewed thousands of issues, fixing many of them. I would
like to invite you all to participate in the review for Hibernate, and
other open source projects. During the review, you are able to comment
on each warning and evaluate it as "Must Fix", "Mostly Harmless", "Not a
Bug" and other classifications. We are particularly interested in
learning if any warnings are causing problems in production.
The list of projects currently included in our review is at
http://findbugs.cs.umd.edu/cloud/
Thanks in advance for your consideration.
Kind regards,
Nat Ayewah
PhD candidate, University of Maryland
http://www.cs.umd.edu/~ayewah
ayewah(a)cs.umd.edu
14 years
Fwd: [HV] Supporting Joda Time API with @Past/@Future
by Gunnar Morling
Answers inline.
2010/3/30 Emmanuel Bernard <emmanuel(a)hibernate.org>
I like the idea.
> Initially we've decided to not add them and were waiting for the JSR-310.
> do you know the status and expected release?
>
JSR 310 was in Early Draft Review stage from 26 Feb till 28 Mar. It's
planned to be included in Java 7, though AFAIK it's not totally sure whether
this is really going to happen. As Joda is quite widely in use I think it
would be nice to have support for it in Hibernate Validator. Once JSR 310 is
final, support for it could be added to HV, and surely also to the BV spec.
>
> The main problem I see is that we would likely use the same annotations for
> both joda and the jsr-310.
> We could think of using @Constraint and use two validator implementations
> but unfortunately that would fail at runtime if we don't have Joda Time in
> the classpath.
>
> Anyone has an idea to work around that?
>
I thought about supporting the standard BV @Past/@Future annotations at
Joda/JSR 310 types with Hibernate Validator. In that case the validator(s)
for Joda/JSR 310 might be registered automatically by HV (as all validators
for annotations from the BV API), probably after some reflective checking
whether Joda/JSR 310 is present in the class path or not.
Alternatively one could provide one/two constraint-mapping XML file(s) to be
delivered with Hibernate Validator, which users might add to their
validation.xml in case they want to work with Joda/JSR 310.
The second approach is more in line with the concepts of customization
defined by BV, while the first is probably more comfortable for Hibernate
Validator users.
>
> On 24 mars 2010, at 22:40, Gunnar Morling wrote:
>
> > Hi,
> >
> > for Hibernate Validator 4.1 we are planning to add some new constraints.
> In
> > this context Hardy and I discussed whether it might be worth to add
> support
> > for the date/time types from the Joda Time API (
> > http://joda-time.sourceforge.net/) for the @Past/@Future standard
> > constraints.
> >
> > I think Joda is quite popular these days, and the upcoming JSR 310 is
> > heavily influenced by Joda, too (the spec lead is also the lead of Joda).
> So
> > this might add value for users, OTOH such support might be too specific.
> Are
> > there any opinions on this?
> >
> > Thanks, Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
14 years
