One of the problems with any sort of caching right now is that MavenProject and Model are mutable. Passing around the same reference of these ubiquitous objects, means that any component can modify other components, changing their behavior internally. This is a pretty serious encapsulation issue. It's even worse that a class could invoke MavenProject.getModel and then leak the mutable model, which backs MavenProject, out to some other class. Having a global caching strategy without enforcing some level of immutability in these objects could exacerbate this encapsulation problem.
We may consider having the embedders (or some attached component) explicitly control the updates and deletions of the cache. If mutability of MavenProject/Model is absolutely necessary, attaching listeners could also prove beneficial so that if there are changes to a cached object, at least the classes using the objects could react, rather than having their behavior invisibly changed. Shane On Mon, Sep 29, 2008 at 12:41 AM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > 2008/9/29 Milos Kleint <[EMAIL PROTECTED]> > > > more likely should be something that gets carried over with the > > request. That however goes against the component architecture a bit as > > it requires the context (request) to be carried along through all the > > components. AFAIK workspace attempted to do just that, but I never > > took a closer look. > > > > Yes, I agree... that would be the right way > > > > > weak references are rather unpredictable and will not help for > > concurrent processing in multiple threads. > > > > However, they could be used to help caching... if the weak references are > entirely managed in the caching layer then multiple threads would not be as > much of an issue. I was not suggesting keeping the weak references in each > plugin, rather wrap the builder in a cached builder that keeps weak > references... It would also have the side-effect of allowing Maven (from > the > command line) to trade memory for performance when memory is running tight. > > (But, yes, in general they are a pane in the h*le) > > > > > Milos > > > > On Mon, Sep 29, 2008 at 8:08 AM, Stephen Connolly > > <[EMAIL PROTECTED]> wrote: > > > weakreferences? > > > > > > 2008/9/29 Shane Isbell <[EMAIL PROTECTED]> > > > > > >> When Jason tested the removal of the workspace, which handles caching > of > > >> MavenProjects, it exposed a lot of bad behaviors within Maven, such > > >> multiple > > >> instances of ProjectBuilder, excessive numbers of calls to > > ProjectBuilder > > >> (54K in one build of trunk). We put back in some simple caching > > mechanisms > > >> (hash maps) to get the build back to an acceptable speed. > > >> Obviously, hash maps is not the solution for the embedder, as that > would > > be > > >> a memory leak and doesn't provide easy clearing. That's something we > > need > > >> to > > >> discuss on the list: how we should handle caching within Maven, as > well > > as > > >> reducing the number of calls to the builder. > > >> > > >> Thanks, > > >> Shane > > >> > > >> On Sun, Sep 28, 2008 at 5:40 PM, Brett Porter <[EMAIL PROTECTED]> > wrote: > > >> > > >> > I was about to ask exactly the same question, Milos beat me to it. > > >> > > > >> > Can you elaborate more please? > > >> > > > >> > Thanks, > > >> > Brett > > >> > > > >> > On 29/09/2008, at 8:12 AM, Jason van Zyl wrote: > > >> > > > >> > We're just in the middle of ripping some stuff down and building it > > back > > >> >> up. All with the end of making it embedder friendly. > > >> >> > > >> >> On 28-Sep-08, at 2:50 PM, Milos Kleint wrote: > > >> >> > > >> >> Hello Shane, > > >> >>> > > >> >>> How will the cache be cleared? Other than dumping and restarting > the > > >> >>> container? > > >> >>> That would be a problem for embedded project loading. > > >> >>> > > >> >>> Milos > > >> >>> > > >> >>> > > >> >>> > > >> > -- > > >> > Brett Porter > > >> > [EMAIL PROTECTED] > > >> > http://blogs.exist.com/bporter/ > > >> > > > >> > > > >> > > > >> > > --------------------------------------------------------------------- > > >> > 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] > > > > >
