> Rather than using the version numbered jar, can you deploy an > unversioned one instead?
Very likely, but then (if I understand correctly) wouldn't I lose the ability to grab the JAR from a repository? Most of what I've seen up till now has involved using the repository for "plain vanilla" JARs. I'm trying to figure out if the repository can be adapted for J2EE packages. I'd love to be able to say that MyEJB-A.jar has a dependency on MyEJB-B.jar, version 1.0.1. The build system should then be able to retrieve MyEJB-B-ejb-client-1.0.1.jar from the repository and include it in the classpath when building MyEJB-A.jar. There are things to consider, like making sure the correct entry for MyEJB-B-ejb-client-1.0.1.jar ends up in the manifest's Class-Path entry for MyEJB-A.jar. Another issue is whether it would be possible to leverage the repository for pulling external JARs into an EAR - for example, a reusable component (ie, one not tied to that EAR specifically) that must be called via local interfaces for performance reasons (hence ejb-client-jar isn't an option). Then of course, the application.xml would have to be generated from the POM to ensure the correct JAR file names are included. Fortunately all of the above can be scripted via various Ant tasks. I think a lot of these intricacies could be avoided if Maven offered an extensible mechanism (for example, an abstract VersionExtractor, a la Ruper) for extracting version info--from the file name, from a directory name, from the manifest file, etc. And it may, or it may only be a few patches away from being able to handle something like that, or my idea may be rejected all together :-) Regardless, I've gotten some good ideas on how to handle versioned JAR file names in J2EE out of this discussion - thanks! Kyle _____ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
