First of all, sorry for the long email. The "right" way according to maven is probably going to seem tedious at first from your point of view, but in the long run will probably save you hours of headache:
I understand your desire to use WEB-INF/lib for the source of your dependencies. However, I have a question about this. When in a development scenario, are you versioning your dependencies right along with everything else, such that WEB-INF/lib winds up in version control too? If so, why? The way I see it, there are two ways you can go on this. First, you can choose to stick to the methodology you're using below, and probably use something other than maven (JAM or ant might be a good choice). Second, you can change your projects to _build_ the WEB-INF/lib from the project.xml's set of dependencies, and manage a corporate repository for proprietary artifacts. The second method is strongly preferred in the maven world, and I'd like to take a second and try to convince you why it's a good thing. The name of the jar file is irrelevant to this choice, and I will explain this later. If you have multiple projects, you're probably reusing many of the dependencies in WEB-INF/lib (you even state that you have some dependencies in the EAR, and probably referenced in the application.xml or manifest.mf or somesuch). If any of these dependencies is proprietary, this means that you have to update all the jars in all the WEB-INF/lib-like locations in all projects in order to incorporate new versions. It also means that your version control system is experiencing bloat for storing the same file in different locations. Finally, since the jar is a derivative of the source code, any proprietary jars are essentially re-versioning a derivative of code you can already recover via the sources (which are in version control themselves). From a version control / codebase maintenance perspective, it's much easier to centralize your storage of project artifacts (jars) and select from these in order to make other artifacts (more jars, or wars, or ears, or whatever). Additionally, if you chose to publish a full description of your project, including things like static code check results, and maybe something like a dependency list, how would you produce this? This is where the project.xml really becomes a powerful item. If you have the name and version of a dependency, you can give a full description of exactly what files are needed to run your code. For the sake of clarity and recoverability, this can be invaluable. When you place the project.xml under version control, you can now track these dependencies (including version numbers, which I'm betting you can't recite to me about the current version of your project). In the event you have to recover to some previous incarnation of a project, you'll know exactly which versions of which dependencies to look for. As for the jar file names, you can simply use the <jar>jarname.jar</jar> element within a <dependency/> specification. This will allow you to have the following: <dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> <version>2.0</version> <jar>commons-lang.jar</jar> </dependency> and have maven look for <repo>/commons-lang/jars/commons-lang.jar instead of <repo>/commons-lang/jars/commons-lang-2.0.jar. This is a pathetically incomplete reasoning for why you should use the maven approach, and I'm sure you'll get some more detail from others on the list, but I wanted to provide at least one voice of reason on this topic. Maven is hard to get at first, but once you do it will change the way you think about producing software. It may seem strange to do things in the recommended way, but in the end it will save you time and effort, and make your codebase much more usable both for producing software and for reporting on progress, etc. Hope it helps, -john On Fri, 2004-06-11 at 14:32, Bielby, Randy J wrote: > Hello, > > First, I'm a newbie and just getting started. I'm trying to proof out > an existing build that is currently using Ant, while also making a > determination of Maven is a good choice for new projects. > > I have a situation that I don't believe is unique but I can't seem to > find all the info I'm looking for. I have several projects with a > number of dependent jars. The development team is anywhere from 10-30 > developers depending upon the project. We are using WSAD and have as > one of the projects in our workspace a webapp. This webapp contains all > the dependent jars within the WEB-INF/lib folder. All the other project > within the workspace are included as dependent jars in the EAR. I would > prefer that the compile uses the jars in the lib folder. This is the > ensure that the deployed runtime code is the same as what the developers > have developed against. I know this goes against Maven's perferred > method of retrieving dependencies for the repository. I know that I can > override this behavior, but I'm struggling with how to go about it. > > I guess I could override the local repository to be the WEB-INF/lib, but > I'm not sure that will work due to the expected folder structure of the > repo. I could also just not use the dependencies and add the jar to the > classpath. > > Also, due to corporate defined standards, my jar names cannot contain > the version number (don't ask). So I also need my jar dependencies to > be something like, log4j.jar instead of log4j-1.2.6.jar. I have tried > eliminating the version from the dependency but I get, log4j-.jar > instead. > > Randy Bielby > -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
