[hibernate-dev] Gradle branch

[Hardy Ferentschik]

hi,

some thoughts. First, should the current gradle branch compile out of the  
box?

I did the following:

svn co https://svn.jboss.org/repos/hibernate/core/branches/gradle2  
gradle-branch
cd gradle-branch
gradle build

It did some downloading and it completed the build of core, but then all  
tests in
Annotations failed. A quick look seems to suggest that resource filtering  
is not working
yet. If this is not expected to work, because it's work in progress it's  
fine with me,
but I think we should mention it somewhere. Or if I need to configure  
anything else it
should be mentioned as well :)

That said, I was looking on the wiki if we have some sort of page where we  
document our
gradle experience. I couldn't find one. I think we should create one with  
instructions
on how to build the current prototype. On this page we can then also start  
a discussion about
our experiences. WDYT?

Btw, while searching for Gradle on the wiki I found this comparison  
between Maven vs Gradle -
http://community.jboss.org/wiki/MavenVsGradle

--Hardy


On Thu, 03 Jun 2010 00:12:43 +0200, Steve Ebersole <steve at hibernate.org>  
wrote:

> Wanted to point out that I have a new Gradle PoC branch in SVN at
> https://svn.jboss.org/repos/hibernate/core/branches/gradle2  Of special
> interest, this branch supports generating intellij project from the
> source.  The Gradle guys have been really awesome in helping me to get
> this ready.  You'll need at least the 0.9-preview2 release and you'd
> simply run 'gradle idea' to generate the intellij project.
>
> If anyone is really averse to installing gradle on their machines we
> could try generating a wrapper too:
> http://mrhaki.blogspot.com/2010/05/gradle-goodness-use-gradlew-for-easy.html
>
> Its still a work in progress, but I think it shows the promise of using
> gradle.  Really the only parts missing at this point are:
> 1) integrating the testing (testsuite, jdbc3 and jdbc4 testing) stuff
> which I have been waiting to do a "better way" leveraging Gradle
> strengths (because it allows more than one artifact per project)
> 2) doing docbook builds
> 3) special handling for building a release
>