I just introduced Maven on a major project which made use of pretty much the same strategy as the one you describe. I found that the various duplications of jar files in the CVS repository increasingly resulted in inconsistencies and confusion - the java version of DLL HELL - this is over with ONE repository for ALL jars with an explicit versioning scheme. Maven doesn't introduce an extra tool in my point of view - it replaces ant which the developers would otherwise have to invoke. With plugins (mevenide) to eclipse/WSAD the calling of goals can be accomplished pretty easily from within the ide. Specifying the dependencies as SNAPSHOT makes sure that the newest artefacts are always used. Web projects with Web-inf/lib folders all have an accompanying goal to create/recreate the lib based on the dependencies. Internal eclipse dependencies on jars and other projects are easily managed with the use of a MAVEN_REPO variable. Nightly builds keep a site up to date including information for new developers and how to get started and other resources.
I find Maven extremely valuable in a corporate environment as well :) Regards ____________________________ Jesper Linvald >-----Original Message----- >From: Bielby, Randy J [mailto:[EMAIL PROTECTED] >Sent: 14. juni 2004 17:17 >To: Maven Users List >Subject: RE: Jar help > >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] > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.693 / Virus Database: 454 - Release Date: 31-05-2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.693 / Virus Database: 454 - Release Date: 31-05-2004 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
