> Answers -----Original Message----- From: Steve Cohen [mailto:[email protected]] Sent: 23. februar 2009 16:09 To: Maven Users List Subject: Re: Mavenizing existing project
"Thanks. I now grok your meaning - use svn externals as a proof of concept (when I saw "POC" I imagined some variation on "POM") way station between what we are doing now and setting up a true maven repository. That may be the only way to do it in my situation. I am in the worst of both worlds, a small organization (with few resources) inside a mega-corporation (with large security bureaucracy to appease). Perhaps then use Maven as the build tool and skip the local repository for now? Is that what you are suggesting?" >POM, POC - I can see that one :) Maven is not a build tool. It's a collection of best practies from an entire worldwide community. The build tool is just a consequence of following best practies. It seems that you (like we had 3 years ago) need to sell this idea to your organization. And trust me, it's worth fighting for a company maven repo. Your salespitch is that this saves development time. If all fails you could (hurts to say it) build it with maven and drop it back in subversion. But if you can get subversion in there, you can get a repo. "I hadn't heard of subversion externals before. Could be what I'm looking for. BUT - if I'm understanding correctly, svn externals references Subversion repositories, not Maven repositories. Does this not require knowing the subversion repository location of every third party project you want to use? Or is there some central Subversion (not Maven) repository somewhere that contains these jars? Or can svn externals reference Maven repos?" >Svn externals is a way to hook in to code. That is: your own code. So no, there is no central Subversion repo. But subversion look at files, and you have a lot of jar files in your subversion repo. So yes, you can hook in to get those files. But that's what you want to get away from when using Maven. 3 party jars should be refed in dependecy management. Jon Jon Georg Berentsen wrote: > 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] > > > > --------------------------------------------------------------------- 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]
