maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Georg Berentsen" <Jon.Georg.Berent...@Objectware.no>
Subject RE: Mavenizing existing project
Date Mon, 23 Feb 2009 17:06:19 GMT
If you have any 3 party dep that resides in any global Maven repos.,
hook that up first.

I belive your workaround will not come in conflict with the repo idea,
given your restrictions.
It's what maven does anyway, except for the manual installation for
modules.

But keep pushing for a company repo. Better to get it in 09 than
oh'never.

Jon 

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

Jon Georg Berentsen wrote:
> -----Original Message-----
> From: Steve Cohen [mailto:scohen@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.
>>     
Sure, but is it a bad one in my situation? The third party dependencies 
our projects depend on are not rapidly changing. The most typical change

is an "add" and that is rare. If a POM change breaks someone's local 
build, that's not that hard to overcome. Balancing this against the 
bureaucratic fight I would have to win to get a local repository, it 
seems to be a no-brainer. Having experience pointing to the need for it 
would help me win that fight. Otherwise it's biting off too big a piece.

My goal here is to improve process over time. I want to avoid continuing

down a path that over time make improving the process later harder.



---------------------------------------------------------------------
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


Mime
View raw message