Craig R. McClanahan wrote:
On Sat, 1 Mar 2003, Stefano Mazzocchi wrote:
[EMAIL PROTECTED] wrote:
Having a file encode <project>-<artifact>-<version>.type has been very useful for us.
Yes, it's often different from what the project creates and distributes,
but I (and others) have been bitten by
commons-logging.jar, struts.jar, junit.jar so many times, that seeing
log4j-1.2.5.jar is a godsend.
I totally share this experience and support the concept.
I've gotten bit by the opposite problem (changing version number in a JAR filename causing broken build scripts) just as often.
Wouldn't a reasonable approach to this problem be to make searches for
"commons-foo.jar" return the latest released version, while searches for
"commons-foo-x.y.jar" would return that particular version? Then, you can
have it either way. On the former, one might also support a mode that
grabs the latest nightly instead of the latest reslease.
Two problems here
* The uri to find a needed jar. * How to store the jar on the local filesystem
I think we should handle these cases
* uri to find
o Specific version
o latest released. (blank )
o latest nightly
* Jar name on local filesystem
o with complete version
o without version.Seems like a straight forward enough to handle all of these on the client or the server side.
R, Nick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
