2009/2/23 Jon Georg Berentsen <jon.georg.berent...@objectware.no>

>
> "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."
>
> Same setup as the project I been mavenizing for the last few weeks.
> The first thing you want to do is set up a local company Nexus and
> release all those proprietary jars.
>
> "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 some annoying manual post-export tasks that must be
>
> run."
>
> Should not be a problem.
> Plenty of plugins for any given container.
> Whould recommend jetty, if you have no servers lockins.
>
> "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."
>
> Same as we had. Expect to use some time trimming the pom's.
>
>
> "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."
>
> Every brown field mavneization is different.
> My strategi was:
> 1.Depending on the setting and controll over the source, consider using
> subversion externals in a POC.
>

Why not just do it on a branch.... it'll make merging the changes back
easier.  Doing it via externals will actually make your life harder IMHO


>
> 2. Setup and/or release 3 party jars in the company repo.
>

+1000


>
> 3.Put it all in one project and make it compile.
>

I'm less keen on this option. I would take each artifact one step at a time,
the Big Feck Off Project (BFOP) technique tends to lead to bad pom design...

easier to refactor jars as jars, wars as wars, and if you want at the end
string them all together with an aggregator pom... but getting your release
process working with the release plugin will require much more effort on a
brown-field project if you go BFOP than if you go lots of small projects and
an aggregator if you need to join them together.


>
> 4. Get in running on the container of your choise, using a maven plugin.
>
> 5. Import all tests and make'em run green (might have to be done
> earlyer, dep on your project)
>
> 6. Divide the project into multimodule projects. Recommend Domain Driven
> Design :)
>
> And yes it can take some time. Took me 3 weeks, doing a enterprise 250++
> external jars,
> 3 years of code, lockins to container, bad tests next to production
> code.
>
> "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. Again consider using Subversion externals in a poc first.
>
> "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."
>
> With a good repo you'll have both :)
>
> "Thanks.
>
> Steve Cohen"
>
> No p'!
> Good luck!
>
> ---------------------------------------------------------------------
> 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
>
>

Reply via email to