> > I'm not sure I'm not mistaken for the read part: with the current repo > format, > one thing that is super easy is that each artifact version is just a path > that > you can use simultaneously in one build or in multiple builds >
e.g. build #1 using --classpath ~/.m2/repo/tw/xstream-1.4.3.jar build #2 (concurrent or soon after) using --classpath ~/.m2/repo/tw/xstream-1.4.4.jar other builds using one of those two (again) or more, concurrently or not. Got it. > With the proposed git repos, I don't get how read access to a tag is done > without changing disk state, so you can access mutliple tags at the same > time. > Without a *fanciful* change to java and javac, the toolchain is stilll going to need to make jars as we've always known them. The toolchain for recreating jars (notwithstanding timestamps on class files issues previously noted) from the blog entry: git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch 1.4.3 cd mc-xs-classes rm -rf .git jar cvfM ../xstream-1.4.3.jar . cd .. rm -rf mc-xs-classes That might be faster for Java and the widely used JGit if it can be done in memory. It took 3 secs for me, with 2 of that being the jar step. On a development workstation, that style of use *exclusively* will mean you can rebuild ~/.m2/repository as we know it today, jar by jar. Specifically, you don't retain the jar .git folders per repo for things pulled from from 'central at all. Other people, optionally, could say then want to host their own .git/ centric cache of things pulled down from 'central. That could be on a network mount somehow, or (more realistically) an anemic Artifactory of Nexus service. That could even be on their own box rather than for the team, of they are happy to momentarily use *more* hard drive space than the ~/.m2/repository of today. I think if had a local .git representation of things from 'central, I would be deleting ~/.m2/repository every night when I wasn't using the machine. I mean, in lieu of a more sophisticated solution. Regards, - Paul > > > This "on read" question happens with "on write": but as you told the idea > is > more to consume releases from a central repository, and not on the desktop > with SNAPSHOTs and so on, the write question is not really a question. > > Regards, > > Hervé > > > > > - Paul > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
