Hi, > I'd need to think a bit more about it, but I personally dislike > relativePath and have never used it (across hundreds of projects), > pretty much for the sorts of reasons you've described. Hard-coding > paths that represent links to other modules seems like a > horrendously bad idea.
That is fair. I will point out, though, that if you do not specify the relativePath, then it is ".." by default. Best practice is to write "<relativePath />" if you explicitly do _not_ want Maven to check for the parent in the parent directory. Hence, if we implemented my requireElements enhancement, the relativePath would be treated as ".." when one is not explicitly specified. I will also point out that each "<module>" of a multi-module build is also a hard-coded link to another module, which according to your reasoning, makes multi-module projects in general a horrendous idea. (And I am not being totally facetious here—I personally prefer never to use multi-module projects at all. Though I would not go so far as to call them "horrendous"—they definitely have their uses.) > I've written a few plugins, but I'm not intimately familiar with the > Maven API: Shouldn't it be possible to recursively retrieve the parent > POMs from the reactor (and failing that, the local and remote > repositories) within the plugin? That would remove the need for > <relativePath>. Sure. You are absolutely welcome to file a PR against the scijava-maven-plugin adding this feature. The complication is just that instead of loading POMs from local files, you now also need to resolve them from the appropriate remote repositories, for which there is certainly Maven API, but I am also not familiar enough with it to tell you what it is off the top of my head. Hopefully someone else here can comment in more detail, and/or suggest alternative solutions here. In any case, if you pursue this, it should work to test locally by installing the plugin into your local repo cache using the "install" phase, and then using "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs. Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Thu, Mar 2, 2017 at 11:02 AM, <org.apache.maven.u...@io7m.com> wrote: > On 2017-03-02T10:29:30 -0600 > Curtis Rueden <ctrue...@wisc.edu> wrote: > > > > it seems that I can only require that the XML elements be overridden > > > in *all* descendant POMs, and this introduces too much redundancy. > > > > I see. > > > > Would it be sufficient if the requireElements rule had a multiModule flag > > which, if set, green-lighted the build when the stated elements are > defined > > in the local parent POM? This feature would assume you are using the > > aggregator==parent scheme, and follow the <relativePath> declared in the > > <parent> of each POM. If it finds a POM there, it would parse it and then > > check for the required elements in _that_ POM instead of the initial one. > > And do this recursively, in case you have a multi-layered multi-module > > build. > > > > The downside of this approach: modules of a project would only build if > the > > parent is available locally. E.g.: if you try to build one module of a > > multi-module build which has been physically disconnected from its parent > > (e.g., a partial SVN checkout), the enforcer would fail because it would > > not find the local parent POM to validate against. One can also imagine > > various "aggegator != parent" organizations where the parent is not > > available locally, which would also all fail to support this scheme. > > > > I'd need to think a bit more about it, but I personally dislike > relativePath and have never used it (across hundreds of projects), > pretty much for the sorts of reasons you've described. Hard-coding > paths that represent links to other modules seems like a horrendously > bad idea. > > I've written a few plugins, but I'm not intimately familiar with the > Maven API: Shouldn't it be possible to recursively retrieve the parent > POMs from the reactor (and failing that, the local and remote > repositories) within the plugin? That would remove the need for > <relativePath>. > > If that is possible, then I think the pseudocode is: > > let root(p) be the root POM of project p > let parent(p) be the parent of p > let definesElements(p) return true if p defines the required elements > > Project q = p > while (!done) { > if (q == root(p)) { > throw RequiredElementsMissing() > } > > if (definesElements(q)) { > done = true > } > > q = parent(p) > } > > This feels like it would achieve what I need with only minimal > assumptions about the hierarchy of projects. > > M >
