rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489105642
> But the parent/child relationship has to be done later in the process, so
can't be used for early interpolation.
Interpolation does not really works there anyway so no, but yes it will
require a 2 phases processing, guess it is not a big blocker as of today.
I'm not to add new properties, really just to get a single functional
rootdir one (hopefully merged with multi one but if not at least reliable on
any maven compatible projects).
My definition enables to use it for checkstyles, headers etc even without a
.mvn (whereas it works in a minority of cases - statistically - if not done
this way). It can also work when using an aggregator if the pom uses properties
to define paths exactly as .mvn case which does not solve this issue since for
a project with `root > {child1/.mvn>subchild1,child2/.mvn>subchild2}` it will
randomly take child1 or child2 as rootdir.
Side note: using .mvn also has a nasty side effect, we couldnt use it in
nested directories for module specific configuration anymore whereas it can
come later if we support lock files, dependency routing or other metadata per
module we don't want to put in the pom to keep it readable. It would be a
natural location for me.
Maybe thinking out loud but do we attack the issue by the right side, for
configuration location we want to be able to pin absolutely a file (often the
root pom), shouldn't we enable it? Main issue is that `${project.xxxx}` is
interpolated per pom so maybe we should enable a definition pinning, ie
`${project.definition.basedir}` - name is bad but sharing the idea - would stay
`/opt/foo` for `/opt/foo/pom.xml` but also its child `/opt/foo/child/pom.xml`?
This looks pretty easy to handle in interpolation and drops this `rootdir` need
in properties for user/mojo configuration. Can it be an outcome?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
