2009/2/22 Steve Cohen <sco...@javactivity.org> > I am considering"Mavenizing" a pre-existing project. > > This project consists of a Web Application (WAR file) and a server side JAR > module, built from several Eclipse projects, some of which are dependencies > of both modules, as well as many third party jars, both open source (many of > which themselves use Maven, of course) and proprietary. > > Current build process is very rudimentary. The Eclipse projects do not > currently use Maven naming standards for directories. To do builds, the > simple Eclipse Export menu options are currently used. Deployment is manual > and there are
FYI, maven's lifecycle says *nothing* about deploying post release. When maven talks about deploying, this is deploying the released artifacts to a Maven repository. There are maven plugins to deploy your war to tomcat, jetty, etc... but they are not part of the lifecycle... I think you will always end up with a manual deployment step (even if that is running a maven mojo in tomcat-maven-plugin, cargo-maven-plugin, jetty-maven-plugin, etc) And your customers will have the same... On the other hand, if deployment is for integration testing, then maven can do even better, with the ability to start and stop the app server before and after the integration tests (as part of the lifecycle). Some aspects of the maven support for this are poorer than they could be though. > some annoying manual post-export tasks that must be run. Version control > uses subversion, including a big ugly "project" containing static copies of > binary jars. These are my main reasons for considering conversion to Maven. > > Questions: > > 1. Are there articles around detailing "war stories" about making the kind > of move I am contemplating? I would like to read such before I get started. > I have just purchased Maven: The Definitive Guide, and while the > information there is very good, it tends to assume a start from scratch. I > would like to keep the history in the Subversion respository if possible. I have done several conversions, and providing you rename and move the files in subversion, you can keep your history without issue. > > > 2. Would I be better served by renaming directories at the start to Maven > "Convention over Configuration" standards or by overrriding the defaults all > the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I'd want to be on subversion 1.5.5 before trying that.... of course if you are using subversion 1.5.x and have repository access via http or https you will have a bit of fun when releasing using the release plugin. svn: does not have these issues. (A bug the mod_dav_svn prevents tagging from a working copy that is not based off of the head revision) > > > 3. Would I be better off building a local network repository containing > both the open source and proprietary code needed or would it be better to > create a local repository only for the proprietary stuff and get the open > source stuff from a remote repository. You would be best served using nexus to host your artifacts and cache all the remote ones. There are alternatives, but Nexus is, IMHO, the easiest to set up and get running, and also has the lowest cost of switching to the others (i.e. all the data is on the disk) (Note I have no affiliation with either Nexus or Sonatype ) > > > Thanks. > > Steve Cohen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
