Hi Igor,
On Apr 6, 2009, at 1:30 PM, Igor Sereda wrote:
Tom,
Thanks for your reply. I think I did try adding test-classes to
unmanagedClasspath and that introduced some other problem. A week
after my
original question I already don't remember what the problem was :)
We decided not to go with Gradle, I'm sorry to say, and chose Gant.
Here's
our story in brief, in case anyone's interested.
We have a project with lots of modules (more than 100 is expected).
Everyone
here uses IntelliJ IDEA, so we decided to use IDEA's .iml and .idea
files as
the primary source of inter-module and library dependencies. We
don't care
much about libraries' transitive dependencies, we store all libs in
svn and
don't enjoy any downloading from the Internet during build.
With so many modules it is a brave choice to use IDEA files for this.
Not just that you don't have the information about transitive
dependencies. What about test, compile and runtime? What about
reports? This pretty much sounds like jar hell to me. On the other
hand, it is not the job of Gradle to decide how people should set up
there build. For your scenario the Gradle support will be improved in
the future. For example it will be possible to just declare a
directory and all the jar's in this directory are added to the
classpath. We will get rid of different concepts for managed and
versioned jars vs. unmanaged jars. You can expect this for 0.7.
As you know, Gradle does support dependency management for jar's in
svn (although you don't like the syntax :)).
We used to produce parts of Ant script with XSLT transformation from
the
original source of inter-module dependencies. That would give us
targets
compile.A, compile.B, and so on - and also classpaths, testing and
other
targets and stuff up to the stage where all artifacts are bundled
together.
That was terrible to write and even to look at, I must say.
With Gant, the horror of XSLT is gone. We have a single closure that
produces per-module targets for module X. All other problems with
Ant, like
lack of "if"s, are gone. Parsing IDEA's files is trivial. Everything's
perfect. Gee, you can even debug your script in IDEA!
Gradle is everything Gant is, and more? Right. With Gradle, we found
another
level of complexity and obscurity introduced.
But this level is optional. You can use Gradle in the same plain way
as you can use Gant. With additional goodies like multi-project build
support. In some areas Gant offers functionality Gradle does not
provide yet (e.g. build.xml integration, which is scheduled for Gradle
0.7).
To understand what's going on
or how to do something, current documentation is hardly enough. I've
had to
go through the source code quite a few times and browse this mailing
list.
Learning ivy seems very necessary. The API is far from obvious (why
on Earth
to add a library to classpath I have to call something named
addClientModule? what does the "name" parameter mean and why it
should be
"lib"? /rhetorical questions/).
There are some warts in our API. We are aware of that. But it is not a
big deal to solve this. One focus for Gradle 0.6/0.7 is to improve
this and make the API more intuitive and concise.
I hope I didn't miss something obvious about Gradle that would turn
it from
magic into science for me. I understand the project is still in its
early
versions, and I'm totally enthusiastic about any tools that would
reduce the
complexity of build scripts for projects like ours. I understand that
complexity is replaced with conventions sometimes, but I believe
those must
be open and easily configurable, otherwise the cost beats the purpose.
I completely agree. The driving vision behind Gradle is 'toolset over
framework'. Another focus for Gradle 0.6/0.7 is to come closer to this
vision. But I think already in 0.5 we have achieved a lot in this
respect.
So guys, thanks again for your effort, I hope to take a look at Gradle
sometimes later. If you need more input about our use case, feel
free to
write me.
Many thanks for your feedback. We are looking forward to get you back
with a later version of Gradle :).
Cheers,
- Hans
Cheers,
Igor
Tom Eyckmans wrote:
2009/3/30 Igor Sereda <[email protected]>
Hello to the list.
I'm trying to set up a Gradle build instead of overly complex Ant
build.
So
far it looks promising, so thanks and kudos to Hans and guys!
Thanks!
The first bump for me is that, from what I see, test classes in one
project
are not available in test classpath in another project within the
same
build.
The build.gradle looks something like that:
project(":A") {
dependencies {
testCompile ':junit:0'
}
}
project(":B") {
dependencies {
compile project(':A')
testCompile project(':A')
testCompile ':junit:0'
}
}
Some tests in B use fixtures and stuff defined in test sources in
A. The
classpath used to compile B tests includes main classes from A but
not
test
classes.
Am I missing something here?
I don't think so, it is just not done automatically at the moment,
but I
think it is a good idea to make this possible. I wouldn't make it the
default but make it so that when you declare a dependency on
project A in
B
in the testCompile dependency configuration you are depending on
the test
configuration of project A.
If that's on purpose, is there a workaround?
Yes there is a workaround, you can add the build/test-classes
directory of
project A to the unmanagedClasspath attribute of the test task in the
project B build file.
--
View this message in context:
http://www.nabble.com/Test-classes-dependency-in-multi-project-builds-tp22787955p22906955.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
