> 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)
Maven artifact repositories are *not* hooked in with SCM systems. That is, when you compile your project, Maven tries to satisfy the dependencies by fetching the artifact via a URL (http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-1.0.jar or /home/user/java/repository/commons-lang/jars/commons-lang-1.0.jar). Maven does NOT talk SCM speak. It does not, for instance, do a SCM sync and then look in your local or remote repository to satisfy the project dependencies and build the classpath. > 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 Well...this is a different question than what I originally wrote. There are two groups of people at my work that want to configure our software projects in different ways. First way: If your project must follow another project's HEAD, then everytime you want to compile your own project you must also *compile* the other project you depend on. So you have to sync the other project, build the other project, then build your own project. This methodology obviates the need to install the other project's SNAPSHOT into a repository. Second way: The maven way - you depend on the SNAPSHOT jar and you don't build the other project yourself. Most companies have a dedicated Build and Test (BAT) machine for vetting changes to code and provide a single point of failure. I think the first way is daft but the argument for it is you are getting the very LATEST of a branch, not something that is almost near the HEAD. I think there are more drawbacks with this than advantages. > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
