[hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

https://hibernate.atlassian.net/browse/HHH-8219 https://hibernate.atlassian.net/browse/HHH-8220 - Best Regards, Strong Liu http://about.me/stliu/bio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lis

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

For the HHH-8219 - usage of JDK 7 API - I'm working on integrating the Animal Sniffer plug-in to check that only Java 6 classes are used in the code base. --Gunnar 2013/5/3 Strong Liu > > https://hibernate.atlassian.net/browse/HHH-8219 > > https://hibernate.atlassian.net/browse/HHH-8220 > > >

Re: [hibernate-dev] Checkstyle breaking the OGM build

I found the problem, not sure where that comes from though. On a fresh repo clone it works as expected. So I did diff the two and found that the failing version has lines ending as CRLF (Windows) and the fresh repo has lines ending as LF (Unix). On Fri 2013-05-03 8:32, Gunnar Morling wrote: > Wo

Re: [hibernate-dev] Checkstyle breaking the OGM build

Did you get the latest patch (added by Davide) to fix the endofline issue ? 2013/5/3 Emmanuel Bernard > I found the problem, not sure where that comes from though. > > On a fresh repo clone it works as expected. So I did diff the two and > found that the failing version has lines ending as CRLF

Re: [hibernate-dev] Checkstyle breaking the OGM build

Ah, it may then be that you have to re-normalize the line endings in your existing checkout as described in [1]: git rm --cached -r .# Remove everything from the index. git reset --hard# Write both the index and working directory from git's database. [1] https://help.github.com/articles/d

Re: [hibernate-dev] hibernate dialect for hana

Why not? Especially as Hana looks extremely interesting. I recall some discussion about having the database vendors maintain them, but to go that route we could at least document how it works and make sure it's easy enough for end users. I think I'd prefer to see if database vendors are willing t

Re: [hibernate-dev] hibernate dialect for hana

I think the main reason is the lack of dev resource, if someone is willing to promise that long time contribution / maintains, I'm fine with that, or it will just become some dead code that we don't have knowledge nor time to maintains. On May 3, 2013, at 4:47 PM, Sanne Grinovero wrote: > Why

Re: [hibernate-dev] hibernate dialect for hana

But we can definitely have a wiki page or even better a table in the documentation for third party dialects and where they are hosted. That' cheap for us and keep the ecosystem thriving. Emmanuel On Fri 2013-05-03 17:17, Strong Liu wrote: > I think the main reason is the lack of dev resource, if

Re: [hibernate-dev] A synchronous JGroups backend for Hibernate Search

I did not think of that but an "implicit" or "auto" setting makes some sense. Just to be sure, the new immplicit setting / behavior will break the semantic of what's going on so it should at least but a minor version bump. Correct? BTW, did you guys even found out why using sync was taking so much

Re: [hibernate-dev] hibernate dialect for hana

+1 But I'd really like to see - for example - Oracle providing free to use (and hosted) RDBMS instance, 10gen a MongoDB instance, etc.. so they can update it as they see fit and deal with the maintenance aspects of it (and licencing + execution costs). Ideally if someone - like Andrew in this cas

Re: [hibernate-dev] A synchronous JGroups backend for Hibernate Search

On 3 May 2013 10:47, Emmanuel Bernard wrote: > I did not think of that but an "implicit" or "auto" setting makes some > sense. > Just to be sure, the new immplicit setting / behavior will break the > semantic of what's going on so it should at least but a minor version > bump. Correct? Correct, t

Re: [hibernate-dev] A synchronous JGroups backend for Hibernate Search

> I did not think of that but an "implicit" or "auto" setting makes some > sense. > Just to be sure, the new immplicit setting / behavior will break the > semantic of what's going on so it should at least but a minor version > bump. Correct? > > BTW, did you guys even found out why using sync was

Re: [hibernate-dev] hibernate dialect for hana

Hi, On 2013-05-03 17:17:28 +0800, Strong Liu wrote: > I think the main reason is the lack of dev resource, if someone is > willing to promise that long time contribution / maintains, I'm fine > with that, or it will just become some dead code that we don't have > knowledge nor time to maintains.

Re: [hibernate-dev] improved Eclipse project support

Hi Steve, I've pushed some commits for using the Animal Sniffer plug-in to discover the usage of Java 7 APIs to my fork [1]. This uses the Ant task and fails the build when using methods not existent in Java 6 such as emptyIterator(). I'm still in the process of testing this but thought it would

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

I dont understand what you mean with HHH-8220. OK its a change, but how is that breaking any builds? And for JDK 7 we have discussed that on this list already. Gunnar will work on integrating some checks into the build to make sure we are not using JDK 7 features... On 05/03/2013 02:08 AM, S

Re: [hibernate-dev] improved Eclipse project support

I'll take a look. Thanks Gunnar! On Fri 03 May 2013 06:13:53 AM CDT, Gunnar Morling wrote: > Hi Steve, > > I've pushed some commits for using the Animal Sniffer plug-in to > discover the usage of Java 7 APIs to my fork [1]. This uses the Ant > task and fails the build when using methods not exist

Re: [hibernate-dev] hibernate dialect for hana

We've never said we were not accepting new dialects. What was said is that there needs to be some accountability for new dialects. Sounds like we have that here... On 05/03/2013 05:37 AM, Andrew Clemons wrote: > Hi, > > On 2013-05-03 17:17:28 +0800, Strong Liu wrote: >> I think the main reason

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

On May 3, 2013, at 8:13 PM, Steve Ebersole wrote: > I dont understand what you mean with HHH-8220. OK its a change, but how is > that breaking any builds? > suppose there is a WAR project that uses hibernate, and it has a compile scope dependency of h-em before this 4.3.0.Beta2, the HEM wi

[hibernate-dev] Developer IRC Meeting - 5/2

Unfortunately my internet connection was spotty today... [11:14] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-05-02-15.03.html [11:14] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

Have you tried this? Runtimr and compile scopes are both transitive, so the situation you describe should work just as before On 05/03/2013 07:23 AM, Strong Liu wrote: > > On May 3, 2013, at 8:13 PM, Steve Ebersole > wrote: > >> I dont understand what you mean

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

sorry, I missed the provided scope and runtime scope the problem is : now hibernate-core is a runtime scope dependency of h-em so, suppose a project depends on h-em ( compile scope ) and the project uses h-core classes, then the project won't be compiled. since runtime scope dependencies are no

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

Well purists would argue that relying on transitivity for dependencies that you need for *compilation* is a baad idea. In fact Maven's own primer to dependency management discusses this very thing: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html spe

Re: [hibernate-dev] [OGM] Metamodel

Hello Davide, Technically most of the knowledge is in https://hibernate.atlassian.net/browse/OGM-208 but it's definitely quite blurry for a new comer ;) Let me try and summarize it for you. With that you'll be able to better grasp the comments in OGM-208 ## Goals We want a metadata facility as

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

I asked about this on the gradle-dev list. Seems likely this is a change stemming from the new publishing dsl which i just switched Hibernate to use. On Fri 03 May 2013 08:12:40 AM CDT, Steve Ebersole wrote: > Well purists would argue that relying on transitivity for dependencies > that you ne

[hibernate-dev] Scripting releases - SourceForge

I am working on scripting more of the release steps into the Gradle build scripts. When it comes to uploading the release bundles to SourceForge we have a choice to make. I will use rsync since we already require people doing a release to have it installed because docs.jboss.org uploads requi

Re: [hibernate-dev] Scripting releases - SourceForge

Maybe you could reuse the scripts Hardy built for HV (to be found in the HV project under distribution/src/scripts)? This release script expects the SF user to be specified as argument when invoking the script. --Gunnar - sent from my mobile phone - Am 03.05.2013 18:42 schrieb "Steve Ebersole" :

Re: [hibernate-dev] Scripting releases - SourceForge

+1 for listing the users Brett Meyer Red Hat Software Engineer, Hibernate - Original Message - From: "Steve Ebersole" To: "hibernate-dev" Sent: Friday, May 3, 2013 12:41:35 PM Subject: [hibernate-dev] Scripting releases - SourceForge I am working on scripting more of the release steps

Re: [hibernate-dev] Scripting releases - SourceForge

can't you just omit the users? I would assume that it's going to use rsync over SSH, so it should pick the user I've defined for this server in my own ~/.ssh/config On 3 May 2013 17:54, Brett Meyer wrote: > +1 for listing the users > > Brett Meyer > Red Hat Software Engineer, Hibernate > > ---

Re: [hibernate-dev] Scripting releases - SourceForge

To clarify, this is the "interesting" part of my ~/.ssh/config : http://pastebin.com/raw.php?i=tBq91kMH As you can see, I specify the user it's going to use in the file on a per-server basis. Very convenient, so I don't have to remember these details, and also you can specify the correct key. On

Re: [hibernate-dev] hibernate dialect for hana

Andrew, could you create a pull request against our master branch and add your dialect to hibernate-core/src/main/java/org/hibernate/dialect? We'll take a look. Email me if you need help creating the PR. Brett Meyer Red Hat Software Engineer, Hibernate - Original Message - From: "Stev

Re: [hibernate-dev] Scripting releases - SourceForge

We *could*. But that obviously requires a different level of system-level assumptions. If we all agree to that then fine. I am going to leave the doc upload as is for now, mainly because that one is less in our control. On Fri 03 May 2013 12:16:07 PM CDT, Sanne Grinovero wrote: > To clarify,

Re: [hibernate-dev] Scripting releases - SourceForge

On 3 Jan 2013, at 6:41 PM, Steve Ebersole wrote: > Preferences? > > Personally I'd rather just use our own users and account for the > different usernames in the script (read from ~/.gradle/gradle.settings > maybe). +1, I think the best way is to use the users own account. Everyone can uploa