On Wed, 2004-01-07 at 02:28, Steve Garcia wrote: > 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 -
For Java at least I don't think this was really practiced much before Maven came along. But for Perl there is CPAN and I believe now an equivalent for Python. Long ago when I did Perl stuff I always use CPAN which is definitely where some of the ideas in Maven come from. Even for Perl modules I made I put them in the local library. I have always found it stranged putting generated entities into an SCM. I don't like generated docs in an SCM and I don't like binaries in an SCM (save of course images and what not). For local projects that haven't a great number of dependencies which are external then it probably isn't really a big deal to keep your artifacts in an SCM. The benefit of using the repository is that at some point you are going to want to update some of the components you use: using a repository and POMs you rely on the knowledge of the project maintainers to track the dependencies for you. If you decide to upgrade to foo-1.2 from foo-1.1 and it's dependencies change then you can either figure out all the changes yourself or rely on the people that know about the project, namely the developers of that project. This of course assumes that we have all the POMs in the repository which we are moving toward. We don't have it yet but the design for it is there. So you can do this maintenance over and over again if you like but it boils down to the same notion, the most important notion in Maven is that the project information is stored once by the people who know about the project. As the repository is populated with POMs transitive dependencies will be possible and all sorts of cool things will then be possible. Again I'll come back to the upgrading of components: it's not impossible that there will be tools that could easily test various graphs of dependencies to see which ones work with your tests. Maybe you need a certain feature in an updated component which causes conflicts elsewhere and Maven could certainly help find a resolution that works. You could of course do this all yourself but why bother. I think the real power of Maven is really far from fruition and transitive dependencies will be a big part of that. I also hope that in time you will be able to take a POM and reliably build an entire project with all its dependencies from source so that if you really wanted to your could build everything from scratch with one simple command. If you could do that I don't really see much point in store binary artifacts in an SCM. Of course we need mechanisms like a much augmented release plugin incorporating the new Maven SCM project but we will eventually get there. > 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
