Re: [hibernate-dev] Fwd: [Hibernate-JIRA] Closed: (HHH-5616) Switch to Gradle for builds
by Steve Ebersole
Looks guys I know change is tough for people. But this constant whining is
getting old. And it does not fix anything. We are using Gradle. Period.
End of story.
So now, can we move past that and work on fixing things?
On Friday, October 15, 2010, at 05:56 am, Galder Zamarreño wrote:
> And to top it up, since move to gradle, my testsuite hangs in a test where
> it never used to do before.
>
> So, so far, pretty unhappy about the move to gradle :(
>
> On Oct 15, 2010, at 12:43 PM, Galder Zamarreño wrote:
> > Where are you supposed to execute 'gradle idea' from? If I execute it from
the root, the IML files created are pointing to the wrong dependencies, i.e.:
> > •
> > /Users/.gradle/cache/org.infinispan/infinispan-core/jars/infinispan-
cor
> > e-4.2.0.ALPHA1.jar
> >
> > Clearly, this should be pointing to:
> > •
> > /Users/z/.gradle/cache/org.infinispan/infinispan-core/jars/infinispan-
c
> > ore-4.2.0.ALPHA1.jar
> >
> > Any idea what is wrong? I can't compile anything from IDEA
> >
> > On Oct 14, 2010, at 8:07 PM, Steve Ebersole wrote:
> >> FYI, I wrapped this up into a blog entry:
> >> http://in.relation.to/Bloggers/HibernateGradlePointers
> >>
> >> On Monday, October 11, 2010, at 08:58 pm, Steve Ebersole wrote:
> >>> I should have pointed out some of the basic commands you'll commonly
> >>> need. All these can be found in the Gradle User Guide:
> >>> http://www.gradle.org/0.9-rc-1/docs/userguide/userguide_single.html
> >>>
> >>> Most of the stuff we are interested in comes from the Java plugin:
> >>> http://www.gradle.org/0.9-
> >>> rc-1/docs/userguide/userguide_single.html#java_plugin
> >>>
> >>> Here is a list of the ones you will currently be using (from any
> >>> project in gradle you can get a list of available tasks by executing
> >>> `gradle -t`):
> >>>
> >>> 1) build - Assembles (jars) and tests this project.
> >>> 2) buildDependents - Assembles and tests this project and all projects
> >>> that depend on it. So think of running this in
> >>> hibernnate-entitymanager.. Gradle would assemble and test
> >>> hibernate-entitymanager as well as hibernate-envers (because envers
> >>> depends on entitymanager).
> >>> 3) classes - compiles the main classes
> >>> 4) clean - Deletes the build directory.
> >>> 5) jar - Generates a jar archive with all the compiled classes.
> >>> 6) testClasses - Assembles the test classes.
> >>> 7) test - Runs the unit tests
> >>> 8) uploadArchives - think Maven deploy
> >>>
> >>> Especially those of you developing Search, Validator, etc should know
> >>> about an additional task:
> >>> 9) install - installs the project jar to your local maven cache (aka
> >>> ~/,m2/repository)
> >>>
> >>> In the root project you can perform any task and Gradle will attempt to
> >>> perform it on each subproject.
> >>>
> >>> That should be enough to get you going.
> >>>
> >>> Oh and you can also execute multiple tasks:
> >>> `gradle clean build` runs both the clean and build tasks
> >>>
> >>> On Monday, October 11, 2010 05:45:29 pm Steve Ebersole wrote:
> >>>> I have switched HEAD of hibernate-core to use Gradle for builds. I
> >>>> still need to finish up some tasks, but they mostly deal with the
> >>>> release process for which I created a follow-up issue.
> >>>>
> >>>> You can either install Gradle and use the gradle command, or you can
> >>>> use "gradle wrapper" by using the ./gradlew (or ./gradlew.bat files
> >>>> for our Windows friends).
> >>>>
> >>>> ---------- Forwarded Message ----------
> >>>>
> >>>> Subject: [Hibernate-JIRA] Closed: (HHH-5616) Switch to Gradle for
> >>>> builds Date: Monday, October 11, 2010, 04:46:57 pm
> >>>> From: "Steve Ebersole (JIRA)" <noreply(a)atlassian.com>
> >>>> To: steve(a)hibernate.org
> >>>>
> >>>> [
> >>>>
> >>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5616?pag
> >>>> e=c om .atlassian.jira.plugin.system.issuetabpanels:all- tabpanel ]
> >>>>
> >>>> Steve Ebersole closed HHH-5616.
> >>>> -------------------------------
> >>>>
> >>>> Resolution: Fixed
> >>>>>
> >>>>> Switch to Gradle for builds
> >>>>> ---------------------------
> >>>>>
> >>>>> Key: HHH-5616
> >>>>
> >>>>> URL:
> >>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5616
> >>>>
> >>>>> Project: Hibernate Core
> >>>>>
> >>>>> Issue Type: Task
> >>>>> Components: core
> >>>>>
> >>>>> Reporter: Steve Ebersole
> >>>>> Assignee: Steve Ebersole
> >>>>>
> >>>>> Fix For: 4.0.0.Alpha1
> >>>>>
> >>>>> Time Spent: 23h
> >>>>>
> >>>>> Remaining Estimate: 0h
> >>>>>
> >>>>> http://gradle.org
> >>
> >> ---
> >> Steve Ebersole <steve(a)hibernate.org>
> >> http://hibernate.org
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > --
> > Galder Zamarreño
> > Sr. Software Engineer
> > Infinispan, JBoss Cache
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 2 months
Hibernate-infinispan tests disabled, why?
by Galder Zamarreño
I've just spotted that the hibernate-infinispan gradle file says:
test {
environment['java.net.preferIPv4Stack'] = true
environment['jgroups.ping.timeout'] = 500
environment['jgroups.ping.num_initial_members'] = 1
environment['jgroups.udp.enable_bundling'] = false
// environment['jgroups.bind_addr'] = $jgroupsBindAddress
// quite a few failures and the old maven module disabled these tests as well
enabled = false
}
I know for fact that the Infinispan testsuite runs at 100% these days, so it'll be interesting to enable tests again and find out what can be done about those issues.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 2 months
Re: [hibernate-dev] Fwd: [Hibernate-JIRA] Closed: (HHH-5616) Switch to Gradle for builds
by Galder Zamarreño
Acutally, just found it in http://docs.codehaus.org/display/GRADLE/Gradle+0.8+Breaking+Changes
gradle -xtest clean build
On Oct 14, 2010, at 4:02 PM, Galder Zamarreño wrote:
> How do you run a build skipping test execution?
>
> I've tried the following but no luck: gradle -Dskip.tests=true clean build
>
> On Oct 12, 2010, at 3:58 AM, Steve Ebersole wrote:
>
>> I should have pointed out some of the basic commands you'll commonly need.
>> All these can be found in the Gradle User Guide:
>> http://www.gradle.org/0.9-rc-1/docs/userguide/userguide_single.html
>>
>> Most of the stuff we are interested in comes from the Java plugin:
>> http://www.gradle.org/0.9-
>> rc-1/docs/userguide/userguide_single.html#java_plugin
>>
>> Here is a list of the ones you will currently be using (from any project in
>> gradle you can get a list of available tasks by executing `gradle -t`):
>>
>> 1) build - Assembles (jars) and tests this project.
>> 2) buildDependents - Assembles and tests this project and all projects that
>> depend on it. So think of running this in hibernnate-entitymanager.. Gradle
>> would assemble and test hibernate-entitymanager as well as hibernate-envers
>> (because envers depends on entitymanager).
>> 3) classes - compiles the main classes
>> 4) clean - Deletes the build directory.
>> 5) jar - Generates a jar archive with all the compiled classes.
>> 6) testClasses - Assembles the test classes.
>> 7) test - Runs the unit tests
>> 8) uploadArchives - think Maven deploy
>>
>> Especially those of you developing Search, Validator, etc should know about an
>> additional task:
>> 9) install - installs the project jar to your local maven cache (aka
>> ~/,m2/repository)
>>
>> In the root project you can perform any task and Gradle will attempt to
>> perform it on each subproject.
>>
>> That should be enough to get you going.
>>
>> Oh and you can also execute multiple tasks:
>> `gradle clean build` runs both the clean and build tasks
>>
>> On Monday, October 11, 2010 05:45:29 pm Steve Ebersole wrote:
>>> I have switched HEAD of hibernate-core to use Gradle for builds. I still
>>> need to finish up some tasks, but they mostly deal with the release
>>> process for which I created a follow-up issue.
>>>
>>> You can either install Gradle and use the gradle command, or you can use
>>> "gradle wrapper" by using the ./gradlew (or ./gradlew.bat files for our
>>> Windows friends).
>>>
>>> ---------- Forwarded Message ----------
>>>
>>> Subject: [Hibernate-JIRA] Closed: (HHH-5616) Switch to Gradle for builds
>>> Date: Monday, October 11, 2010, 04:46:57 pm
>>> From: "Steve Ebersole (JIRA)" <noreply(a)atlassian.com>
>>> To: steve(a)hibernate.org
>>>
>>>
>>> [
>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5616?page=com
>>> .atlassian.jira.plugin.system.issuetabpanels:all- tabpanel ]
>>>
>>> Steve Ebersole closed HHH-5616.
>>> -------------------------------
>>>
>>> Resolution: Fixed
>>>
>>>> Switch to Gradle for builds
>>>> ---------------------------
>>>>
>>>> Key: HHH-5616
>>>
>>>> URL:
>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5616
>>>
>>>> Project: Hibernate Core
>>>>
>>>> Issue Type: Task
>>>> Components: core
>>>>
>>>> Reporter: Steve Ebersole
>>>> Assignee: Steve Ebersole
>>>>
>>>> Fix For: 4.0.0.Alpha1
>>>>
>>>> Time Spent: 23h
>>>>
>>>> Remaining Estimate: 0h
>>>>
>>>> http://gradle.org
>>
>> --
>> Steve Ebersole <steve(a)hibernate.org>
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 2 months
Gradle build problems
by Hardy Ferentschik
Hi,
it seems that some people have problems building the latest trunk version
of Hibernate Core.
I was one of them and after figuring out where goes what in the new build
I found this:
Caused by: org.h2.jdbc.JdbcSQLException: Cannot change the setting
"MVCC" when the database is already open; SQL statement:
SET MVCC TRUE [90133-134]
at
org.h2.message.DbException.getJdbcSQLException(DbException.java:316)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.get(DbException.java:144)
at org.h2.command.dml.Set.update(Set.java:233)
at org.h2.command.CommandContainer.update(CommandContainer.java:70)
at org.h2.command.Command.executeUpdate(Command.java:198)
at org.h2.engine.Engine.openSession(Engine.java:159)
at org.h2.engine.Engine.getSession(Engine.java:120)
at org.h2.engine.Session.createSession(Session.java:119)
at
org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:237)
at
org.h2.engine.SessionRemote.createSession(SessionRemote.java:215)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:111)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:95)
at org.h2.Driver.connect(Driver.java:58)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at
org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:133)
at
org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
This led me to the file
hibernate-core/src/test/resources/hibernate.properties where I removed the
MVCC=TRUE from the connection url.
Now the tests passed. I am not sure yet why this option seems to make a
difference on some systems and not on others, but in case you are
having build problems as well try modifying the driver url (at least for
now).
This might be JDK/OS related, since so far t only affected me and Emmanuel
and we are both using Mac with the provided JDK 1.6.
In case you have any idea why this option makes a difference let us know.
--Hardy
14 years, 2 months
Hibernate 4 and the hibernate3.jar file in release bundle
by Steve Ebersole
Basically this comes down to whether we want to continue to provide an uber-
jar of all Hibernate classes.
Currently we do this for the release bundles as hibernate3.jar
Do we want to continue this practice into 4.x? If we are going to do it, then
I think we should be consistent and also provide the same through the Maven
repository. So to me either:
1) Provide option for uber-jar both in release bundles and in JBoss Maven
repository (as separate artifactId)
2) Completely stop providing the uber-jar option.
Have also been thinking about whether it makes sense to provide "guidance" on
different base setups. This is mostly unrelated to the discussion above, but
there is a bearing. Mostly people want the uber-jar because they find it
easier then naming 3 jars to get hibernate+c3p0 up and running (for example).
But if we had a way for them to do this easier maybe it lessens the need for
the uber-jar even more. Initially for "guidance" I was thinking ivy
configurations since I think ivy is available pretty ubiquitously (can't you
even use ivy from maven?); plus the fact that you can name custom
configurations and mix them together make it much more flexible and
simultaneously much less verbose than poms for this purpose. So in their
projects, instead of depending on "hibernate" they could depend on the ivy
configuration "hiberate+c3p0".
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 2 months
GenericConstraintDef extends raw ConstraintDef
by Dag Hovland
Hi!
We were wondering why
org.hibernate.validator.cfg.defs.GenericConstraintDef
extends the raw type ConstraintDef ? Using maven, it compiles, but in Eclipse (with jdk-1.6) We get
the following error:
"Name clash: The method groups(Class<?>...) of type GenericConstraintDef has the same erasure as
groups(Class...) of type ConstraintDef but does not override it"
and similar for the method "payload". The others methods give no errors. We do not understand why,
but it compiles after changing the definition to
public class GenericConstraintDef<A extends Annotation>
extends ConstraintDef<A>
and also replacing the "Class<?>" in the argument to the method "constraintType" with "Class<A>.
Regards,
Dag Hovland and Federico Mancini
14 years, 2 months
Hibernate Core is now using Git
by Emmanuel Bernard
Hibernate Core now uses Git as the version control system.
You can access it at http://github.com/hibernate/hibernate-core
Core on Git
We have imported the SVN history (at least what GIT could extract) and pushed the SVN trunk, branch 3.5 and branch 3.3. If you need more of the legacy branches or tags, let me know, that can be arranged.
If you want to contribute a fix or new feature, either use the pure Git approach, or use the GitHub fork capability (see http://help.github.com/forking/ and http://help.github.com/pull-requests/ ) The benefit of the GitHub approach is that we can comment on the pull request and code though I am far from an expert so far and their flow could easily be improved (slightly confusing).
If you still want to do it the old way a provide a patch file, that's ok too.
Tips on Git
Here are some tips on Git:
o read Pro Git http://progit.org/book/ awesome book and very practical. It has a free html and epub version (buying the tree version is recommended to repay the author).
o prefer the git protocol when cloning over http (so say the experts). At the very least that will be much faster. cloning the repo from GitHub took me less than 3 minutes
#for people with read/write access
git clone git@github.com:hibernate/hibernate-core.git
#for people with read-only access
git clone git://github.com/hibernate/hibernate-core.git
It will create a "remote" link named origin. I usually tend to rename it to reflect what it is really.
git remote rename origin core-on-github
o always work on a topic branch and merge your work when you are done
git checkout master
git checkout -b HHH-XXX
hack commit hack commit
Likewise if you want to share a work with somebody from the Hibernate team, push or define the pull request of your topic branch (though make sure your topic branch is above master).
o prefer small commits, they will be more readable and will very unlikely fail on merge
o write good comments (short one line including the issue at stack followed by a blank line and a more detailed explanation if needed)
`HHH-XXX Fix NPE on persist
Fix stupid bug by Gavin that lead to a NPE when persisting objects with components`
o prefer rebase over merge
Rebase put changes from the branch you forked below the new commits you have done and thus keep the history linear.
got checkout HHH-XXX
git rebase master
DO NOT rebase a branch that you have shared publicly (unless you know people won't use it or you wish them harm).
o while you are at rebasing, you can rewrite your commit history to clean comments or merge some commits together (named squashing)
git rebase -i HEAD~6 (go back 6 commits in time)
o once you're fed up with typing longish command lines, use aliases (see below)
o I've put a copy of my ~/.gitconfig file in case people want to copy some things including aliases (see below)
o if you use Mac OS X, GitX is a fantastic tool, in particular to do interactive staging and commit only some parts of a file
o you can read this blog entry that was some more info http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-sinc...
o feel free to add your tips to this email thread, I'll likely compile them in a blog entry.
~/.gitconfig
[user]
name = Redacted
email = redacted(a)redacted.com
signingkey = id_key.pub
[core]
editor = open -nW -a Smultron
[merge]
tool = opendiff
[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color "status"]
added = yellow
changed = green
untracked = cyan
[github]
user = redacted
token = redacted
[alias]
co = checkout
undo = reset --hard
cb = checkout -b
br = branch
cp = cherry-pick
14 years, 2 months
