You mention that your company works through a large number of highly fragmented teams. Also, I'm sure that the codebase overall consists of many reusable libraries (proprietary). So, the question I have for you is:
Is your company's inter-team communications so good that you can checkout the sources for each dependency project and build them from CVS without worrying about pinning a particular dependency down to a version so you don't have to develop against a backdrop of moving targets? What I mean is, when you compile, are you retrieving a particular SCM tagged version for the dependency projects, or simply pulling HEAD? This matters, because if you're developing against the HEADs of all of your dependency projects, that has to be hell, and it effectively unites all of the projects into one release cycle. If you're pulling based on some SCM tag (ex. PROJ_2_0_1), then you're essentially doing what maven does, except that as soon as you put the artifact into your WEB-INF/lib, you lose the version information for your dependencies. Using the repository gives you an easy way to pin down your dependencies and not have to constantly rebuild them. It can therefore: (a) stabilize your development effort in fragmented environments if you're developing against one large roiling pool of HEADs, and (b) lower the cost of a given build by using prefab jars for a given set of dependency/version combinations. I understand your worries about the one-tool vs. two-tool issue; we're experiencing some of that here as well. And believe me, I know what corporate inertia can be like. I'm not sure how best to address that particular issue (the inertia), but I can say with confidence that once you've changed over from ant to maven throughout the company's codebase, you'll likely be very glad you did. You get to automatically take advantage of these structures with any new maven plugins, etc. One thing that has made our internal repo very useful where I work is the ability to build on the maven process and do things like assemble binaries (.tgz, .zip) which are custom-built, coherent applications that are tailored for deployment to a particular environment. Since the application itself is often a conglomerate of many libraries, this process simply involves assembling an archive of all the libraries, plus the glue that makes the application coherent (jsps, configs, etc.), and applying a set of environment properties to this bundle. This would take much longer and probably be much more complex were I to attempt building each artifact from SCM. I don't have to, because I already have most of my dependencies in the repo (from previous testing iterations, etc.). Just food for thought. Also, I want to throw in a little plug for the future. While it's a long way from being ready, and many will likely criticize me for even mentioning it, maven2 (next-gen maven) will accommodate the idea of a cascading source-build system sort of like what I think you're describing below. It's kind of like a ports tree (if you're familiar with BSD), except much more dynamic. I only mention this so you know that many of us are already thinking about that sort of requirement. Anyway, I know that maven isn't the right answer for everyone. It takes a certain mindset (corporate as well as individual) to use it. It breaks many of the traditional codebase management practices. Most importantly, it, like Ant or anything, is hard to adopt with a large set of projects. You have entrenched practices, and attitudes associated with these practices. But it's important to recognize that _any_ change you make in codebase management will require the same level of effort. My advice is to let maven adoption be viral; let users see the advantages for themselves. Maven seems to be pretty good at spreading in this way, since the alternative (*cough*Ant) requires a _lot_ of effort to do what maven provides in a nearly effortless fashion. So, start small, and emphasize the Right Way(tm) on a small scale. This will get you a lot, strictly on reporting, etc. convenience. (Show them the jcoverage, junit, and checkstyle reports to get them going ;). Good luck. HTH -john On Mon, 2004-06-14 at 11:17, Bielby, Randy J wrote: > 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]
