I can live with it... but there are definite downsides. if you have a flat file directory and version control the files, you have to do remove/add for each version instead of just checking in new versions. and eclipse makes you add in the jar file again (although IntelliJ detects all jars in a dir)
I'm coming from ant land. what does maven do? On Mon, Jan 11, 2010 at 3:36 PM, Tim Taylor <[email protected]> wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
