Make plugin-maven use local config files if possible

[nedtwigg]

There are downsides to this approach, just pushing up to demonstrate a point for #571

[nedtwigg]

@lutovich I know this doesn't solve our big problem, but do you see any downsides to this tiny PR? If not I will merge.

[lutovich]

I can't think of any downsides 👍

Javadoc for this method could be adjusted to say that the method doesn't always copy the file.

[nedtwigg]

Thanks for the feedback, good call.

While we're at it, do you think there's any chance that we could take your filename-is-hash idea, and have just one resource manager in the root project, so that all subprojects are extracting resources to the same place? It's a performance optimization to know "if my filename hash is there, it's already been extracted before by someone else", and I think it would also solve #559.

[lutovich]

@nedtwigg IIRC Maven modules should be independent and not rely on files from parent modules. We've explored an idea to scan parent modules for config files here but decided not to do this to keep modules self-container. I think this issue helped us to decide. Feels like having a common place for config files could result in a similar any-pattern.

[nedtwigg]

Interesting. It is usually a bad idea to work against the container you're in, but I also think container designers are not infallible. In gradle, we've fought platform conventions a bit in a few minor ways, and in hindsight I'm still quite happy with all of those decisions.

IMO, there's a difference between "the child project cannot function unless the parent project does something" versus "every child project is going to perform the exact same operation, so using a central caching location can improve performance and reduce the number of moving parts, which reduces complexity". The projects are already sharing a SpotlessCache of classloaders (to great benefit! JIT is much better if amortized across all projects), imo it would make sense for their config files to also be shared. The terrible performance that #571 is seeing is really about what happens if you don't centralize those classloaders.

But I'm maven-illiterate, so it's very possible there's more to the firewalled projects than I appreciate. Definitely FileSignature needs to be improved someday anyway, but that looks to be pretty distant. The gitattributes thing is a hairy problem, and my Spotless time is waaaayyyy over its budget atm.

As a semi-related aside, I just merged in the ratchetFrom 'origin/master' feature for Gradle, and I'm pretty excited about it. I'd like to do the same for Maven, but one of the roadblocks is that in order for performance to be reasonable, you really want to centralize the git handling across all subprojects. That would requite taking this GitRatchet class, and turning it into:

public abstract class GitRatchet<Project> {
  protected abstract Project parentOfProject(Project project)
  ...
}

It works great in Gradle, but I wasn't sure if maven provided an analogous project class but thanks to checkstyle it looks like it is possible! It's very low on my prio-list, but I think adding ratchetFrom to maven will require a similar centralizing. Sorry for long stream-of-consciousness, but those are my broad thoughts on places where plugin-gradle has features/performance enabled by centralization, and where bringing plugin-maven to parity will be difficult without similar centralization.

[nedtwigg]

Released in plugin-maven 1.31.2