At first I had a similar reaction as you, then settled on Gradle's requirement
on filenames as a reasonable "code by convention" requirement, particularly
given the optimizations it allows.
For remote repositories, when searching out a JAR with a particular revision,
it would get very expensive to have to download and extract a JAR file just to
introspect its manifest. The alternative is to externalize that manifest, and
down this road you arrive back at ivy.xml and/or pom files. For local files
introspecting JARs isn't such a performance hit. Requiring version numbers in
the filenames allows Gradle (by default, because it all can be extended) to use
the same resolving mechanism for local and remote repositories.
- Tim
On Jan 11, 2010, at 4:47 PM, phil swenson wrote:
> Well, I do have the version information. It's in the manifest file:
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.5.3
> Created-By: 1.3.1_01 (Sun Microsystems Inc.)
> ---->Package: org.apache.commons.collections
> Extension-Name: commons-collections
> Specification-Version: 3.1
> Specification-Vendor: Apache Software Foundation
> Specification-Title: Commons Collections
> ---->Implementation-Version: 3.1
> Implementation-Vendor: Apache Software Foundation
> Implementation-Vendor-Id:
>
> Sounds like there is no existing way to get gradle to leverage it?
> Wouldn't the manifest be a better way to looking at version info than
> a file name anyway? people don't tend to mess with jar manifests, but
> change file names all the time.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
