Hi Steve, I use Maven for building my projects and the eclipse WTP plugin as well. JSP re-compilation while running and hot swap code replacement while debugging has always worked for me.
On Sun, Feb 22, 2009 at 5:21 PM, Steve Cohen <sco...@javactivity.org> wrote: > Thanks Stephen: > > I figured there would always be one manual deployment step but I would like > to at least get rid of the post-eclipse export, pre-deploy manual steps. > > I have one more question I meant to ask earlier but forgot. > > I do make use of the Eclipse WTP environment and a local Tomcat server and > immediate compilation to create a rapid-turnaround development environment > apart from the server. This dovetails pretty nicely with the regular > Eclipse export. Is it possible to still do this when Maven is running the > show? > > > > Stephen Connolly wrote: > >> 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 >>> >>> >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
