Looking for Sponsor for JIRA HHH-3579, this enhancement was originally
requested last year.
I updated the JIRA ticket will patches that implement the enhancement.
Enhancement Summary: Support for PostgreSQL UUID data type
The good folks at NHibernate implemented this feature previously. This is
es
Hi Sanne
Thanks for your reply. I was thinking mostly around implementation
side of things. I guess it would be great to get an idea or discuss
how this may impact the API. I know Emmanuel mentioned moving
SearchMapping into an interface.
Cheers
Amin
Sent from my iPhone
On 14 Dec 2009, a
I'm finally done with mapping all the missing features of JPA 2 in either
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4190 or
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4325
Sorry it took so long.
Emmanuel
___
hiber
Well we can also do what you suggest and you can be the one fielding bug
reports about some other providers jar if you wish ;)
On Mon, 2009-12-14 at 17:38 +0100, Emmanuel Bernard wrote:
> If you guys like that. But you will be the ones answering the questions:
> - why is Hibernate not standard
>
If you guys like that. But you will be the ones answering the questions:
- why is Hibernate not standard
- why do I need an hibernate specific jar to use JPA 2
:)
On 14 déc. 2009, at 16:02, Hardy Ferentschik wrote:
> I like the idea of having 'hibernate' in the actual jar name as well. When
>
Just for the build... The model generated is not SE 6 specific in any
way...
On Mon, 2009-12-14 at 17:31 +0100, Emmanuel Bernard wrote:
> So far we only require SE 5 for JPA 2 but SE 6 will bring you the static
> metamodel generator used by the criteria API.
>
> On 14 déc. 2009, at 16:57, Paul
So far we only require SE 5 for JPA 2 but SE 6 will bring you the static
metamodel generator used by the criteria API.
On 14 déc. 2009, at 16:57, Paul Benedict wrote:
> I read that JEE 6 is built on JSE 6 [1]. So does that mean that
> Hibernate's JPA 2.0 implementation requires JSE 6? I would li
I read that JEE 6 is built on JSE 6 [1]. So does that mean that
Hibernate's JPA 2.0 implementation requires JSE 6? I would like some
clarification on this. Thank you.
[1] http://www.eisele.net/blog/2009/01/jee6-public-review-draft.html
Paul
___
hibernat
I like the idea of having 'hibernate' in the actual jar name as well. When
you are
building a project the dependencies are clear. But when you just look at
an artifact
like for example a war file it helps a lot if the jar file names are a
little more descriptive.
We also have hibernate-core a
Hi Amin,
your idea looks good to me; is this discussion affecting only
implementation or does it have some impact on APIs?
This is just to check for yourself that you're not forgetting something right?
Just wondering: it makes sense in both cases, sorry I'm looking into
it after much time.
Cheers,
Shizzle, that explains it. I forgot to commit after releasing :(
Done now.
Same for jpamodelgen too btw. I cut a Beta-2 release in order to align
the jpa api jars
On Mon, 2009-12-14 at 11:29 -0300, Hardy Ferentschik wrote:
> In pom.xml is still uses file://${maven.repository.root} and looking
When the user simply has the jar file "in hand".
On Mon, 2009-12-14 at 15:30 +0100, Emmanuel Bernard wrote:
> Since jpa-api is not a standard name, people will search
> javax.persistence and they will see the group is prefix.
> When is the artifactID not next to the groupId? I don't remember where
Since jpa-api is not a standard name, people will search javax.persistence and
they will see the group is prefix.
When is the artifactID not next to the groupId? I don't remember where that
could happen in ivy or maven but I am no expert here.
On 14 déc. 2009, at 15:22, Steve Ebersole wrote:
>
In pom.xml is still uses file://${maven.repository.root} and looking at
the gradle build file
it also seems to use file based deployment
file://${jbossReleaseRepositoryRoot}
Webdav is used for the snapshot repository. My understanding was webdav
was not working yet for the
main repository du
Hi
It seems as though my email may have been a bit too vague. So I'll try to
explain more or provide some more information to get some advice.
At present none of the mapping class extend any particular interface or
extend any abstract classes so it becomes difficult to a certain extent to
remembe
I am thinking of users here. Since there will be multiple jpa api jars out
there I liked the idea of the jar name itself encoding the fact that this is
the one from hibernate. I think this is more user friendly. I hear what you
are saying though about the ability to bootstrap any/all provider
Synching from where? That project is set up for webdav deployment. Let me
check when I get to my computer...
-- Sent from my Palm Prē
st...@hibernate.org
http://hibernate.orgHardy Ferentschik wrote:
I think I found the answer to my question in another email:
"the syncing to repository.jboss
Guys,
Amin needs feedback.
On 10 déc. 2009, at 21:12, Amin Mohammed-Coleman wrote:
> Hi
>
> I was wondering whether to get some thoughts about the following:
>
> At present none of the mapping classes implement any interface or extend any
> abstract classes. So I was thinking of introducing so
I think I found the answer to my question in another email:
"the syncing to repository.jboss.org is currently broken" :(
On Mon, 14 Dec 2009 10:54:15 -0300, Hardy Ferentschik
wrote:
> just tried to build core, but the following dependency seems to be
> missing
> :
>
> org.hibernate.javax.p
On 14 déc. 2009, at 13:59, Sanne Grinovero wrote:
> You'll find a better explanation in the papers in your dropbox; in
> short: a date is split in multiple fields, like year-month-day (it's
> doing better actually, I'm keeping it simple) and so the number of
> terms is reduced, making a rangequer
Hi
just tried to build core, but the following dependency seems to be missing
:
org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0-CR-1
Looking at the svn log for the jpa api project it seems that Steve already
went
through the release process for this dependency.
The question
Hi hibernate developers,
Since various hibernate releases (3.2, 3.3 , 3.5beta2) I'm still
wondering about following warning when using hibernate with
JDBCTransactionFactory (= without JTA integration):
TransactionManagerLookupFactory:80 - No TransactionManagerLookup
configured (in JTA environm
inline answers:
2009/12/14 Emmanuel Bernard :
>
> On 14 déc. 2009, at 11:15, Sanne Grinovero wrote:
>
>> Even though I'm ok with breaking index compatibility,
>> it looks like option "2" will not break compatibility per-se
>> (other features might) as they state the same compression algorithm is
>
Attached is my current diff against trunk r18223 for you guys to review:
- it introduces org.hibernate.stat.Concurrent* classes that are the JDK5 ones
- I extracted interfaces for the Collection-, Entity-, Query- and
SecondLevelCacheStatistics and have their previous impl. in *Impl.
(the new are
On 14 déc. 2009, at 11:15, Sanne Grinovero wrote:
> Even though I'm ok with breaking index compatibility,
> it looks like option "2" will not break compatibility per-se
> (other features might) as they state the same compression algorithm is
> being used, just
> they don't apply it automatically
javax.persistence is owned by "Sun" as spec lead.
And more concretely, they don't publish the spec jars to maven repos under an
open source license. So our lawyers asked us to use a clean code.
Emmanuel
On 14 déc. 2009, at 11:18, Sanne Grinovero wrote:
> out of curiosity, why not drop org.hibe
out of curiosity, why not drop org.hibernate?
javax.persistence:jpa-2.0-api:1.0.0-SNAPSHOT
are there more api vendors ?
Cheers,
Sanne
2009/12/14 Emmanuel Bernard :
> I would use
> org.hibernate.javax.persistence:jpa-2.0-api:1.0.0-SNAPSHOT
>
> Because while there is code written by us, it's not s
Even though I'm ok with breaking index compatibility,
it looks like option "2" will not break compatibility per-se
(other features might) as they state the same compression algorithm is
being used, just
they don't apply it automatically anymore (and the Store.Compress
isn't defined in 3.0)
Actuall
I would use
org.hibernate.javax.persistence:jpa-2.0-api:1.0.0-SNAPSHOT
Because while there is code written by us, it's not specific to Hibernate and
can bootstrap all providers on the market.
On 11 déc. 2009, at 22:24, Steve Ebersole wrote:
> Of course that should be
> org.hibernate.javax.persi
2. is not backward compatible index-wsie, is it?
Are we ok to break backward compatibility on indexes?
On 13 déc. 2009, at 23:41, Sanne Grinovero wrote:
> Hi all,
> I'm trying to migrate Hibernate Search to Lucene 2.9;
> As you might now the COMPRESS store option is not supported in 3.0
> so I ha
30 matches
Mail list logo
