On 11/05/10 2:08 PM, Kurt Harriger wrote:
I have been trying to parse the docs around artifact configuration and
got hung up on the following.
artifacts {
archives myJar
}
Cause: No signature of method:
org.gradle.api.internal.artifacts.dsl.DefaultArtifactHandler.archives() is
applicable for argument types: ...
We could definitely to better with the error reporting here.
I'm not using the java plugin and I didn't realize "archives" was the
name of a configuration and was pulling my hair out before I realized
archives was actually the name of a configuration not a property or
method of artifacts. So adding
configurations {
archives
}
fixed the error.
To further confuse the issue I was trying to upload dlls rather than
jar files so I thought I might be able to do
artifacts {
file 'bin\log4net.dll'
artifact name: 'log4net.dll'
}
and other stuff like that.
You should be able to do things like this. Right now, the publishing DSL
is probably the least useful piece of Gradle's dependency management.
After the 0.9 release, we plan on revisiting the whole dependency
management DSL, and a major goal of that is to make publishing easier
and more flexible. Exactly how things will look is still up for discussion.
The error makes sense in hindsight I guess. But this also raises a
few other interesting questions.
Is possible to attach non-archive artifacts?
Yes. There's a mailing list discussion about how to do this here:
http://markmail.org/message/niseybxbjynckr2c
How are gradle configurations mapped to ivy configurations?
1:1 mapping.
can gradle support extra properties?
http://ant.apache.org/ivy/history/trunk/concept.html#extra
Not yet, but it should. Could you add a JIRA issue for this?
I was thinking it might be less confusing if artifacts were actually
specified in the configuration's configuration rather than in a
separate section. And perhaps archive would mean read artifact info
from the archive task and artifact might mean a here is the ivy info
find file via publish pattern as ivy does (although I don't really
like how Ivy does this either and found ivy publications -> file
location a bit confusing also). Something like the following perhaps:
configuration {
archives {
artifacts {
archive myJar
artifact name: 'blah', culture: 'en-US'
}
}
}
This is a good idea, and similar to what we've been talking about doing.
Personally, I'd like to split Configuration up, so that we separate the
incoming dependencies from the outgoing artifacts. The configurations {
} section would go away, as would the concept of a Configuation. The
incoming bits of Configuration would move to the dependencies { }
section to live with the dependency declarations, and the outgoing bits
of Configuration would move to the artifacts { } section to live with
the artifact declarations.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
