Hey Sanne, https://hibernate.atlassian.net/browse/HHH-7584 might be what you're
looking for -- that should take care of it, I believe.
Brett Meyer
Red Hat Software Engineer, Hibernate
- Original Message -
From: "Strong Liu"
To: "Sanne Grinovero"
Cc: "Hibernate"
Sent: Wednesday, July 1
Nice. You should add it to g+ too
On Jul 11, 2013 2:10 PM, "Brett Meyer" wrote:
> If anyone's interested in the recent Hibernate ORM OSGi efforts, there's a
> write-up in InfoQ today:
>
> http://www.infoq.com/news/2013/07/hibernate-osgi
>
> Brett Meyer
> Red Hat Software Engineer, Hibernate
>
>
If anyone's interested in the recent Hibernate ORM OSGi efforts, there's a
write-up in InfoQ today:
http://www.infoq.com/news/2013/07/hibernate-osgi
Brett Meyer
Red Hat Software Engineer, Hibernate
___
hibernate-dev mailing list
hibernate-dev@lists.jb
Today we discussed Integrators, mapping fetch strategies in the new
metamodel and wakeboarding amongst other topics :)
[11:35] Meeting ended Thu Jul 11 16:07:16 2013 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[11:35] Minutes:
http://transcripts.jboss.org/mee
On 11 July 2013 15:29, Hardy Ferentschik wrote:
> I find them confusing as well and cannot thing of an actual use case.
> I assume you are removing the hibernate.search.worker.* settings as well,
> right?
Partly: we still need the options which apply to our "one and only"
implementation, the Tra
On 11 July 2013 15:40, Emmanuel Bernard wrote:
> Fine by me, one of those brilliant flexibility points that did not reach
> its public. Let's call it succès d'estime :)
who knows, maybe it's so successful and works so well that nobody ever
complained :-)
I guess we'll find out when removing it.
Fine by me, one of those brilliant flexibility points that did not reach
its public. Let's call it succès d'estime :)
On Thu 2013-07-11 15:04, Sanne Grinovero wrote:
> I'm wondering if this property is really useful. Someone has a
> practical example in which he would need it?
>
> http://docs.jbo
I'm wondering if this property is really useful. Someone has a
practical example in which he would need it?
http://docs.jboss.org/hibernate/search/4.3/reference/en-US/html_single/#table-worker-configuration
I'm tempted to deprecate it and remove the description from the
documentation as so far I'
On Thu 2013-07-11 14:37, Hardy Ferentschik wrote:
>
> On 11 Jan 2013, at 12:18 PM, Gunnar Morling wrote:
>
> > Here is the thing, we need to also need to start talking retention setting
> > of the annotation.
> > I think you were suggesting source retention. This means that the
> > annotation
On 11 Jan 2013, at 12:30 PM, Gunnar Morling wrote:
> I think hovering over a method I want to use in my IDE and seeing it is
> annotated with @Incubating gives me that information much faster than going
> to a wiki or online docs.
would you get that out of the box?
> The latter also doesn't
On 11 Jan 2013, at 12:18 PM, Gunnar Morling wrote:
> Here is the thing, we need to also need to start talking retention setting of
> the annotation.
> I think you were suggesting source retention. This means that the annotation
> is only in the
> source. That means the IDE needs to be linked t
2013/7/11 Hardy Ferentschik
>
> On 10 Jan 2013, at 11:07 PM, Gunnar Morling wrote:
>
> > 2013/7/10 Steve Ebersole
> >
> >> http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
> >
> >
> > Thanks for the link. I like their approach of explicitly documenting this
> > kind of thing.
2013/7/11 Sanne Grinovero
> Indeed in my previous comment about bundling it in a common jar I was
> assuming the retention would have been at source level.
>
> Hardy suggested we could keep it even at runtime.. indeed that could
> open the path for several kinds of diagnostics and reporting. I gu
2013/7/11 Hardy Ferentschik
>
> On 10 Jan 2013, at 5:48 PM, Gunnar Morling wrote:
>
> > So basically we're looking for a way to inform the user and say "it's ok
> to
> > use this API, but be prepared to changes in the future". One way to do
> this
> > is documentation, i.e. prose or a custom Jav
Indeed in my previous comment about bundling it in a common jar I was
assuming the retention would have been at source level.
Hardy suggested we could keep it even at runtime.. indeed that could
open the path for several kinds of diagnostics and reporting. I guess
there is no downside? I don't exp
On 10 Jan 2013, at 11:07 PM, Gunnar Morling wrote:
> 2013/7/10 Steve Ebersole
>
>> http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
>
>
> Thanks for the link. I like their approach of explicitly documenting this
> kind of thing.
I think we might have to differentiate here
On 10 Jan 2013, at 6:13 PM, Emmanuel Bernard wrote:
> I remember a few discussion where something like that has been
> contemplated. One thing that made us not do it AFAIR is that we would
> need some kind of shared project to host this across ORM, OGM, SEARCH
> etc. In the past we have deemed i
On 10 Jan 2013, at 5:48 PM, Gunnar Morling wrote:
> So basically we're looking for a way to inform the user and say "it's ok to
> use this API, but be prepared to changes in the future". One way to do this
> is documentation, i.e. prose or a custom JavaDoc tag such as @experimental.
> This has b
18 matches
Mail list logo
