[...] > >Not really. Maven repository is competly different beast then > >SCM repository > >and provides different features. > > > > Is it? Or is it just a difference of access protocol, http > vs pserver? > Yes, I know that versioning etc is not part of the repo, but > from a very > basic view of a jar containment mechanism, they could be used > interchangably. I'm not that familiar with the plugins, but I would > guess that I could implement a repostory plugin that access a cvs > repository rather than a Maven one. By basically creating a module in > cvs that had contents very similar to a Maven repo, I could in theory > accomplish the same thing. >
Yes it is different. First of all binary artifacts are not well handled by SCM repositories and versioning mechanism which is used by SCM is rather useless for them. E.g. you cannot easily check-in an artifacts and require that this is version 1.2.7 of log4j. Also metadata which is needed by maven repositories is different. Say that you have jar file and you want to find matching javadoc artifact or jar with sources (might be useful for debugging) SCM repositories don't provide any facility for that. It is true that you can theoretically use SCM repositories as maven repositories but if you do that you are probably not using a single feature which they provide (maybe with exception for security mechanisms). So from maven point of view there is no difference if artifacts are accessed from local file system or cvs repository (except of course of protocol which is used) > >> If the repo had an interface to CVS it then might become > >> more "sellable" in a corporate environment. That way all > >> components of > >> an application are contained with a single source control > mechanism. > > > >Jars and other generated artifacts are not "sources" and SCM > system are > >really useless for them. > >Are you going to keep javadocs in cvs as well? > > > > No they are not sources, but the ARE components that contribute to the > overall completion of the resulting artifact. There fore > they should be > under some kind of version control mechanism. In Maven case, that > mechanism is the Maven repository. And instead of the version > attributes of a given file being a relationship to the file, > it is part > of the name of the file. From and auditing standpoint, I have to be > able to recreate an EAR from a single repository. Plus I'm > not sure we > would pass an internal audit if some of our distributed binary was not > maintained internally. And then to top it all off, we have an > additional deployment tool (Harvest/AllFusion) for deploying to all > tiers above our development tier. > I am not sure if I understand you. Why would any of your binaries couldn't be maintained internally? Are you aware of the fact that maven works well without the access to ibiblio and only with intranet repositories? And how can you audit your projects if an audit tool cannot dig the information which artifacts were used in your projects? Maven repositories can be also used for deploying artifacts like report results. So you can for example track changes of the projects like test coverage, total number of tests and what ever else you want. I don't really think that those kind of artifacts should be kept in SCM systems. In fact I think that almost never "generated" artifact should be kept in such system. SCM systems are intend for keeping sources. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
