Mikal Unfortunately, if my project choses to use Maven we will be the only project doing so here. There are probably 200 other apps in production plus 20-30 currently under development. So, I will have to conform to what the corporate standards are, regardless of my build tool. That may mean duplicate maintainence as far as storing jars etc, in a repository.
Like it of not, this is the reality of large corporate development where standards and best practices are sometime mandated based upon a wide range of criteria. Most of which have nothing to do with the day to day work of the developers in the trenches (see Tim Reilly's post) Randy Bielby x32258 >-----Original Message----- >From: Maczka Michal [mailto:[EMAIL PROTECTED] >Sent: Tuesday, June 15, 2004 3:24 AM >To: 'Maven Users List' >Subject: RE: Jar help > > >[...] >> >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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
