Hi Phil,
sorry for not answering earlier.
On May 11, 2008, at 11:55 PM, pbarnes wrote:
First question, relating to multi-project builds:
I have three web applications and a background application that all
depend
on a 'core' custom library that is basically driven by Spring and
Hibernate.
Currently my directory structure is something like:
\projects\WebApp1\
\projects\WebApp2\
\projects\WebApp3\
\projects\BackgroundApp\
\projects\Core\
\projects\Web\
Where Core contains shared services and data access, and Web
contains shared
web framework classes and utilities.
You can structure it like above but you could also structure it like:
projects/Core
projects/BackgroundApp
projects/Web
projects/Web/WebAppX
The Web project could have two roles. One role is to provide shared
configuration, the other is to provide a library.
In the Web gradlefile you could configure for example the subprojects
like:
dependencies {
compile project(':Core')
}
subprojects {
usePlugin('java')
type = 'war'
dependencies {
compile "javax:servlet-api:2.5", project(':Web'),
project(':Core')
}
}
If a subproject does not have any other specific behavior, you might
not even need to provide a gradefile for it.
I don't know whether Web has a direct dependency on Core and whether
the WebAppX projects have such a direct dependency. If both have a
direct dependency you might do it as above. If the WebAppX does not
have one, only Web itself, you would remove project(':Core') from the
subproject dependencies declarations.
If I understand the documentation correctly, I could have a
'gradlefile' in
each of the subdirectories with dependsOn(':Core') for all the
applications
and additionally dependsOn(':Web') for the three web applications.
A gradlefile can be in every project but is optional. If you use
configuration injection you might not use one. Or you use a
gradlefile to define the specific stuff for a particular project
(e.g. WebApp3), and declare the common things of all WebApps in the
Web project's gradlefile.
However, I'm not sure what to do with the 'gradlesettings' file. I
could
"include 'Core', 'Web', 'WebApp1', 'WebApp2', 'WebApp3',
'BackgroundApp'",
but I wasn't sure this was the right approach, since WebApp1,2,3
are all
really independent of one another, and of course so is BackgroundApp.
This is the right approach. You need to include all projects which
should take part in the build independent of there relationships.
Second question, related to dependencies: I'm probably going to
show my
ignorance with Ivy here, but here goes. ;)
In the above example, I can specify my dependencies fine for
compile time,
and the project compiles fine. However, when I try to run "gradle
dists" I
run into issues with what I assume are "runtime dependencies" from my
"compile dependencies" as I see non-optional Hibernate dependencies
are
pulled down (i.e. ehcache, asm-attrs, etc.). But for Sun jars,
such as
'jta.jar' these aren't available in the Maven repository (I assume
due to
license). However, the Hibernate POM describes this dependency as
required
and therefore I assume Ivy tries to retrieve it, fails, and the build
terminates.
Is my only recourse here to create my own clientModule with the
correct
dependencies or is there some way I can 'override' where this one
dependency
is looked up? It doesn't seem to follow any of the
classpathResolvers.add()
that I specified, and always (only) looks to the Maven rep.
The usual Ivy behavior is that the resolver that finds the pom is
also responsible for retrieving the jar. As Ivy allows to assign
multiple URL's to resolvers this is not really a problem. But the way
Gradle integrates the MavenRepo makes life harder than necessary for
your I think very common use case. I have filed an issue to make this
more convenient: http://jira.codehaus.org/browse/GRADLE-91
The way you have to do this now is to add another resolver.
I have to catch my plane right now and will paste the snippet how to
do this in another reply hopefully coming soon.
- Hans
Thanks in advance,
Phil..
--
View this message in context: http://www.nabble.com/How-should-one-
structure-multi-project-builds--tp17178473p17178473.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
