<lacostej> yo ! Is there anything I can do in exchange for some comments regarding MNG-3595 ? at least to know if this problem is something that is worth addressing. Thanks
<Brian> lacostej, i don't think we should make that change in 2.0.x, but perhaps 2.1
<Brian> it's a little scary to make changes in this area anymore because it will inevitably break someone's build
<lacostej> Brian: OK. I am willing to provide a cleaner patch for 2.1, I just need some comments on what approach to follow.
<lacostej> the current patch cannot build any existing build as it provides a new hook for adding the functionality. But I don't like changing MavenProject
<Brian> jdcasey, wdyt?
<jdcasey> lacostej: I'm not sure I get it, the clover plugin would register a post-processor for dependencies? or, would it attach a post-processor to the project for use ahead of successive plugin executions?
<jdcasey> lacostej, Brian: why not simply remember when/what scope we've resolved to for a given project, and avoid re-resolving? then swizzled artifacts would remain intact for the forked project instance
<Brian> jdcasey, that would be the preferred technique performance wise also, but i'm afraid of consequences in 2.0.x
<lacostej> jdcasey: the way I solved the problem was just the quickest solution I found. The problem is that successive plugin executions affect the list of transitive dependencies, because of the requireDependencyResolution tag. The idea was then to post process this dependency resolution operation, if it is to happen again. Another solution would be to prevent from the re-resolution to happen again,...
<lacostej> ...but I wasn't sure if it is possible to achieve this without locking maven into one corner. I wasn't sure why we were not already re-resolving for each plugin that required it
<jdcasey> Brian: I understand, but this should be relatively tame
<jdcasey> lacostej: I think as long as we never prune the list of transitive artifacts (i.e. going from test scope to compile scope only) in the project instance, we should be able to avoid re-resolving pretty safely
<Brian> there's a lot of sketchy stuff in there, like you may still get artifacts even if you didn't request resolution, depending on what plugin(s) ran before
<jdcasey> IIRC, there is another long-standing issue with re-resolving the artifacts...jesse filed it, but I'd have to dig around to find it again
<lacostej> jdcasey: what happens if we start adding a new scope ?
<jdcasey> Brian: true, we'd almost need a masked project instance for things that didn't request dependency resolution
<Brian> yeah which is why this scares me in 2.o
<jdcasey> Brian: you don't think we could hem it in with a bunch of tests and get the possible pathways covered?
<jdcasey> I mean, it'd be a lot of work, and this is sort of an edge case (if you don't mind my saying so), but still...
<jdcasey> 2.1 is definitely safest
<Brian> i'm risk averse after the mess we went through with .9
<Brian> we're trying to reduce regressions not make more
<jdcasey> it's probably worth mentioning in connection that we ought to do a full audit of the mutability of the MavenProject instance, to make sure things are intuitive across the board...fwiw
<lacostej> jdcasey: that's a good think. In fact what I was missing when developing is a contract between the plugins and maven core
<jdcasey> Brian: that pretty much means just shoring up the behavior and adopting a sunset clause for 2.0.x asap, then?
<jdcasey> lacostej: yeah, the formal contract thing keeps coming up
<lacostej> e.g. what should a plugin expect after using setArtifacts()
<jdcasey> I started looking at that awhile back, something outside the core that was fluent in both the 2.0.x core and the 2.1 core, but ran out of time
<Brian> jdcasey, that's essentially what i had in mind, continue to fix bugs and regressions only
<jdcasey> that's cool
<jdcasey> Brian: maybe it's worth talking about a less scary 2.1, then? something that will do a new feature-set in between the current plan and the 2.0.x features?
<jdcasey> I mean, we have enough code now to talk about killing bugs and doing a release
- jdcasey shrugs
<Brian> yes but 2.1 hardly works without the artifact stuff
<Brian> i've been pushing to close the scope on 2.1 for a while now
<lacostej> what's the rough idea behind 2.1 ? E.g. do you plan on enforcing maximum compatibility or can new features be favored over compatiblity ?
<jdcasey> Brian: there isn't that much change in the way it uses artifact...we could probably backport it for a quick release, then move forward to the new artifact stuff in 2.2
<jdcasey> lacostej: addressing some of the design flaws in 2.0.x, like extension loading for instance
<jdcasey> and plugin-versioning/-configuration differences
<lacostej> jdcasey: back to the issue, the reason I didn't try to lazy resolve the dependencies (and opted for a post-processing instead), is that I wasn't sure what the contract between the plugin and MavenProject would end up if one plugin uses setArtifacts() and at the same time, the plugin manager only resolves once. That could create issues for plugins that work later on in the lifecycle. That's...
<lacostej> ...why I wondered if there should be some guidelines on how operations that for example use setArtifacts() should be implemented in order to avoid plugin conflicts
<lacostej> Anyway. thanks for the comments. I will copy paste part of this chatlog in the issue. I will keep using my patched maven for now (it's only going to be used on our build server anyway) and see if I can get try the resolution caching instead.
<jdcasey> lacostej: sure, I understand. In any case, Brian has an excellent point in that this could be a major source of regressions unless we managed it perfectly and got very lucky...I guess I'd prefer to put it off until 2.1 as well...
<lacostej> jdcasey: I am still running 2.0.6 on one project due to regressions
<jdcasey> lacostej: I'm not sure I'm against the postProcessor idea, but it does seem a little hackish to continue re-resolving and just put in a longer resolution process, rather than figuring out how to limit re-resolution