That's the lucene index of the maven repository. No content, just an index On Wednesday, 6 February 2013, Joachim Durchholz wrote:
> Am 06.02.2013 20:38, schrieb Stephen Connolly: > >> On Wednesday, 6 February 2013, Joachim Durchholz wrote: >> >> Am 06.02.2013 19:57, schrieb Stephen Connolly: >>> >>> See in-line >>>> >>>> On Wednesday, 6 February 2013, Joachim Durchholz wrote: >>>> >>>> Am 06.02.2013 17:47, schrieb Manfred Moser: >>>> >>>>> >>>>> I dont think there is a real MRM type of functionality in M2e ... >>>>> kind >>>>> >>>>>> of >>>>>> doesnt make sense to me either. A MRM is a server software while M2e >>>>>> is >>>>>> a >>>>>> development environment. >>>>>> >>>>>> >>>>>> m2e installs its own repository inside .metadata. >>>>> >>>>> >>>> Smells like a second local *cache* (one of the most confusing things is >>>> that we called it a "local repository" and not a "local cache" >>>> >>>> >>> It's where things land if you run a launch configuration that says "mvn >>> install". >>> >> >> Then it is eclipse's local cache. Plain and simple. >> > > Okay... what's the difference then? > > My current mental model of m2e's working is that it uses a normal Maven >>> runtime, accessing ~/.m2 as a local cache like Maven normally does, and >>> the >>> repository inside .metadata is a normal repository. >>> >> >> Nope. Wrong on at least one and probably two counts. >> >> 1. Eclipse uses the maven embedder, this is not the same as a maven cli >> install. >> > > Well, at least it generates very similar output and takes the same > command-line options :-) > > > It should build the same as *the soon to be released* 3.0.5 or > >> 3.1.0 depending on when it was cut. >> > > It comes with a 3.0.3 tag. (Recently updated from 3.0.2.) > > 2. I haven't checked the exact code, but I think Benjamin is implementing >> a >> "layered" cache, so if the artifact is in ~/.m2/repository then eclipse >> will just copy that into its cache (assuming the [dreads the >> misunderstanding *again*] source matches]. >> > > Name it "origin" and there's no misunderstanding. > > But yes I got it this time ;-) > > One of the subdirectories is even named "nexus", so I suspect (but >>> couldn't >>> verify) that m2e uses Nexus code. >>> >> >> Really melting like the more advanced local cache layout that Benjamin was >> working on >> > > I didn't understand that. Particularly what's "melting" here. > > On a dev tangent: It's somewhat unnerving to read that the cache isn't >>> thread-safe. Some people routinely do multiprocessing from the command >>> line, what if multiple tasks happen to execute a mvn command at the same >>> time? At least some locking would be in order, methinks. >>> >> >> Known issue, solutions are a available-ish... Just need an official >> release >> of Aether from Eclipse IIRC >> > > Thanks, good to know. > > The issue I'm having is that I can't manage that repository. >>> >>>> >>>> Because it's a cache but a repository (might look like a repository, but >>>> aether treats it differently) >>>> >>> >>> Probably not a cache. >>> At least I think so. Is there a way to tell by inspecting the >>> directories? >>> (It would be nice if there were.) >>> >> >> Metadata files with local in the name are a dead giveaway, but given the >> reworked local cache store that the version if aether used by m2e is using >> I cannot say that the absence if such is evidence that it is not a local >> cache >> > > Is the difference between a cache and a "true" repo documented somewhere? > > FWIW here's a listing of all files in it: > ./**830bc118332e77292949ed1e6d2fab**e0 > ./**830bc118332e77292949ed1e6d2fab**e0/write.lock > ./**830bc118332e77292949ed1e6d2fab**e0/_5k.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5l.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5m.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5k_2.del > ./**830bc118332e77292949ed1e6d2fab**e0/_5n.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5l_1.del > ./**830bc118332e77292949ed1e6d2fab**e0/_5o.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5p.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5q.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5n_1.del > ./**830bc118332e77292949ed1e6d2fab**e0/_5r.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/_5r_1.del > ./**830bc118332e77292949ed1e6d2fab**e0/_5s.cfs > ./**830bc118332e77292949ed1e6d2fab**e0/segments_5a > ./**830bc118332e77292949ed1e6d2fab**e0/segments.gen > ./**72f1a3d25d727baca6dce66d9cb012**12 > ./**72f1a3d25d727baca6dce66d9cb012**12/_2i.cfs > ./**72f1a3d25d727baca6dce66d9cb012**12/_2j.cfs > ./**72f1a3d25d727baca6dce66d9cb012**12/_2k.cfs > ./**72f1a3d25d727baca6dce66d9cb012**12/_2l.cfs > ./**72f1a3d25d727baca6dce66d9cb012**12/_2i_1.del > ./**72f1a3d25d727baca6dce66d9cb012**12/_2m.cfs > ./**72f1a3d25d727baca6dce66d9cb012**12/write.lock > ./**72f1a3d25d727baca6dce66d9cb012**12/_2m_1.del > ./**72f1a3d25d727baca6dce66d9cb012**12/_2n.cfs > ./**72f1a3d25d727baca6dce66d9cb012**12/segments_2g > ./**72f1a3d25d727baca6dce66d9cb012**12/segments.gen > ./**d9d714e11cb097b3ffcec91cccc65d**3e > ./**d9d714e11cb097b3ffcec91cccc65d**3e/nexus-maven-repository-** > index.properties > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a5.cfs > ./**d9d714e11cb097b3ffcec91cccc65d**3e/timestamp > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a5_1.del > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a6.cfs > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a6_1.del > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a7.cfs > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a7_1.del > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a8.cfs > ./**d9d714e11cb097b3ffcec91cccc65d**3e/write.lock > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a8_1.del > ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a9.cfs > ./**d9d714e11cb097b3ffcec91cccc65d**3e/segments_8g > ./**d9d714e11cb097b3ffcec91cccc65d**3e/segments.gen > > so there's a write.lock (0 bytes) and a timestamp file (8 bytes of binary > cruft), which looks like at least the m2e repo-or-cache does have locking. > > The nexus-maven-repository-index.**properties file has this: > > #Mon Feb 04 20:04:40 CET 2013 > nexus.index.id=central > nexus.index.chain-id=**1318453614498 > nexus.index.timestamp=**20130127130541.823 +0000 > nexus.index.incremental-19=189 > nexus.index.incremental-18=190 > nexus.index.incremental-17=191 > nexus.index.incremental-16=192 > nexus.index.incremental-15=193 > nexus.index.incremental-14=194 > nexus.index.incremental-9=199 > nexus.index.incremental-13=195 > nexus.index.incremental-8=200 > nexus.index.incremental-12=196 > nexus.index.incremental-7=201 > nexus.index.incremental-11=197 > nexus.index.incremental-6=202 > nexus.index.incremental-10=198 > nexus.index.incremental-5=203 > nexus.index.incremental-4=204 > nexus.index.incremental-3=205 > nexus.index.incremental-2=206 > nexus.index.last-incremental=**208 > nexus.index.incremental-1=207 > nexus.index.incremental-0=208 > nexus.index.incremental-29=179 > nexus.index.incremental-28=180 > nexus.index.incremental-27=181 > nexus.index.incremental-26=182 > nexus.index.incremental-25=183 > nexus.index.incremental-24=184 > nexus.index.time=**20120615133728.952 +0000 > nexus.index.incremental-23=185 > nexus.index.incremental-22=186 > nexus.index.incremental-21=187 > nexus.index.incremental-20=188 > > Looks like it's keeping track of when it last looked at Maven Central with > that. > > Can anyone identify what this is? > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
