-----Original Message-----
From: Steve Cohen [mailto:sco...@javactivity.org] 
Sent: 23. februar 2009 17:12
To: Maven Users List
Subject: Re: Mavenizing existing project

Unfortunately, you guys may be talking me out of mavenizing rather than 
into it. :-(
My situation is a bit different than what is described.

There are only two or three real "developers" in my project and they 
work on separate applications with very little sharing between them - 
and I am one of them, the one most involved in coding, in fact. I'm not 
an SCM guy per se, though automated builds have always been an interest 
of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an

anti-pattern, and would like to move toward a truly automated build. (As

I indicated in my original post, we don't even use Ant here - we use 
Eclipse's built-in Export to build - and even THAT was a big step 
forward for this team). But a local, networked M2 repo is going to run 
up against all sorts of security minefields.

So I would like to explore a somewhat different path:

1) abandon any thought of a local repository for now. Too many 
political/bureaucratic issues. Each developer could download maven and 
the m2eclipse plugin himself and build a local repository of things
needed.

>Thats a work around.

2) create a POM in an SVN branch and develop automated maven-based 
builds using developer-local repos. If builds break, devs can update 
their repo.

>Seems okay.

3) as this becomes general, down the road, if and when the need for a 
local repo is perceived, only then take that step.

>Can you "create" a new user, and have all this done on a separate
laptop? 

Does this kind of plan make any sense to you guys?

Jon Georg Berentsen wrote:
> +1
>
> -----Original Message-----
> From: Samuel Langlois [mailto:slangl...@ilog.fr] 
> Sent: 23. februar 2009 16:11
> To: users@maven.apache.org
> Subject: Re: Mavenizing existing project
>
>
>
>
>   
>>> 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.
>>
>> This is the way I recommend myself.
>>
>> There are two ways you can do this...
>>
>> 1. Make the changes in trunk, and keep the existing build process
>> functional
>> while you change everything... this allows you to ignore maven until
>>     
> you
>   
>> get
>> everything perfect.
>>
>> 2. Make the changes in a branch and merge them back when you're
>>     
> ready... 
>   
>>     
>
> I agree you should follow the Maven "happy path".
>
> I migrated a big several-million-LOC project from Ant to Maven, and I
> chose
> a 3rd way, somewhat in-between.
> The trick is to keep the trunk as it is, so that people can still work
> with
> Ant as they are used to, and to perform the migration in a branch.
> In the branch, you commit only your pom.xml files and an empty folder
> structure. Every time you need some files from the trunk, you use
> svn:externals to make a kind of 'dynamic link' inside your SVN
> repository.
> Typically, your svn:external will look like this:
>   module/submodule/src/main/java
http://repo/trunk/module/submodule/src
> This way, you can quietly migrate without bothering anyone.
>
> When the migration is ready, you also need to make a shell script that
> will
> copy the pom.xml from the branch to the trunk and move all source
> folders in
> the right place.
> Similarly, you can prepare and test this script quietly on your side
> without
> impacting developers.
>
> The migration itself is then just a matter of minutes, while the
script
> is
> run and you commit everything.
>
> That was a little more work for me, but not having 40 stuck developers
> on my
> back while I was performing the migration was priceless :-)
>
> Hope this will help you
>
> Samuel
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to