You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Colin Chalmers <co...@xs4all.nl> on 2005/08/24 18:18:25 UTC
Introducing Maven to developers
Hi all,
I'm trying to introduce Maven at the client I'm working at,
unfortunately I'm meeting some resistance.
They currently work with a number of ant scripts which pulls data in
from all over the place, I want to change that but some find it hard to
see the added value of Maven.
The main arguments are:
1. By splitting the project up into a number of small sub-projects it's
going to make it more difficult for the developers to work on the code.
Currently everything is in one CVS project which can easily be checked
out using Eclipse. How do others deal with this? By working with
different sub-projects in IDE or checking out all into one self-made
project (within IDE)?
2. There are a few moans about tranferring builds to different
environments whereby other ip-addresses/logins are needed for databases
etc. Is it possible to configure property files for these environments
and have goals to build for each environment? Other ideas , solutions??
THX
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Introducing Maven to developers
Posted by Lothar Märkle <lo...@netpioneer.de>.
On Wed, Aug 24, 2005 at 06:18:25PM +0200, Colin Chalmers wrote:
> 1. By splitting the project up into a number of small sub-projects it's
> going to make it more difficult for the developers to work on the code.
> Currently everything is in one CVS project which can easily be checked
> out using Eclipse. How do others deal with this? By working with
> different sub-projects in IDE or checking out all into one self-made
> project (within IDE)?
>
> 2. There are a few moans about tranferring builds to different
> environments whereby other ip-addresses/logins are needed for databases
> etc. Is it possible to configure property files for these environments
> and have goals to build for each environment? Other ideas , solutions??
we handle this with checked in configuration templates, and use the
ant:replace task to create a working config wiht a custom goal. All
logins etc. go into build.properties. This works well, and an automatic
setup for testing is also easy then.
hth,
lothar
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Introducing Maven to developers
Posted by Jeff Jensen <je...@upstairstechnology.com>.
I agree with the incremental approach.
One of the first things I did in introducing Maven to my current client is
to just set it up to generate site. I started on my PC and generated site
to it, sharing a "file://" URL for others to use the HTML pages. The value
of all the reference docs (Javadoc, xref, FAQs), automated code review
results, JUnit results, and Cobertura results became apparent fast, and
affected process and standards change - in a very good manner.
Since your customers think they are happy with the current build setup, I
suggest you generate site first and get that part of the process. Then work
on having Maven correctly build the distributables too, and ease into that
as site is accepted.
-----Original Message-----
From: eric.starr@wachovia.com [mailto:eric.starr@wachovia.com]
Sent: Wednesday, August 24, 2005 11:59 AM
To: Maven Users List
Subject: Re: Introducing Maven to developers
Concerning Argument 1:
If you can't get them to see the value then you may want to use an
incremental approach. This will involve more work on the front end for you
though...
Instead of changing the structure of their source, you can create a
maven/ant script that will download the source and place it into your
current directory (on Windows it might be c:\myMavenArea) into a directory
structure that maven likes( c:\myMavenArea\projectName\src\main\java\com...
) .
Then perform the build as you normally would with maven.
That way, you can create the build and show them the value of using Maven
without changing any or their source or their existing ant scripts.
If you want, you could then hold a "lunch time learning" session about Maven
and show them the massive and complex current ANT scripts compared to the
comparitivley small Maven script as well as the other nice project
management features you get for free using the maven plugins...
Colin Chalmers <co...@xs4all.nl> wrote on 08/24/2005 12:18:25 PM:
>
> 1. By splitting the project up into a number of small sub-projects
> it's going to make it more difficult for the developers to work on the
code.
> Currently everything is in one CVS project which can easily be checked
> out using Eclipse. How do others deal with this? By working with
> different sub-projects in IDE or checking out all into one self-made
> project (within IDE)?
>
---------------------------------------------------------------------
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: Introducing Maven to developers
Posted by er...@wachovia.com.
Concerning Argument 1:
If you can't get them to see the value then you may want to use an
incremental approach. This will involve more work on the front end for
you though...
Instead of changing the structure of their source, you can create a
maven/ant script that will download the source and place it into your
current directory (on Windows it might be c:\myMavenArea) into a directory
structure that maven likes(
c:\myMavenArea\projectName\src\main\java\com... ) .
Then perform the build as you normally would with maven.
That way, you can create the build and show them the value of using Maven
without changing any or their source or their existing ant scripts.
If you want, you could then hold a "lunch time learning" session about
Maven and show them the massive and complex current ANT scripts compared
to the comparitivley small Maven script as well as the other nice project
management features you get for free using the maven plugins...
Colin Chalmers <co...@xs4all.nl> wrote on 08/24/2005 12:18:25 PM:
>
> 1. By splitting the project up into a number of small sub-projects it's
> going to make it more difficult for the developers to work on the code.
> Currently everything is in one CVS project which can easily be checked
> out using Eclipse. How do others deal with this? By working with
> different sub-projects in IDE or checking out all into one self-made
> project (within IDE)?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org