You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steve Cohen <st...@comcast.net> on 2009/02/24 01:53:02 UTC
Mavenizing Existing Project Part Deux
OK, after extensive discussion in earlier thread about the best way to
go about Mavenizing Existing Project(s) in my, shall we say, unusual
environment (see that thread for details, don't want to recapitulate
them here) I have decided to try to move forward.
First I have to learn this tool. I have used maven before, but mainly
in the way of building from someone else's POM. Just type maven install
or some such and bingo, the world is built.
Now my goal is to have pre-existing non-Maven projects be mavenized. I
am prepared to "throw the first one away". I also want to take this
opportunity to start from a m2eclipse platform, so I have now installed
that, even to the point of installing Ganymede because I couldn't get it
to install in Europa. Although I know there is benefit to the command
line tools, I'd like to start from eclipse, understanding that I can
take the POM I produce and install it with command line tools.
So my first question is this:
How do I convert a non-Maven project into a Maven project?
1) Is there some way to "change natures"?
2) Create a new Maven project, place in SVN, then move stuff to the
right places?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by David Weintraub <qa...@gmail.com>.
Sorry to get late into this conversation, but I am wondering if there
might be a way to do a gentler migration path.
For example, let's say you modify the current directory structure
bit-by-bit into the standard Maven directory structure, then once you
have setup in a way Maven likes it, convert the build over to Maven.
Of course, the whole thing depends on how standard are your current
projects. Our main project is a mess of enterprise beans, various
frameworks, and an infrastructure that was hacked together into a
mish-mosh of one of the biggest messes you've ever seen. The software
was developed about a decade ago by a bunch of developers who worry
about such things as "planning" or "architecture". To move over to
Maven is almost impossible because it may require massive structural
changes in our project.
However, other projects we had were quite easy. They produced a
standard JAR file or WAR file and the whole process was pretty
straight forward. And, unlike the previous monstrous project I
described, these were actually buildable in Eclipse, so there may be
hope for you.
If I remember, you're talking about a rather small shop of three
developers and about 10 projects.
It may simply be a matter of moving your source to emulate Maven's
structure, then moving resources to where they're suppose to go. Once
that is done, you can generate a POM via the "mvn: archetype:generate"
and put it into your Eclipse project. Once you're able to get your
project to build with Maven, simply remove the jarfiles you have in
your revision control system.
This is a similar path we took with our smaller projects. We moved the
source files around while still doing our Ant builds, then created the
POM. Once we got things working, we simply moved Hudson from using Ant
to Maven, and removed the jarfiles from Subversion. Each project took
a couple of days. No branching or merging.
On Mon, Feb 23, 2009 at 7:53 PM, Steve Cohen <st...@comcast.net> wrote:
> OK, after extensive discussion in earlier thread about the best way to go
> about Mavenizing Existing Project(s) in my, shall we say, unusual
> environment (see that thread for details, don't want to recapitulate them
> here) I have decided to try to move forward.
>
> First I have to learn this tool. I have used maven before, but mainly in
> the way of building from someone else's POM. Just type maven install or
> some such and bingo, the world is built.
>
> Now my goal is to have pre-existing non-Maven projects be mavenized. I am
> prepared to "throw the first one away". I also want to take this
> opportunity to start from a m2eclipse platform, so I have now installed
> that, even to the point of installing Ganymede because I couldn't get it to
> install in Europa. Although I know there is benefit to the command line
> tools, I'd like to start from eclipse, understanding that I can take the POM
> I produce and install it with command line tools.
>
> So my first question is this:
>
> How do I convert a non-Maven project into a Maven project?
> 1) Is there some way to "change natures"?
> 2) Create a new Maven project, place in SVN, then move stuff to the right
> places?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Jason van Zyl <jv...@sonatype.com>.
On 24-Feb-09, at 8:12 AM, Jon Georg Berentsen wrote:
> Jason,
>
> This blogpost,
> http://tech.puredanger.com/2009/01/28/maven-adoption-curve/
> , sparked quite a debate in my company.
> We have been quite the early adopters with maven, and have seen the
> benefits etc. etc., but it seem like this "Ant/script to Maven, what
> do
> we get, we only got trouble" fight has to be fought all the time with
> clients and new co workers.
>
> In your experience who adopt and embrace maven?
People who try it and have something that works.
If it doesn't work for you then don't use it. I'm not very preachy
about Maven and I've never tried to convert people to use it. I don't
think that would generally work anyway. If Ant or scripting languages
work for you then use them.
>
> Is it always the "I have seen the need"-people?
> Or do you have to have a maven Maven guy preaching?
>
I don't think you'll get very far if the team doesn't buy into it. Any
organization who listens to one preachy guy and then adopts Maven is
not going to get very far.
> It seems, to me, that if none of the two is present, Maven is often
> considered a hassel and pain.
Often people don't read any documentation, think a build is just
something that requires no maintenance and is just going to work, or
are just completely accustom to Ant that anything different seems like
a hassle. We get lots of people telling us all the time that they
think Maven is great and works well for them.
>
>
> Often, if used, Maven also becomes a "specialist" skill.
> One or two persons know it, the rest just use it, and can't fix it if
> something is broken.
I honestly have not found that to be the case when developers are
prepared. If you took two people who don't know either Ant or Maven
you would probably have an equal amount of difficulty. You get used to
what you use. Project who think that they can get away without
investing something in the infrastructure and training about it are
going to have problems. Many people think build and release management
is just some appendage to their project. Your project is not going to
work if the infrastructure doesn't work.
>
> I have often heard that the reason for this is that Ant is very
> transparent in what it does. Maven is not.
I really don't think that's the case. I think people have just used
Ant for a long time and they are used to it.
>
> Does this raise the bar for adoption?
I don't think so. Traffic on Maven central has grown incredibly over
the last year (on the order of 200M hits/month) and it continues to
grow. So Maven is still being adopted all the time because the number
of unique IPs keeps growing. So empirically we're seeing an increase
in adoption as time passes.
>
> Project size/complexity and skills matter?
>
Nope. I know lots people who use Maven on small projects and we have
clients who build project that are 6M lines of code. Some are build
and release engineers, most of them are just developers.
> Jon
>
>
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@sonatype.com]
> Sent: 24. februar 2009 16:32
> To: Maven Users List
> Subject: Re: Mavenizing Existing Project Part Deux
>
> Do make your first Maven project a conversion. You will likely fail or
> be extremely unhappy. I have seen this a hundred times now and trying
> to wedge Maven into what you currently have is categorically not a
> good idea.
>
> Find a new, preferably small, project where you can try out Maven and
> understand fully what it does before you attempt to convert a project.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Three may keep a secret if two of them are dead.
-- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by Jon Georg Berentsen <Jo...@Objectware.no>.
Jason,
This blogpost,
http://tech.puredanger.com/2009/01/28/maven-adoption-curve/
, sparked quite a debate in my company.
We have been quite the early adopters with maven, and have seen the
benefits etc. etc., but it seem like this "Ant/script to Maven, what do
we get, we only got trouble" fight has to be fought all the time with
clients and new co workers.
In your experience who adopt and embrace maven?
Is it always the "I have seen the need"-people?
Or do you have to have a maven Maven guy preaching?
It seems, to me, that if none of the two is present, Maven is often
considered a hassel and pain.
Often, if used, Maven also becomes a "specialist" skill.
One or two persons know it, the rest just use it, and can't fix it if
something is broken.
I have often heard that the reason for this is that Ant is very
transparent in what it does. Maven is not.
Does this raise the bar for adoption?
Project size/complexity and skills matter?
Jon
-----Original Message-----
From: Jason van Zyl [mailto:jvanzyl@sonatype.com]
Sent: 24. februar 2009 16:32
To: Maven Users List
Subject: Re: Mavenizing Existing Project Part Deux
Do make your first Maven project a conversion. You will likely fail or
be extremely unhappy. I have seen this a hundred times now and trying
to wedge Maven into what you currently have is categorically not a
good idea.
Find a new, preferably small, project where you can try out Maven and
understand fully what it does before you attempt to convert a project.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Jason van Zyl <jv...@sonatype.com>.
On 24-Feb-09, at 8:12 AM, Steve Cohen wrote:
> Wow. That's different advice from what others are saying, BUT,
> you're the "maven" so I do appreciate your warning and take it
> seriously!
>
> Was there a missing "not" in your first sentence? It seems to make
> more sense that way.
>
Yes, a typo. Try a small Maven project first and learn what it does on
a small scale before attempting a large project. Maven is very
different then ad-hoc scripting and you'll get frustrated pretty fast.
There's usually a way in Maven to do everything you need. Also a good
idea to read:
http://www.sonatype.com/products/maven/documentation/book-defguide
> I am prepared to fail the first few times, start with the simplest
> projects, etc. I'm not a newbie, I have a lot of experience in
> reengineering builds and I don't imagine immediate success the first
> time around. Also, I'm a team of, for all practical purposes, one.
> There are no other users I can burn with my failed efforts. And I'm
> a bulldog when I want to be.
>
> It seems to me that my experiences, if carefully logged and
> ultimately successful, could be helpful to other potential users who
> might be in my position. Frankly, I think would be good for Maven to
> lower the bar to conversion. It seems higher to me than it ought to
> be.
>
You're talking about conversion from something usually arbitrary
relative to Maven. We do have some tools around to help with
conversions but it's primarily mapping out dependencies and creating
repositories that's enough to get people started.
> Steve
>
> Jason van Zyl wrote:
>> Do make your first Maven project a conversion. You will likely fail
>> or be extremely unhappy. I have seen this a hundred times now and
>> trying to wedge Maven into what you currently have is categorically
>> not a good idea.
>>
>> Find a new, preferably small, project where you can try out Maven
>> and understand fully what it does before you attempt to convert a
>> project.
>>
>> On 23-Feb-09, at 4:53 PM, Steve Cohen wrote:
>>
>>> OK, after extensive discussion in earlier thread about the best
>>> way to go about Mavenizing Existing Project(s) in my, shall we
>>> say, unusual environment (see that thread for details, don't want
>>> to recapitulate them here) I have decided to try to move forward.
>>>
>>> First I have to learn this tool. I have used maven before, but
>>> mainly in the way of building from someone else's POM. Just type
>>> maven install or some such and bingo, the world is built.
>>>
>>> Now my goal is to have pre-existing non-Maven projects be
>>> mavenized. I am prepared to "throw the first one away". I also
>>> want to take this opportunity to start from a m2eclipse platform,
>>> so I have now installed that, even to the point of installing
>>> Ganymede because I couldn't get it to install in Europa. Although
>>> I know there is benefit to the command line tools, I'd like to
>>> start from eclipse, understanding that I can take the POM I
>>> produce and install it with command line tools.
>>>
>>> So my first question is this:
>>>
>>> How do I convert a non-Maven project into a Maven project?
>>> 1) Is there some way to "change natures"?
>>> 2) Create a new Maven project, place in SVN, then move stuff to
>>> the right places?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>> We all have problems. How we deal with them is a measure of our
>> worth.
>>
>> -- Unknown
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
Wow. That's different advice from what others are saying, BUT, you're
the "maven" so I do appreciate your warning and take it seriously!
Was there a missing "not" in your first sentence? It seems to make more
sense that way.
I am prepared to fail the first few times, start with the simplest
projects, etc. I'm not a newbie, I have a lot of experience in
reengineering builds and I don't imagine immediate success the first
time around. Also, I'm a team of, for all practical purposes, one. There
are no other users I can burn with my failed efforts. And I'm a bulldog
when I want to be.
It seems to me that my experiences, if carefully logged and ultimately
successful, could be helpful to other potential users who might be in my
position. Frankly, I think would be good for Maven to lower the bar to
conversion. It seems higher to me than it ought to be.
Steve
Jason van Zyl wrote:
> Do make your first Maven project a conversion. You will likely fail or
> be extremely unhappy. I have seen this a hundred times now and trying
> to wedge Maven into what you currently have is categorically not a
> good idea.
>
> Find a new, preferably small, project where you can try out Maven and
> understand fully what it does before you attempt to convert a project.
>
> On 23-Feb-09, at 4:53 PM, Steve Cohen wrote:
>
>> OK, after extensive discussion in earlier thread about the best way
>> to go about Mavenizing Existing Project(s) in my, shall we say,
>> unusual environment (see that thread for details, don't want to
>> recapitulate them here) I have decided to try to move forward.
>>
>> First I have to learn this tool. I have used maven before, but mainly
>> in the way of building from someone else's POM. Just type maven
>> install or some such and bingo, the world is built.
>>
>> Now my goal is to have pre-existing non-Maven projects be mavenized.
>> I am prepared to "throw the first one away". I also want to take this
>> opportunity to start from a m2eclipse platform, so I have now
>> installed that, even to the point of installing Ganymede because I
>> couldn't get it to install in Europa. Although I know there is
>> benefit to the command line tools, I'd like to start from eclipse,
>> understanding that I can take the POM I produce and install it with
>> command line tools.
>>
>> So my first question is this:
>>
>> How do I convert a non-Maven project into a Maven project?
>> 1) Is there some way to "change natures"?
>> 2) Create a new Maven project, place in SVN, then move stuff to the
>> right places?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> We all have problems. How we deal with them is a measure of our worth.
>
> -- Unknown
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Jason van Zyl <jv...@sonatype.com>.
Do make your first Maven project a conversion. You will likely fail or
be extremely unhappy. I have seen this a hundred times now and trying
to wedge Maven into what you currently have is categorically not a
good idea.
Find a new, preferably small, project where you can try out Maven and
understand fully what it does before you attempt to convert a project.
On 23-Feb-09, at 4:53 PM, Steve Cohen wrote:
> OK, after extensive discussion in earlier thread about the best way
> to go about Mavenizing Existing Project(s) in my, shall we say,
> unusual environment (see that thread for details, don't want to
> recapitulate them here) I have decided to try to move forward.
>
> First I have to learn this tool. I have used maven before, but
> mainly in the way of building from someone else's POM. Just type
> maven install or some such and bingo, the world is built.
>
> Now my goal is to have pre-existing non-Maven projects be
> mavenized. I am prepared to "throw the first one away". I also
> want to take this opportunity to start from a m2eclipse platform, so
> I have now installed that, even to the point of installing Ganymede
> because I couldn't get it to install in Europa. Although I know
> there is benefit to the command line tools, I'd like to start from
> eclipse, understanding that I can take the POM I produce and install
> it with command line tools.
>
> So my first question is this:
>
> How do I convert a non-Maven project into a Maven project?
> 1) Is there some way to "change natures"?
> 2) Create a new Maven project, place in SVN, then move stuff to the
> right places?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by Jon Georg Berentsen <Jo...@Objectware.no>.
+1
-----Original Message-----
From: Todd Thiessen [mailto:thiessen@nortel.com]
Sent: 24. februar 2009 15:16
To: Maven Users List
Subject: RE: Mavenizing Existing Project Part Deux
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
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.
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.
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.
5. Understand what a SNAPSHOT version is and how this is different from
a regular released version. I found this confusing at first.
6. Get to know the release plugin; its benefits and its limitations.
7. Understand the build lifecycle and how to bind goals to phases.
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.
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.
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.
And above all, enjoy ;-).
---
Todd Thiessen
> -----Original Message-----
> From: Steve Cohen [mailto:scohen@javactivity.org]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Felipe Gaúcho <fg...@gmail.com>.
you need:
- a top folder (parent pom)
- sub-folders with the modules (each refering the top pom and the
other modules dependencies - if any)
then in the top folder you type:
mvn install eclipse:eclipse
it will do the job
On Tue, Feb 24, 2009 at 4:29 PM, Steve Cohen <sc...@javactivity.org> wrote:
> Todd Thiessen wrote:
>>>>
>>>> 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.
>>>
>>
>> If the project can be built individually, then yes that makes sense. But
>> if you have any depencencies between projects then of course the picture
>> is a bit more complex.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>
> Okay, so this is going to be the rub, it looks like. I have multiple
> projects and they DO depend on one another, but in a well defined fashion,
> not cyclically. I guess my question is, what, in Maven, takes the place of
> (or supplements) the Eclipse action of putting one project on the build path
> of another?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Please help to test this application:
http://fgaucho.dyndns.org:8080/cejug-classifieds-richfaces
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
Todd Thiessen wrote:
>>> 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.
>>
>
> If the project can be built individually, then yes that makes sense. But
> if you have any depencencies between projects then of course the picture
> is a bit more complex.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
Okay, so this is going to be the rub, it looks like. I have multiple
projects and they DO depend on one another, but in a well defined
fashion, not cyclically. I guess my question is, what, in Maven, takes
the place of (or supplements) the Eclipse action of putting one project
on the build path of another?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by Todd Thiessen <th...@nortel.com>.
> > 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.
If the project can be built individually, then yes that makes sense. But
if you have any depencencies between projects then of course the picture
is a bit more complex.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
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:scohen@javactivity.org]
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by Todd Thiessen <th...@nortel.com>.
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
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.
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.
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.
5. Understand what a SNAPSHOT version is and how this is different from
a regular released version. I found this confusing at first.
6. Get to know the release plugin; its benefits and its limitations.
7. Understand the build lifecycle and how to bind goals to phases.
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.
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.
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.
And above all, enjoy ;-).
---
Todd Thiessen
> -----Original Message-----
> From: Steve Cohen [mailto:scohen@javactivity.org]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
Hey, I know. "In the Beginning was the Command Line." I'm a believer.
BUT, if I can't make this look seamless in Eclipse, I'll never win.
Re pts 3 and 4 "delete the local copy of the project" meant "delete the
local copy of the project on the branch." I can always get back to what
I had from the trunk.
Mavenization comes in and after step 4.
Jon Georg Berentsen wrote:
> -----Original Message-----
> From: Steve Cohen [mailto:scohen@javactivity.org]
> Sent: 24. februar 2009 14:34
> 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.
>
>> Yes
>>
>
> 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.
>
>> Yes, and use svn ignore so they will not come back.
>>
>
> 3. delete the local copy of the project.
>
>> Well not yet. Mavenize the branch first and make sure it works.
>>
> Tha' POC. Then go to 3.
>
> 4. check it out again from the repository as a new project and specify
> maven in the wizards?
>
>> Haven't used m2eclipse, but I'll say yes :)
>> I would urge you to also learn to use maven with the commandline.
>>
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by Jon Georg Berentsen <Jo...@Objectware.no>.
-----Original Message-----
From: Steve Cohen [mailto:scohen@javactivity.org]
Sent: 24. februar 2009 14:34
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.
>Yes
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.
>Yes, and use svn ignore so they will not come back.
3. delete the local copy of the project.
>Well not yet. Mavenize the branch first and make sure it works.
Tha' POC. Then go to 3.
4. check it out again from the repository as a new project and specify
maven in the wizards?
>Haven't used m2eclipse, but I'll say yes :)
> I would urge you to also learn to use maven with the commandline.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by Jon Georg Berentsen <Jo...@Objectware.no>.
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.
-----Original Message-----
From: Steve Cohen [mailto:stevecoh1@comcast.net]
Sent: 24. februar 2009 01:53
To: Maven Users List
Subject: Mavenizing Existing Project Part Deux
OK, after extensive discussion in earlier thread about the best way to
go about Mavenizing Existing Project(s) in my, shall we say, unusual
environment (see that thread for details, don't want to recapitulate
them here) I have decided to try to move forward.
First I have to learn this tool. I have used maven before, but mainly
in the way of building from someone else's POM. Just type maven install
or some such and bingo, the world is built.
Now my goal is to have pre-existing non-Maven projects be mavenized. I
am prepared to "throw the first one away". I also want to take this
opportunity to start from a m2eclipse platform, so I have now installed
that, even to the point of installing Ganymede because I couldn't get it
to install in Europa. Although I know there is benefit to the command
line tools, I'd like to start from eclipse, understanding that I can
take the POM I produce and install it with command line tools.
So my first question is this:
How do I convert a non-Maven project into a Maven project?
1) Is there some way to "change natures"?
2) Create a new Maven project, place in SVN, then move stuff to the
right places?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Rusty Wright <ru...@gmail.com>.
Thanks, that's very good to know.
Brian E. Fox wrote:
>> The other thing is, and this may be an urban legend, that I think it's
> better to not have the >sub modules nested in the parent module's
> directory. Make them parallel; siblings. This means >using ../ with
> relativePath when referring to the parent's pom:
>
> This is due to the old eclipses not supporting nested modules. With M2e
> this is no longer a problem, so you should maintain a traditional tree
> structure instead.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>The other thing is, and this may be an urban legend, that I think it's
better to not have the >sub modules nested in the parent module's
directory. Make them parallel; siblings. This means >using ../ with
relativePath when referring to the parent's pom:
This is due to the old eclipses not supporting nested modules. With M2e
this is no longer a problem, so you should maintain a traditional tree
structure instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Dependency:copy and/or dependency:copy-dependencies
-----Original Message-----
From: Ketan Khairnar [mailto:ketan.khairnar@gmail.com]
Sent: Thursday, February 26, 2009 5:42 AM
To: Maven Users List
Subject: Re: Mavenizing Existing Project Part Deux
Based on this discussion, I have a question here regarding uncommon
requirement.
Once my build is finished I need to copy all the generated artifacts as well
as portal components and some shell scripts/batch files from resources.
Copying is done to custom directory which acts as TestBed of the
application. i.e. it can start jetty..with portal and all application jars.
I couldnt do that using maven-assembly plugin.
Only otions I had
1) jar with dependencies - doesnt work as I need it in directory format or
rather I can first gather all things and then build executable jar....but it
takes longer too considering frequent change install cycle
2) assembly descriptor --- How can I copy generated artifacts i.e. jars
modulesets? ..but then with unpack=false option it also copies all
dependencies too which I don't need
Can anybody suggest me better solution?
TIA
Ketan
On Thu, Feb 26, 2009 at 4:03 PM, Dominic Mitchell <do...@semantico.com> wrote:
> On 25 Feb 2009, at 14:40, Steve Cohen wrote:
>
>> I am thinking about this very carefully, and the option of not using Maven
>> at all is still in play. So is the option of using Maven ONLY to grab
>> third-party dependencies into a local repository.
>>
>
> I did this the other day, using the maven-ant-tasks to manage dependencies
> of an ant based project. I've written a POM and a minimal ant script, which
> collaborate to download all dependencies from our internal repo. It works
> like a charm, given that this project can't be converted to maven wholesale
> yet (it's cocoon 2.1, and would need to be migrated to 2.2).
>
> -Dom
>
>
Re: Mavenizing Existing Project Part Deux
Posted by Ketan Khairnar <ke...@gmail.com>.
Based on this discussion, I have a question here regarding uncommon
requirement.
Once my build is finished I need to copy all the generated artifacts as well
as portal components and some shell scripts/batch files from resources.
Copying is done to custom directory which acts as TestBed of the
application. i.e. it can start jetty..with portal and all application jars.
I couldnt do that using maven-assembly plugin.
Only otions I had
1) jar with dependencies - doesnt work as I need it in directory format or
rather I can first gather all things and then build executable jar....but it
takes longer too considering frequent change install cycle
2) assembly descriptor --- How can I copy generated artifacts i.e. jars
modulesets? ..but then with unpack=false option it also copies all
dependencies too which I don't need
Can anybody suggest me better solution?
TIA
Ketan
On Thu, Feb 26, 2009 at 4:03 PM, Dominic Mitchell <do...@semantico.com> wrote:
> On 25 Feb 2009, at 14:40, Steve Cohen wrote:
>
>> I am thinking about this very carefully, and the option of not using Maven
>> at all is still in play. So is the option of using Maven ONLY to grab
>> third-party dependencies into a local repository.
>>
>
> I did this the other day, using the maven-ant-tasks to manage dependencies
> of an ant based project. I've written a POM and a minimal ant script, which
> collaborate to download all dependencies from our internal repo. It works
> like a charm, given that this project can't be converted to maven wholesale
> yet (it's cocoon 2.1, and would need to be migrated to 2.2).
>
> -Dom
>
>
Re: Mavenizing Existing Project Part Deux
Posted by Dominic Mitchell <do...@semantico.com>.
On 25 Feb 2009, at 14:40, Steve Cohen wrote:
> I am thinking about this very carefully, and the option of not using
> Maven at all is still in play. So is the option of using Maven ONLY
> to grab third-party dependencies into a local repository.
I did this the other day, using the maven-ant-tasks to manage
dependencies of an ant based project. I've written a POM and a
minimal ant script, which collaborate to download all dependencies
from our internal repo. It works like a charm, given that this
project can't be converted to maven wholesale yet (it's cocoon 2.1,
and would need to be migrated to 2.2).
-Dom
Re: Mavenizing Existing Project Part Deux
Posted by Rusty Wright <ru...@gmail.com>.
Also remember that in eclipse you'll need to right click on the project and select Properties; there are some important maven things in there.
Steve Cohen wrote:
> Thanks, Rusty.
>
> I am thinking about this very carefully, and the option of not using
> Maven at all is still in play. So is the option of using Maven ONLY to
> grab third-party dependencies into a local repository. Another option
> is to use Eclipse's build functionality "headlessly", from the command
> line, without Maven. This capabilty exists in Eclipse, although it's
> not well publicized.
>
> A key goal of mine is to keep local developer builds in Eclipse working
> pretty much as they have. Directories may have to move to accomodate
> Maven standards, but I still want to be able to compile and run my
> Mavenized projects as well as pieces thereof inside Eclipse. In other
> words, the "Java Build Path", natures, etc. in Eclipse will still be
> operative and the capabilities of running java apps from the command
> line, and web apps through WTP will still exist. This is the reason for
> my perhaps misguided intention of working through m2eclipse.
>
> What's keeping me undecided is the lack of an assertion from anyone that
> when I am done, my Mavenized projects will be able to be used this way.
> Can someone tell me definitively that that's possible? If not, I may be
> wasting my time.
>> Once you have your project working from the command line, then commit
>> it to svn, then in eclipse check it out from svn as a maven project.
> Can you tell me what "checking out as a maven project" actually
> entails? I tried this on a non-maven project, thinking that it might
> generate all the maven framework for me, a skeleton POM or something,
> that I would have to complete. This did not work. It sounds like the
> right path is to command-line-mavenize, check-in, and then check out as
> a maven project. I guess I need to understand what a "Maven project" in
> Eclipse is. I suppose I should generate one from scratch and compare to
> an existing project.
>
>> I think eclipse doesn't like or support nested projects. If you use
>> the nested directories layout, when you import it into eclipse I think
>> the m2eclipse does some voodoo behind your back, rearranging things to
>> make eclipse happy. For me it was a bit more transparent having the
>> modules as parallel projects in eclipse.
>>
> I already work this way in Eclipse. No nested projects. So this
> shouldn't be a problem
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
Hmm, I don't usually click the build button. I typically live with
"build automatically" turned on. I live with the fact that this will
bomb out the WTP Tomcat if I'm not careful. But that's another can of
worms no? If we're not sure what build does, it's even scarier for
automatic build. Does anyone know? Or should I take this over to the
m2eclipse list?
Rusty Wright wrote:
> I'm pretty sure you'll be able to continue doing all of the usual
> eclipse stuff everyone is used to doing. I also use WTP and have a
> tomcat server running under/in eclipse that I fire up to test my jsps
> and whatnot.
>
> What bothers me about the m2eclipse plugin is that it's not obvious,
> to me at least, who's doing what and when. For example, you'll have
> maven menu items for doing the usual maven things; compile, package,
> test, etc. But what happens when I click on the eclipse build
> button? Is that doing a maven build or just an eclipse build?
> Likewise with a clean? I have my rituals when using the tomcat under
> eclipse; for example, I try to remember to always stop it before I
> click on the build button; at some time in the past it didn't always
> see the changes. And I'm not sure if doing a maven build in eclipse
> (from the maven menu) will update the files tomcat uses.
>
> So the reason I think it's better to start with the command line is so
> that you'll have a better understanding of what you're doing and why.
>
> Checking out a maven project into eclipse from svn simply means that
> the project was set up as a maven project before you committed to svn;
> it has a pom.xml, the correct directory structure, etc. If you want
> to start a mavenized eclipse project from scratch, use the archetype
> thing. That's quite nice for hitting the ground running.
>
>
> Steve Cohen wrote:
>> Thanks, Rusty.
>>
>> I am thinking about this very carefully, and the option of not using
>> Maven at all is still in play. So is the option of using Maven ONLY
>> to grab third-party dependencies into a local repository. Another
>> option is to use Eclipse's build functionality "headlessly", from the
>> command line, without Maven. This capabilty exists in Eclipse,
>> although it's not well publicized.
>>
>> A key goal of mine is to keep local developer builds in Eclipse
>> working pretty much as they have. Directories may have to move to
>> accomodate Maven standards, but I still want to be able to compile
>> and run my Mavenized projects as well as pieces thereof inside
>> Eclipse. In other words, the "Java Build Path", natures, etc. in
>> Eclipse will still be operative and the capabilities of running java
>> apps from the command line, and web apps through WTP will still
>> exist. This is the reason for my perhaps misguided intention of
>> working through m2eclipse.
>>
>> What's keeping me undecided is the lack of an assertion from anyone
>> that when I am done, my Mavenized projects will be able to be used
>> this way. Can someone tell me definitively that that's possible? If
>> not, I may be wasting my time.
>>> Once you have your project working from the command line, then
>>> commit it to svn, then in eclipse check it out from svn as a maven
>>> project.
>> Can you tell me what "checking out as a maven project" actually
>> entails? I tried this on a non-maven project, thinking that it might
>> generate all the maven framework for me, a skeleton POM or something,
>> that I would have to complete. This did not work. It sounds like
>> the right path is to command-line-mavenize, check-in, and then check
>> out as a maven project. I guess I need to understand what a "Maven
>> project" in Eclipse is. I suppose I should generate one from scratch
>> and compare to an existing project.
>>
>>> I think eclipse doesn't like or support nested projects. If you use
>>> the nested directories layout, when you import it into eclipse I
>>> think the m2eclipse does some voodoo behind your back, rearranging
>>> things to make eclipse happy. For me it was a bit more transparent
>>> having the modules as parallel projects in eclipse.
>>>
>> I already work this way in Eclipse. No nested projects. So this
>> shouldn't be a problem
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Rusty Wright <ru...@gmail.com>.
I'm pretty sure you'll be able to continue doing all of the usual eclipse stuff everyone is used to doing. I also use WTP and have a tomcat server running under/in eclipse that I fire up to test my jsps and whatnot.
What bothers me about the m2eclipse plugin is that it's not obvious, to me at least, who's doing what and when. For example, you'll have maven menu items for doing the usual maven things; compile, package, test, etc. But what happens when I click on the eclipse build button? Is that doing a maven build or just an eclipse build? Likewise with a clean? I have my rituals when using the tomcat under eclipse; for example, I try to remember to always stop it before I click on the build button; at some time in the past it didn't always see the changes. And I'm not sure if doing a maven build in eclipse (from the maven menu) will update the files tomcat uses.
So the reason I think it's better to start with the command line is so that you'll have a better understanding of what you're doing and why.
Checking out a maven project into eclipse from svn simply means that the project was set up as a maven project before you committed to svn; it has a pom.xml, the correct directory structure, etc. If you want to start a mavenized eclipse project from scratch, use the archetype thing. That's quite nice for hitting the ground running.
Steve Cohen wrote:
> Thanks, Rusty.
>
> I am thinking about this very carefully, and the option of not using
> Maven at all is still in play. So is the option of using Maven ONLY to
> grab third-party dependencies into a local repository. Another option
> is to use Eclipse's build functionality "headlessly", from the command
> line, without Maven. This capabilty exists in Eclipse, although it's
> not well publicized.
>
> A key goal of mine is to keep local developer builds in Eclipse working
> pretty much as they have. Directories may have to move to accomodate
> Maven standards, but I still want to be able to compile and run my
> Mavenized projects as well as pieces thereof inside Eclipse. In other
> words, the "Java Build Path", natures, etc. in Eclipse will still be
> operative and the capabilities of running java apps from the command
> line, and web apps through WTP will still exist. This is the reason for
> my perhaps misguided intention of working through m2eclipse.
>
> What's keeping me undecided is the lack of an assertion from anyone that
> when I am done, my Mavenized projects will be able to be used this way.
> Can someone tell me definitively that that's possible? If not, I may be
> wasting my time.
>> Once you have your project working from the command line, then commit
>> it to svn, then in eclipse check it out from svn as a maven project.
> Can you tell me what "checking out as a maven project" actually
> entails? I tried this on a non-maven project, thinking that it might
> generate all the maven framework for me, a skeleton POM or something,
> that I would have to complete. This did not work. It sounds like the
> right path is to command-line-mavenize, check-in, and then check out as
> a maven project. I guess I need to understand what a "Maven project" in
> Eclipse is. I suppose I should generate one from scratch and compare to
> an existing project.
>
>> I think eclipse doesn't like or support nested projects. If you use
>> the nested directories layout, when you import it into eclipse I think
>> the m2eclipse does some voodoo behind your back, rearranging things to
>> make eclipse happy. For me it was a bit more transparent having the
>> modules as parallel projects in eclipse.
>>
> I already work this way in Eclipse. No nested projects. So this
> shouldn't be a problem
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Steve Cohen <sc...@javactivity.org>.
Thanks, Rusty.
I am thinking about this very carefully, and the option of not using
Maven at all is still in play. So is the option of using Maven ONLY to
grab third-party dependencies into a local repository. Another option
is to use Eclipse's build functionality "headlessly", from the command
line, without Maven. This capabilty exists in Eclipse, although it's
not well publicized.
A key goal of mine is to keep local developer builds in Eclipse working
pretty much as they have. Directories may have to move to accomodate
Maven standards, but I still want to be able to compile and run my
Mavenized projects as well as pieces thereof inside Eclipse. In other
words, the "Java Build Path", natures, etc. in Eclipse will still be
operative and the capabilities of running java apps from the command
line, and web apps through WTP will still exist. This is the reason for
my perhaps misguided intention of working through m2eclipse.
What's keeping me undecided is the lack of an assertion from anyone that
when I am done, my Mavenized projects will be able to be used this way.
Can someone tell me definitively that that's possible? If not, I may be
wasting my time.
> Once you have your project working from the command line, then commit
> it to svn, then in eclipse check it out from svn as a maven project.
Can you tell me what "checking out as a maven project" actually
entails? I tried this on a non-maven project, thinking that it might
generate all the maven framework for me, a skeleton POM or something,
that I would have to complete. This did not work. It sounds like the
right path is to command-line-mavenize, check-in, and then check out as
a maven project. I guess I need to understand what a "Maven project" in
Eclipse is. I suppose I should generate one from scratch and compare to
an existing project.
> I think eclipse doesn't like or support nested projects. If you use
> the nested directories layout, when you import it into eclipse I think
> the m2eclipse does some voodoo behind your back, rearranging things to
> make eclipse happy. For me it was a bit more transparent having the
> modules as parallel projects in eclipse.
>
I already work this way in Eclipse. No nested projects. So this
shouldn't be a problem
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Posted by Rusty Wright <ru...@gmail.com>.
The one big concern I have is your plan of starting with eclipse and the m2eclipse plugin. It's not that I'm old school and prefer the command line but I find that the m2eclipse plugin does a lot of automagic stuff and you may not realize when things are changing under you because of what the plugin is doing.
Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project.
The other thing is, and this may be an urban legend, that I think it's better to not have the sub modules nested in the parent module's directory. Make them parallel; siblings. This means using ../ with relativePath when referring to the parent's pom:
<parent>
<artifactId>project_parent</artifactId>
<groupId>my.company.group.id</groupId>
<version>1.1-SNAPSHOT</version>
<relativePath>../project_parent/pom.xml</relativePath>
</parent>
<artifactId>project_module1</artifactId>
<packaging>jar</packaging>
etc.
I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse.
Steve Cohen wrote:
> OK, after extensive discussion in earlier thread about the best way to
> go about Mavenizing Existing Project(s) in my, shall we say, unusual
> environment (see that thread for details, don't want to recapitulate
> them here) I have decided to try to move forward.
>
> First I have to learn this tool. I have used maven before, but mainly
> in the way of building from someone else's POM. Just type maven install
> or some such and bingo, the world is built.
>
> Now my goal is to have pre-existing non-Maven projects be mavenized. I
> am prepared to "throw the first one away". I also want to take this
> opportunity to start from a m2eclipse platform, so I have now installed
> that, even to the point of installing Ganymede because I couldn't get it
> to install in Europa. Although I know there is benefit to the command
> line tools, I'd like to start from eclipse, understanding that I can
> take the POM I produce and install it with command line tools.
>
> So my first question is this:
>
> How do I convert a non-Maven project into a Maven project?
> 1) Is there some way to "change natures"?
> 2) Create a new Maven project, place in SVN, then move stuff to the
> right places?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org