2009/3/17 <[email protected]>
> My bad, actually both executables have the same behaviour.
> Problem is a bit different. The client module is defined for one
> sub-project. So another sub-project depending on the first one will need
> transitivly the client module for runtime. That's where I get the ERROR. I
> still don't know if it's normal behaviour or not, but I would say no (being
> a basic and dumb user). Client module from a required project should be
> transparent for the requiring project.
>
I've tested this and I think I can reproduce the behaviour you are
describing, e.g:
in the dependency block of moduleA:
...
clientModule(['compile'], "dom4j:dom4j:1.6.1") {
dependency("jaxen:jaxen:1...@jar")
}
...
and webModuleB depends on moduleA, the jaxen dependency is not 'inherited'
by webModuleB.
Please confirm this situation, and if correct could you create a JIRA for
this.
>
> To prevent any mistake, I added the client module to the root script,
> waiting for a better solution.
>
> Hopefully my mistake will prevent other people to have the same problem...
>
Thx,
Tom
>
> ------------------------------
> *From:* [email protected] [mailto:
> [email protected]]
> *Sent:* Tuesday, March 17, 2009 10:06 AM
> *To:* [email protected]
> *Subject:* [gradle-user] Differences between Wrapper and normal bin
>
> Hi all,
>
> I've noticed a difference between the usage of the gradle wrapper and
> normal Gradle bin. I dont know if it's a bug or something else but there is
> something about the dependency download.
>
> With gradlew (any task):
> ERRORS
> sanco repo: bad org.gradle.clientModule found in *
> http://s-sanco-trc-tst.sanco.cec.eu.int/maven_repository/eu/sanco/gras/gras/1_14_1/gras-1_14_1.pom
> *<http://s-sanco-trc-tst.sanco.cec.eu.int/maven_repository/eu/sanco/gras/gras/1_14_1/gras-1_14_1.pom>:
> expected='eu.sa
>
> nco.gras:gras:1_14_1' found='null'
>
> And when I run compile with the gradle bin, no problem, jar is downloaded.
>
> Is it a known bug?
>
> Thanks in advance
>
>
