hdockter wrote:
>
> Hi Phil,
>
> sorry for not answering earlier.
>
No problem - real life always seems to get in my way too. ;)
hdockter wrote:
>
> [...snipped to shorten length...]
>
>> 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.
>
Ok, so I'm guessing that the 'gradlesettings' file is used to determine
inter-project dependencies. But can't this already be inferred from the
"dependsOn()" methods? Say 'WebApp1' depeondsOn(':Web'), and 'Web'
dependsOn(':Core'), what exactly is the 'gradlesettings' file adding to the
process?
And in my case, I *usually* only want to build WebApp1 OR WebApp2 OR WebApp3
- not all 3 at once. It just so happens that all 3 dependsOn(':Core'), so
they're all at the same 'root project' level.
hdockter wrote:
>
>>
>> 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.
>
Yeah, I was assuming this was the way to do it. But are there different
resolvers for compile time versus run time? Because, as noted in my
original message, I added new resolvers via classpathResolvers.add(), but
these are only 'checked' by Ivy at compile time and are not respected when
resolving runtime dependencies (i.e., I don't see any attempt to use the
resolvers when it's trying to resolve Hibernate's runtime dependencies).
hdockter wrote:
>
> I have to catch my plane right now and will paste the snippet how to
> do this in another reply hopefully coming soon.
> - Hans
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
Thanks Hans - I appreciate your help and look forward to your snippet. ;)
Phil..
--
View this message in context:
http://www.nabble.com/How-should-one-structure-multi-project-builds--tp17178473p17209593.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
