You may need to read a little more in-depth on the maven purpose. The idea is that everything in your /lib directory will not actually be stored with your project, at least w.r.t. version management. Instead, these dependency libraries should be maintained in a central repository (or set of repositories...), where the owner of each project can post his/her artifacts (jars, etc.) for all to use. Then, when you use maven to build your project, it will pick up the information on each dependency (from the <dependencies/> element structure), download it, and add it to the build classpath. When you use maven to build a binary distribution, it will bundle these jars with the rest.
I really can't do justice to the elegance of this system, though. Reading the docs (don't forget the WIKI...it's pretty important, too) is really the only way to properly understand the goals of maven. It is not simply a drop-in replacement for Ant; it encapsulates and enforces a lot more of the best practices out there for maintaining working codebases. At first it may seem hard to get the hang of, but once you do you'll probably realize like most of the rest of us that this thing is pretty revolutionary... Cheers, john On Sun, 2004-01-25 at 23:02, David Whitehurst wrote: > I'm confused, what does my project depend on other than the JAR's that > are in my /lib folder, but that's on CVS too along with /src. Am I > supposed to be looking for the java sdk jar? I only depend on the /lib > jars and the /conf folder, but each are on CVS, where would I download > that from? I'm really confused now. > > > David > > John Casey wrote: > > ><snip> > > > > > >> <dependencies> > >>- > >> <dependency> > >><groupId/> > >><artifactId/> > >><version/> > >><url/> > >></dependency> > >></dependencies> > >> > >> > ></snip> > > > >This would do the trick...this is actually a section in which you're > >supposed to list the dependencies upon which your > >project...well...depends. As such, it should be a set of entries that > >look something like this: > > > ><dependency> > > <groupId>commons-jelly</groupId> > > <artifactId>common-jelly-tags-xml</artifactId> > > <version>20030211.142729</version> > ></dependency> > > > >or some such. The group id is a grouping mechanism, which helps to > >determine the directory structure on the remote repository where the > >dependency jar can be downloaded. The artifact id is the the name of the > >jar file itself, minus the version and the '.jar' suffix. The above > >specification would translate to the following download URL on the > >remote repository: > > > >http://the.remote.repository.url/base/path/commons-jelly/jars/commons-jelly-tags-xml-20030211.142729.jar > > > >Leaving any of the above element bodies empty will no doubt result in a > >NPE, since there is literally no value for something that expects one. > > > >Hope that helps. > > > >-john > > > > > >--------------------------------------------------------------------- > >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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
