maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz ...@durchholz.org>
Subject Re: MRM inside Eclipse
Date Wed, 06 Feb 2013 20:33:44 GMT
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:
./830bc118332e77292949ed1e6d2fabe0
./830bc118332e77292949ed1e6d2fabe0/write.lock
./830bc118332e77292949ed1e6d2fabe0/_5k.cfs
./830bc118332e77292949ed1e6d2fabe0/_5l.cfs
./830bc118332e77292949ed1e6d2fabe0/_5m.cfs
./830bc118332e77292949ed1e6d2fabe0/_5k_2.del
./830bc118332e77292949ed1e6d2fabe0/_5n.cfs
./830bc118332e77292949ed1e6d2fabe0/_5l_1.del
./830bc118332e77292949ed1e6d2fabe0/_5o.cfs
./830bc118332e77292949ed1e6d2fabe0/_5p.cfs
./830bc118332e77292949ed1e6d2fabe0/_5q.cfs
./830bc118332e77292949ed1e6d2fabe0/_5n_1.del
./830bc118332e77292949ed1e6d2fabe0/_5r.cfs
./830bc118332e77292949ed1e6d2fabe0/_5r_1.del
./830bc118332e77292949ed1e6d2fabe0/_5s.cfs
./830bc118332e77292949ed1e6d2fabe0/segments_5a
./830bc118332e77292949ed1e6d2fabe0/segments.gen
./72f1a3d25d727baca6dce66d9cb01212
./72f1a3d25d727baca6dce66d9cb01212/_2i.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2j.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2k.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2l.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2i_1.del
./72f1a3d25d727baca6dce66d9cb01212/_2m.cfs
./72f1a3d25d727baca6dce66d9cb01212/write.lock
./72f1a3d25d727baca6dce66d9cb01212/_2m_1.del
./72f1a3d25d727baca6dce66d9cb01212/_2n.cfs
./72f1a3d25d727baca6dce66d9cb01212/segments_2g
./72f1a3d25d727baca6dce66d9cb01212/segments.gen
./d9d714e11cb097b3ffcec91cccc65d3e
./d9d714e11cb097b3ffcec91cccc65d3e/nexus-maven-repository-index.properties
./d9d714e11cb097b3ffcec91cccc65d3e/_a5.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/timestamp
./d9d714e11cb097b3ffcec91cccc65d3e/_a5_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a6.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/_a6_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a7.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/_a7_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a8.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/write.lock
./d9d714e11cb097b3ffcec91cccc65d3e/_a8_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a9.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/segments_8g
./d9d714e11cb097b3ffcec91cccc65d3e/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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message