Who says its an either/or proposition?

Oh I know there are discussions about how you shouldn't put jars into an SCM
system, but if you're a paranoid product developer (like me) and you have to
be able to recreate any build of your published product 'as at' any time in
the past, I think you definitely want all dependent jars in SCM (I know I
do)

There is nothing to stop you using the maven repository model, but get to
the repository via an SCM checkin (or both)

How the 3rd party jars get onto ibiblio is one thing, but how 3rd party jars
get into your own remote repository is entirely another.

I am toying with the idea of a 3-tieres remote repository approach. One will
be for published artifacts (i.e. jar:install etc not under SCM otherwise I'd
probably have to monkey with the deploy plugin?). The second will be for 3rd
party libraries (under SCM control) and the 3rd would be ibiblio, probably
just for maven and anything maven directly needs.

I haven't set this up yet so maybe it's a really bad idea

Matthew

> -----Original Message-----
> From: Steve Garcia [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 07, 2004 6:28 PM
> To: '[EMAIL PROTECTED] '
> Subject: Articles on Artifact Repository
> 
> Does anybody know of any articles I can find on the Internet 
> detailing the advantages and drawbacks of using an artifact 
> repository (instead of sticking artifacts in an SCM) for 
> software development?
> 
> I want to read more about this style of development - I have 
> some colleagues who are not convinced that it is a good idea 
> to put artifacts somewhere else besides a SCM system.  While 
> there is general agreement that a repository is a good thing 
> (preventing duplicate copies of the same jar) my colleagues 
> argue that backing the repository with a SCM provides more 
> security (can't accidently put a patch into a third party 
> jar) and allows anyone to, at any past point in time, to get 
> a complete, unadulterated snapshot of a project and build it.  
> 
> I think there are good arguments both ways (even though I 
> support the Maven artifact model.)  
> 
> Thanks, Steve
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to