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]
