Thanks Todd.
But note, I don't have any Ant stuff to convert. I'm starting from a
more rudimentary base - Eclipse Export has been my "build system". In
some ways this makes things easier. I hope so, anyway.
Todd Thiessen wrote:
Wow. There are 101 ways (perhaps 100001) to do what you want. No one
specific way is best and there is no "wizard" that automatically
converts an ant build.xml into a Maven project. I can share some of the
things that I found important to learn during my transition to Maven.
1. Become familiar with Maven's philosophy:
http://maven.apache.org/background/philosophy-of-maven.html
Been there. Wouldn't be here if not.
2. Get to know your settings.xml file and what it is for. I found it
somewhat confusing to understand at first. Understand the difference
between the global and local settings.xml file.
good point, I will.
3. Understand that the m2e plugin still has some bugs. Particularly if
you use the Embedded installation. It is a GREAT tool still to use even
when considering these bugs but you will still want to have the command
line available. One thing that helps with m2e is pointing to a local
install instead of the Embedded install.
Will have to learn what you're talking about here.
4. Understand how multi-module projects are structured and how they
work. I made a dummy project for this before I even considered porting
over the actual production code.
Yup, this is where I want to wind up. I am supposing that the right
thing is to get the individual projects buildable this way, then build a
multi-module architecture around it. If that is wrong, please let me
know now before I get too far into this.
5. Understand what a SNAPSHOT version is and how this is different from
a regular released version. I found this confusing at first.
Will do.
6. Get to know the release plugin; its benefits and its limitations.
ditto
7. Understand the build lifecycle and how to bind goals to phases.
ditto
8. Understand that Maven encourges, as a rule of thumb, one built
artifact per project. This could be a challenge when moving from ant if
your ant build builds many artifacts. I found that when we moved to
Maven, we had a larger number of projects than with ant but this in the
end was a very good thing.
This mirrors present structure, except for one manual step where I
exported (Eclipse Export) a bunch of projects to a jar, then manually
zipped it up with its dependencies. This is the hump I want Maven to get
me over.
9. Using a repo manager has proved to be extremely useful. Builds are
faster and it provides a great way to share artifacts with your team.
See previous thread. Ain't gonna happen unless I get team using with
individual repos first.
10. Understand what aggregation means and that Maven does not yet
support aggregation well. Some things that you had available in ant,
like an aggregated checkstyle report, are not yet available in Maven.
Checkstyle? Oh Lord. Can't miss what you never had.
And above all, enjoy ;-).
Yup.
---
Todd Thiessen
-----Original Message-----
From: Steve Cohen [mailto:[email protected]]
Sent: Tuesday, February 24, 2009 8:34 AM
To: Maven Users List
Subject: Re: Mavenizing Existing Project Part Deux
OK. Since we're skipping the ant phase on this project, never
having used it here, I'll go with your suggestions in #2.
I'll start by making a branch, using the least dependent
project (which depends on no others) for my first guinea pig.
(I DO follow the trunk-branch-tag pattern).
However, one question remains - in my present mode I always
check everything into SVN, including all those .* files
(.project etc.) which, by default, eclipse filters out. I do
that to make checkout easier for the next guy, no
configuration, etc. But it creates a problem here - it means
that the "nature" of the project is predetermined at the time
of the checkout. That's what I wanted, but I don't want it
here. So I suppose the plan would be:
1. make a tag of current state and cut a branch at the same point.
2. delete from the branch all the .* files that determine
configuration, IN THE REPOSITORY, not on a local copy, where
Eclipse would immediately recreate these files.
3. delete the local copy of the project.
4. check it out again from the repository as a new project
and specify maven in the wizards?
I assume this is possible. Is it what you had in mind? Or is
there a better way.
Steve
Jon Georg Berentsen wrote:
Hey! Great!
Since mavnen config is pretty new to you, this is a great
way to learn.
1) Is there some way to "change natures"?
No.
With Ant and scripts you can get a very specific build process,
usually with som quircks and/or workarounds.
I find using the Ant scripts and other scripts as inspiration and
documentation for building up the pom, the best way to use them.
But there are a bunch of tricks and tips in doing so.
I think we went thru a few previously in this tread.
2) Create a new Maven project, place in SVN, then move stuff to the
right places?
I always presume people have a branch, a tag and a trunk
folder, but
if not have a look at some apache project and see how it's done.
I usually do a poc in a branch to see if it all works out.
(A copy or externals of the working trunk) You do not want
to mess up
your code, fail, get a new order for business/management, and
desperatly revert trunk.
You also want to tag a stable last version of your Ant
built project.
-
---------------------------------------------------------------------
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]
