Thanks for the responses Ron and everyone. I'm going to take back all of your input and try to apply it.
Josh On Sun, Jan 24, 2010 at 5:44 PM, Ron Wheeler <[email protected] > wrote: > I am still new to Maven after using it for 3 years with 20+ projects. > I recently installed the Nexus repository manager, community (free) > version. > It is a great help and I would heartily recommend installing it if you are > moving to Maven. > It makes the whole process much more visible. > > We use the Springsource version of Eclipse which supports Maven very well - > great POM editor. > > You can take my advice with a grain of salt. There are others with more > experience and understanding. > 1) I would set up projects for each of the jars that you need to make. > > 2) I would set up individual projects that create the POM files to describe > the overall dependencies. > These POMS can be used as dependencies in your applications to pick up the > right version of your jars. > I would also build POM projects for dependencies from third parties > We have POM files that have "compile" scope dependencies on all of the > shared jars that we get from third parties (Apache, javax, etc). These are > referenced by the POMs that produce war files, as "provided" so that the > jars are available for compiling but are not in the war files since we > install the jars in the container's (Tomcat) shared library folder. > We have several POMs describing families of 3rd party jars. One for > spring-hibernate-mysql-tomcat for our basic technology stack, one for > utilities, mostly Apache stuff and one for the Apace CXF Web Service > libraries for our projects that are Web Services. > > 3) Put the version numbers of the jars in the POM file of the dependent > POMs so that when you have a dependency on a pom-shared-utility pom you get > a full set of consistent jars for the version of your application. This > reduces the potential for errors by developers. Once you start on a new > version of your application and decide on a set of libraries that will be > used, you define the version in the appropriate POM and the developer only > have to set the dependency on the version of the group POM to get all the > right versions. > > 4) Use SNAPSOTS properly with your development process. Nexus helps with > this by enforcing disciplines. > > 5) Do not get discouraged by the terrible documentation. There is lots of > it but it is very much "inside the beltway". Accurate but too hard to > understand. The software works very well and there are a lot of tools to > make maven do whatever you need. > > 6) Ask here. The community is really helpful if occasionally too cryptic. > > Good luck, you have made a good decision to get properly structured using > maven > > Ron > > > Josh Stone wrote: > >> I'm in the process of moving our company over to Maven, and am not sure of >> the best way to organize our existing projects. Currently our application >> stack consists of two dozen projects with various dependencies on each >> other. For projects that a developer is actively working on, these should >> be >> built locally from source whereas dependencies on all other projects >> should >> be resolved from jars in the maven repository. I've setup 1 pom for each >> project, but there are a few things I'm not sure about: >> >> Since any given project could be built locally from source or from jars, >> do >> I need two poms for each project, one to serve as a "build" pom and one to >> reference jars? >> Should I store the pom(s) in SCM along with having them in the maven >> repository? >> >> Any tips are appreciated, >> Josh >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
