> 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.
This is what I'm about to do. We are in the process of splitting a medium size project up into about 20 tiny projects (to give us some better resolution for releases). I'd hate to try and control the dependencies without Maven. To use the "store the jars in CVS" method, every developer of every project would have to know which projects use his jar. With the repository I only have to know the jars I use. > 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. You can use Maven from within Eclipse just as you use CVS from within it. > I'm in a large IT shop > and swimming upstream like this is not something I enjoy. I know the feeling. :-) > 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. All the teams work on one code base? > The current build mechanism for developers is > WSAD and CVS, introducing Maven may be more then I want to > bite off. That's your call. I started just using it to generate our web site. Now it generates all the official builds. Soon I'll figure out how to get it to do a release for me. Start small and work your way up. Until I get my developers used to using Maven our jar files are going to live in CVS just like yours. But that does limit how we can organize ourselves. > 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. What do they want to replace them with? > 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. I don't see that as a problem. The way our build system works, when someone checks code into CVS CruiseControl (via Maven) checks it out, build and tests it and then drops a jar in the repository. Everyone who needs that jar will get it from the repository. > 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. It does, the link is via the project that provides the jar. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
