On Feb 26, 2009, at 5:52 PM, Galder Zamarreno wrote:
Hans Dockter wrote:
On Feb 24, 2009, at 10:05 PM, Galder Zamarreno wrote:
Hi Hans,
First of all, thanks very much for your help with this.
Hans Dockter wrote:
On Feb 17, 2009, at 8:24 PM, Galder Zamarreno wrote:
Hi,
Hello to every Gradle user. This is my first ever post to this
list. I
have a question:
Even though Eclipse classpath sourcepath attribute generation
has not
been implemented yet, I wondered whether it's possible to
download the
corresponding "*-sources.jar" from a maven repository using
gradle. I
suppose this is something that Gradle should optionally request
via
Ivy but looking at the code, I couldn't figure out how to do
this and
couldn't find an example in the user list either.
Using a classifier should work:
For example:
"junit:junit:4.4:sources"
I'm a bit confused here. If I do the following:
compile "junit:junit:4.4"
The JUnit test classes are added compiled fine.
If I use compile "junit:junit:4.4:sources", gradle adds the
sources to the classpath but not the actual compiled jar, hence
compilation fails.
If I add:
compile "junit:junit:4.4"
compile "junit:junit:4.4:sources"
It only uses sources for compilation and it fails :(
Am I missing something obvious? I want compilation to work and
download the sources at the same time.
It is possible.
There is the following logic behind your problems above. In Gradle
(and Ivy) a dependency is defined by its group, name and version.
You can't assign multiple dependencies which have similar values
for those properties (actually you can, but then only on gets
resolved).
We distinguish between module and artifacts. A module can have
multiple artifacts. If you don't specify an artifacts, Gradle
assumes that the artifacts is of type jar and has the same name as
the module.
So compile "junit:junit:4.4" declares a module "junit:junit:4.4".
As you don't have specified any artifacts, we assume this module
has one artifact, that is junit-4.4.jar. If you declare
"junit:junit:4.4:sources", Gradle creates a module and under the
hood adds an artifact junit-4.4-sources.jar. Adding and artifacts
deactivates the implicit default artifact. But you can add more
than one artifact:
compile "junit:junit:4.4:sources" {
addArtifact(new Artifact('junit','jar','jar', null, null))
}
This should do the job. I had no time to try this out myself
though. Two things strike me as an improvement. Our DSL should
provide a notation for creating artifacts instead of using 'new
Artifact()'. And we should not rely on the implicit artifact, but
should always add the artifact explicitly. Right now this should
not work (it should only download the sources):
compile "junit:junit:4.4" {
addArtifact(new Artifact('junit','jar','jar', 'sources', null))
}
I'll give a shot to your recommendation but in general, it looks a
bit too cumbersome to do a simple thing: download all source jars
for my dependencies if available. A simple flag would be more useful
in general rather than specifying per jar. Thoughts? The convention
would be to download *-sources.jar.
Then, if you had that and did "gradle eclipse", the eclipse part
would pick up and add source paths to project files.
Oh yes, I have forgotten to add, that we definitely need special
support for downloading sources and javadocs (there is a Jira for
this). May be via setting a flag or even as default. When I was
answering to your email I was solely occupied with the general use
case of having more than one artifact for a module.
- Hans
- Hans
- Hans
Thanks very much in advance.
Regards,
--
Galder Zamarreño
http://galder.zamarreno.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
--
Galder Zamarreño
http://galder.zamarreno.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
--
Galder Zamarreño
http://galder.zamarreno.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
