First let me say that I really appreciate the responses I have recieved on this issue. They have been very helpful in at least giving me a start as to how to resolve this challange. I have been on other list servs of this type where responses are critical, arrogant and basically useless. Not the case here... many thanks.
As far as John's response, I can see the need for this structure and methodolgy. But I struggle with this for a couple of reasons. 1 - My development staff is used to keeping their workspace in sync with CVS and doing so thru the WSAD interface (ie Eclipse CVS perspective). I'm not that concerned with "bloating" out the CVS respository. Those jars in the WEB-INF/lib typically do not change that often, if ever. But they are duplicated on other projects, which I have no control over. So, if I were to switch to the Maven approach, as right as it might seem, I would then have to require developers to use two tools, CVS and Maven, to keep their workspaces current. I guess you could argue that I could eliminate the direct access of CVS and do that via Maven, but I'm not sure I want to go that route. I'm in a large IT shop and swimming upstream like this is not something I enjoy. Due to the internal corporate economy and corporate politics, our development structure is very fragmented into smaller development teams all working on the same code base. The current build mechanism for developers is WSAD and CVS, introducing Maven may be more then I want to bite off. And in reality more then the staff here could handle I'm not saying I don't agree with John, as I do. It's just that the reality in large corporate environments like mine, sometimes do not lend themselves to change. I am also swimming upstream with standards that are being mandated outside of my area that do not fit with a tool like Maven. In fact I'm struggling to keep Ant and CVS as my build tools. 2 - While the idea of the Maven repository is nice, does it really make sense in the context of corporate development? There are many pieces of an application that get assembled to create the end result, the artifact if you will. By introducing the Maven repo, we have now introduced an additional repository as input for the build and development process. I would rather have a single source for all of the components of my artifact. In this case CVS. While I think that the repo works very well for some fo the open source projects etc, I think it introduces an additional point of potential inconsitencies, at least in my environment. If the repo had an interface to CVS it then might become more "sellable" in a corporate environment. That way all components of an application are contained with a single source control mechanism. And if I could convince others outside of my immidiate team of the need for a centralize repository for components/jars, this might be an interesting endeavor. Don't get me wrong, I do agree with most of what Maven is about. I am just having to pick and choose my battles based upon corporate culture and desicions that are being made outside of my control. I'd be interested in hearing how others are maintaining an updated workspace for developers while the build process is utilizing Maven. Randy Bielby x32258 -----Original Message----- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, June 11, 2004 8:58 PM To: Maven Users List Subject: Re: Jar help 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
