I'd like to see more people test this branch against their own code.
Test it on their own system, use the integration tests.
I'm a bit surprised there was so little problems with it on my end.
- Joakim
Brett Porter wrote:
On 05/02/2007, at 11:01 AM, Jason van Zyl wrote:
I think there is something wrong in that we would need a cache. It's
bleeding memory why and how is a cache implementation over a HashMap
going to help?
It's bleeding memory because there are thousands of POMs in the
repository, and the hashmap has no limiting. A cache would allow them
to be expired, size, limited, etc. so the memory consumption is fixed.
And how long does it really take to build up a MavenProject. In the
CLI working in the reactor it helps using a HashMap.
Not really understanding here. Are you saying no cache is necessary,
or it can be done elsewhere? Dependency POMs are built many times
across the life of a maven build, so the cache is certainly improving
performance compared to reading them back from the file system in the
local repository.
In something like Archiva the model should be placed in a store, not
cached so I don't think it really helps there a whole lot.
That's a separate discussion, but the repository is the store. Only a
subset of the POM is stored in the index, and there is no point
duplicating the POM it into some other store.
Anyway, not relevant - the current project builder caches everything
and needs to be made configurable so that it doesn't.
I don't see why it would matter, it's just swapping implementations
- either way the cache still needs to be moved if the project
builder is cleaned up. IMO it would be better not to lose track of
the change and do it now.
The function of the cache in there was ever only the short-lived
in-session reactor so that it didn't rebuild in that case. A
long-lived app should not be pulling an object from a cache from the
building to show in an application. A cache helping a real store
maybe, but in short that HashMap in the builder was for very
short-lived reasons i.e. the reactor and the builder is probably then
the wrong place for the cache. The builder should not be in the
business of caching project objects for applications.
I agree, but that wasn't my point.
How about if instead the project builder adds a temporary config item
that allows disabling the hashmap cache instead. Keep it there until
it is refactored out so Maven keeps working, and we can disable it
from Archiva and take care of the caching there?
- Brett
---------------------------------------------------------------------
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]
