I know Kohsuke @ sun has a wagon that deploys to a svn server (as they run the sun maven2 repository off a svn repository)
The advantage to storing a maven2 repository in svn is that mirroring becomes low on bandwidth, as svn update will only pull the changes since the last update where as rsync needs to determine the changes before it can send them. -Stephen On Tue, Mar 11, 2008 at 1:53 PM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > John Coleman schrieb: > >> the problem is that people here want to store artifact / > >> external libraries in svn rather than in an internal repository > >> > > > > These people have some bad thinking. There is simply no point putting > > guaranteed static objects into VCS, which is all about tracking changes. > > And since the POM defines all the dependencies and how they are used, > > and everything required for a build, then that mechanism is already > > ideal. > > > > If they are concerned about losing some artifacts, then they simply need > > to back them up, or provide some clustering. All you need to do is keep > > a mirrored server of your repo. > > > > > >> only thing i could think was to store the maven repository in > >> svn and check it out every time, pointing maven to look at > >> the localRepository in my custom directory > >> > > > > This is a "solution", but one to a problem that doesn't exist. Absurd. > > > > In my experience, this is a very common attitude though. > > For example, the jspwiki project currently under apache incubation > stores its dependencies in the version-control system and will not > change. And they are not stupid people; it is just the way they like to > work. > > In at least two previous jobs I have also tried to persuade people to > avoid storing deps in version-control and failed. So regardless of > whether it is right or wrong, it would be useful to have a way for maven > to deal with this. Persuading people to move to maven is difficult > enough without having to tackle a second problem like this concurrently. > > BTW, one of the issues is that previously java classpaths had to be set > up with the explicit names of dependent jars; having dependencies that > change names was awkward. So simply having a stable name, and > overwriting with later versions of the jars was tempting. Now that java > can use "*" to pick up all jars in a dir this is no longer relevant, but > the habit endures. > > I think that in this case, storing the repository in VCS makes sense. > Ideally you would have a webserver acting as a repository which receives > svn commit messages for the repo directory and automatically updates its > dir, so that commits of new jars are visible immediately. > > I think your suggestion of pointing maven at a locally-checked-out > repository tree is also possible I think; hopefully "file://" is > supported as a repository base url. > > Cheers, > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
