Hm. Google it.. But, here y' go! POC - http://en.wikipedia.org/wiki/Proof_of_concept Subversion externals - http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
-----Original Message----- From: Steve Cohen [mailto:[email protected]] Sent: 23. februar 2009 14:22 To: Maven Users List Subject: Re: Mavenizing existing project Thanks, Jon and Stephen Can you please define some terms in what you wrote that are unfamiliar to me? "subversion externals" "POC" thanks. Steve Cohen Jon Georg Berentsen wrote: > -----Original Message----- > From: Stephen Connolly [mailto:[email protected]] > Sent: 23. februar 2009 10:21 > To: Maven Users List > Subject: Re: Mavenizing existing project > > 2009/2/23 Jon Georg Berentsen <[email protected]> > > >> "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" > > YES! Sorry! Branch out. Even if you use subversion externals. > Using svn externals depends on the setting. > In my case I was doing a maven POC and could'nt touch the trunk, but > needed the changes. > Branching depends on the changes you expect in the trunk. > In my case a big no, no since we where doing heavy refactoring at the > same time. > > > >> 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." > > Yes. Avoiding the BFOP is a good thing, but it depends how well you know > the code. > I would rather have a BFOP that runs in week one. After all that's what > I have now! > And then start to refactor nice and steady, dealing with the spagetti > code. > Nothing more frightening than not haveing a running project for weeks! > > > >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
