Hi, > I get the sense that adding <relativePath /> is something that would > upset IDEs (my experience has been that they cope relatively poorly > with anything uncommon like that).
My group uses "<relativePath />" a lot in IDEs including Eclipse, NetBeans and IDEA, and it works for us. I suggest giving it a try and seeing if it causes you any problems. Of course, in your case, since you have multi-module builds, you probably actually _want_ the default behavior of ".." for your submodules, so maybe you don't want to change anything. > Can a module name contain slashes? Sure can! It's a relative directory path. > I will give it a go. I've had somewhat poor experiences with the Maven > APIs as they tend not to be documented too well. Yeah, me too. I've found it pretty hard to get into Maven plugin development, especially since the APIs have gone through a few major iterations from 2.x to 3.0.x to 3.1.x etc. And in some cases, plugins mix and match APIs from those different iterations. :-O That said, this list (and the Maven dev list) is here for you. Others on this list know a lot more about it, and can help you win awards. > I may end up living with just not enforcing these things... Well, since this rule is mostly for you yourself, and not some nebulous cloud of community developers consuming your stuff, you can probably get away with a nice shell script that calls grep over your POMs, and barfs when various things are not found. Easy, right? Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Thu, Mar 2, 2017 at 1:34 PM, <org.apache.maven.u...@io7m.com> wrote: > On 2017-03-02T11:12:58 -0600 > Curtis Rueden <ctrue...@wisc.edu> wrote: > > > 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. > > Right. > > I get the sense that adding <relativePath /> is something that would > upset IDEs (my experience has been that they cope relatively poorly > with anything uncommon like that). > > > 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.) > > Hehe, I probably overstated it a touch. I tend to think of the <module> > entries slightly differently though: I consider them to be module names > that match the artifact ID of the submodule and also just happen to > correspond to the directory that contains the module's sources. They > don't inspire the same revulsion because they don't exist in my mental > model as filesystem paths. I'm not actually sure they are in Maven's > model either... Can a module name contain slashes? > > > > 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. > > I will give it a go. I've had somewhat poor experiences with the Maven > APIs as they tend not to be documented too well. I may end up living > with just not enforcing these things... > > M >
