-----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]
