As I begin, I've made a copy of the Chapter 3 code package for
proficio. I've started to slowly move my eclipse code into these
packages, but have some questions.
1) The group id is actually the base of all of the package names. Is
that right. So if I'm com.areteq, then my groupId should be com.areteq.
2) In one eclipse project(Foundation), I have several packages such
as com.areteq.foundation, com.areteq.foundation.impl, com.areteq.util,
etc.
I need to have my directory structure under java match that, I believe.
3) Now, in the poms, the foundation (mapping to proficio-api) all the
groupIds need to be changed to com.areteq. Correct?
4) For each of the poms, the same changes need to be made. Correct?
5) One other question. I want ALL compilations, reports, plugins
that require it to use java 1.5. Is there one place I can put this,
or do reports and builds
have to have their own?
Thanks,
On Feb 23, 2009, at 8:46 AM, 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]
