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

Attachment: pgpNNHD4Cw4ln.pgp
Description: OpenPGP digital signature

Reply via email to