On 4 Feb 07, at 4:12 PM 4 Feb 07, 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.
That's just not the function of the builder. That's just wrong as
it's just not the job of the builder to be storing them like that.
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?
In the builder no cache should be present. It was jacked in there to
make reactor builds work a little quicker.
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.
I don't think anyone has ever measured how long it actually takes to
build a MavenProject. I don't think we want to put all that logic in
there anyway, because if you start using for things like Archiva then
you start having to check timestamps on disk or other source changes.
I think the caching should just be removed from the builder.
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.
That's one store. I'm actually sticking them in an object database
and who knows what other third party tool folks will do.
Only a subset of the POM is stored in the index, and there is no
point duplicating the POM it into some other store.
If you have read a released POM and have stored to a database why
would you ever need to build it again? Barring silly people re-
releasing the same things for a release consisting of all releases
that closure could be stored and really not need to ever be read from
a pom.xml file again.
Anyway, not relevant - the current project builder caches
everything and needs to be made configurable so that it doesn't.
I think the builder needs not to cache and then we make sure
everything works properly and when that's fine then start optimizing.
If you need this for the branch then that's fine but I would prefer
the trunk get cleaned up properly. The caching in the builder is
causing some very strange side effects.
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?
If you want to do on the branch go for it, but again I think the
caching should be tossed out of the builder and make to work
properly. I mean why not take the effort in the builder, toss the
cache, make it work and then use that cleaned up version in archiva?
That would probably serve your purposes for a long-lived process more
anyway no?
So if we put that in there and then two weeks from now I pull it out
and remove the caching you guys aren't going to complain?
If Joakim wanted to take a stab at that I would work with him for a
day to try and fix the builder properly. I'm sure in a day between
the two of us we could chop the project builder apart and fix it
properly. The cache in there is a band aid.
Jason.
- 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]
