You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2022/10/21 07:47:19 UTC
[GitHub] [maven] nielsbasjes opened a new pull request, #840: [MNG-7038] Introducing project.topdir
nielsbasjes opened a new pull request, #840:
URL: https://github.com/apache/maven/pull/840
[MNG-7038: Introduce public property to point to a root directory of (multi-module) project.](https://issues.apache.org/jira/browse/MNG-7038)
This pull request simply introduces the new variable `project.topdir` which has been documented and points to the top directory of a (multi module) project.
Please double check if you agree with both this variable name and the way I have implemented it.
---
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] [JIRA issue MNG-7038](https://issues.apache.org/jira/browse/MNG-7038).
- [x] Each commit in the pull request should have a meaningful subject line and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX`
and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue
title in the pull request title and in the first line of the commit message.
- [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.
- [ ] You have run the [Core IT][core-its] successfully.
To make clear that you license your contribution under
the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] kwin commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
kwin commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286627143
> This also means the (internal) maven.multiModuleProjectDirectory suffers from the same problem
This is internal for a good reason and should only be used for finding the `.mvn` directory belonging to the current project (and even there may fail)
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288093272
A practical example is in this project https://github.com/nielsbasjes/yauaa I wanted to have a single set of project specific checkstyle config. I ended up with packaging these files in a jar and making that a dependency of the checkstyle plugin.
The only reason is not having a stable topdir which I could refer to.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286589500
Sidenote: I found in the [init](https://github.com/apache/maven/blob/18eff3baeb899ddd27b34635c8f0d7e47f5c027b/apache-maven/src/assembly/shared/init#L33) script there is something called `basedir` that seems to be very similar to this `project.topdir` (it is different if you have a .mvn somewhere half way your project tree) yet it is very different from `project.basedir`.
Confusing!
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1287770947
I think I ran into a chicken-egg type of problem.
- I would like to have the project.topdir available as a variable that can be used in the pom.xml to pin point things. This implies it must be available before that point.
- Yet the only viable way to determine it is after the pom.xml has been parsed and at least the parents are available.
I would like to have some suggestions on how to handle this is.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286625160
This also means the (internal) `maven.multiModuleProjectDirectory` suffers from the same problem: It may traverse outside of the project root. This will also cause problems if people checkout a different project in a subdirectory of their current project.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286933973
I fully agree to have a new `${project.topdir}` that won't go outside of the tree.
For the `${project.topdir}/.mvn/settings.xml` use case, I'm not sure how that could be handled if multiple projects have different parameters. If those projects are included in a bigger build, everything inside `.mvn/` becomes irrelevant I think, and all access to this directory should be done using `${maven.multiModuleDirectory}`.
Note that we also have the `executionRootDir` which seems to reflect the upper parent path _being built_ (mainly when using `-f xxx` option).
All those properties should be clearly defined and made public.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288068151
Cases to think about I just thought of:
Context: Multi module project, all `parent modules` have pointers towards their `child modules`.
- A child module points to the correct parent (within the project).
- A child module points to a different parent within the project.
- A child module points to a parent outside the project.
- A child module has no parent.
One of the child mentioned edge cases has settings IN the child module (i.e. `${project.topdir}/mvn/settings.xml` is not really the top of the entire project).
In this example the build of such a module will yield different results if built from the real top v.s. build from within the module itself.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286950230
> * check parent of current (non-effective) pom
> * if it has relative path being non empty, check the given path
> * check recursively until no more relative path is set/not found
One question comes to my mind. Are all those properties system properties ? It would make sense to have some of them being computed relative to a given project (in the `pom.xml` or `MavenProject` sense). Especially if we want to support aggregating multiple projects in a single build, each _subproject_ should have a clearly to identify its own _topdir_.
Given I don't think there's a simple way to find the logical root, especially when projects are used as subproject in a bigger build, we may need to actually use the fact that there is a `.mvn/` directory somewhere and stop there. Also children may have a parent outside the build itself, and thus we can not only going through the parents to find the _topdir_.
I think that's how the current `maven.multiModuleDirectory` is computed, but we need one per-project, in case there's an aggregation.
Also I would keep `project.xxx` for things that needs to be computed per-project (especially in case the project is used inside a bigger project), and `maven.` for things that are unmodified during the build.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet closed pull request #840: [MNG-7038] Introducing project.topdir
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet closed pull request #840: [MNG-7038] Introducing project.topdir
URL: https://github.com/apache/maven/pull/840
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288067732
> @gnodet Thanks for the code pointer. This really helps in my understanding the code.
>
> > For the per-project settings.xml, I don't think they should use the topdir, at least not using the parent hierarchy. I think the way the multiModelDirectory is currently computed would better fit the need. Especially if the settings.xml is to be located in the .mvnd/ directory.
>
> I disagree with this because if you want the settings.xml in a `.mvnd` then you currently must also create a `.mvn` with a dummy file or it will not find the correct directory. Also the absense of a `.mvn` in a project can lead to unexpected effects.
>
> @michael-o Yes, good point.
>
> I agree with the property being immutable from an as early moment in the build as possible.
>
> My current thoughts about the meaning of the topdir:
>
> * It is the `filesystem directory` of the top module `within` the project. So I intend to walk up the `project/module tree` instead of the `filesystem directory tree`.
> * Walking up stops if there is no parent defined or the parent is outside the project (relative path is empty).
Note that with build poms, the relative path can be kept empty and it will be inferred from the reactor. But it should be available after the first phase of the model building IIRC.
> * So if there is a pom.xml without a parent, yet in the parent `filesystem directory` there is a pom.xml, walking up will still terminate because there is no parent relation defined.
> * This also means that in a single module project it is the same as the `project.basedir`.
>
> The important difference with the `multiModelDirectory` is that that one walks up the `file system` directories until it finds a `.mvn` subdirectory (or /). This has a real possibility of walking out of the project. So the same project on the same machine in a directory under the same user with all environment variables the same may still be built differently only because it was checked out in a different subdirectory where one of the parent folders contains a `.mvn` with some kind of config file that is picked up.
>
> So the `topdir` definition I have in mind does not depend on the existence of `.mvn` or `.mvnd` or anything else and as such can be used more reliably in all projects.
It really depends on the structure of the project. Some projects may not have their ancestor as the topmost directory. We need to cover those use cases too. Also, it needs to work during a project-aggregation (or we need some properties for that). I think we need to think in terms of use-cases, not properties.
What's your first use-case for the topdir thing ?
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288068788
@gnodet My first class of usecases is a consistent location for project level settings ( https://issues.apache.org/jira/browse/MNG-5659 ) which will solve a lot of practical problems for many of the projects where I work.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288104958
> A practical example is in this project https://github.com/nielsbasjes/yauaa I wanted to have a single set of project specific checkstyle config. I ended up with packaging these files in a jar and making that a dependency of the checkstyle plugin.
> The only reason is not having a stable topdir which I could refer to.
Well, I don't think the _topdir_ as defined above would work. What you need here, is a _project resource_, so can have a stable absolute path on the file system for the root of the project. It has nothing to do with parent/child relationship imho. The parent/child relationship defines inheritance in the project models, but is completely unrelated to their respective file system location. And what we need here is definitely a file system based property.
This top level directory is used by maven. When you invoke maven from a child, all the POMs from the reactor are loaded. This is done through the `multiModuleProjectDirectory`. And that one is also used to load various _build settings_ currently, such as `.mvn/maven.config` and `.mvn/extensions.xml`.
I think this property works well when the projects are standalone.
Problems arise when projects are aggregated, or when `.mvn` directory does not exist for the current project, but exists in a parent directory. In which case, the computation is kinda broken because it goes outside the project's root directory.
Not sure yet how to fix that for the aggregation case, but for the second case, we could refine by checking if there's a `pom.xml` file in the parent folder before allowing to use it.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288099174
> @gnodet My first class of usecases is a consistent location for project level settings ( https://issues.apache.org/jira/browse/MNG-5659 ) which will solve a lot of practical problems for many of the projects where I work.
We need to split between _build settings_, and _project resources_ I think. By _build settings_, I mean things that are loaded once for a given maven session. Per-project `settings.xml` would be one of those.
However, locating _project specific resources_ is different, especially you want to refer to the project root on the filesystem to let maven translate that into an absolute path. I'm thinking about checkstyle rules referred to as `build/checkstyles.xml` or similar.
When such projects are aggregated into a bigger project, the _build settings_ can't really be loaded per-project. However, _project resources) have to keep working.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286619888
@kwin You are right.
That is probably a lot better, also because this code in init will travel outside of the project and even the homedirectory of the user to find the `.mvn` directory.
however...
The problem I see is that for some things, like reading the `${project.topdir}/.mvn/settings.xml` (See [MNG-5659](https://issues.apache.org/jira/browse/MNG-5659)) you'll need to have that available before the pom.xml files are read.
This needs more investigation on how to implement!
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] merikan commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
merikan commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288845375
I've been following this thread and I just thought I'd throw in my two cents. This is what my use case looks like:
Over the years I have built a number of multi-modular projects that have spring-boot as a parent. I have a number of artefacts in the root (folder) that I want to access from my sub-modules (pmd, spotbug, spotless, dependency-check, etc).
```
root
├── etc
├── module1
├── module2
├── module3
└── pom.xml
```
Initially I was using a build-module but since it was used as a dependency and was not always available I gave up using that approach.
The solution I've been using for the last few years is the `build-helper-maven-plugin` and the `rootlocation` goal. I don't know how it resolves the root location, but it has worked in all my projects without any problems. (The only problem with this solution is that a plugin is bound to a phase and since there is no default phase to bind to, I always have to run validate before if I want to execute the plugin goal from the command line, like this: `$ mvn validate spotless:check`. But that is an entirely different issue)
```
<configuration>
<printFailingErrors>true</printFailingErrors>
<failOnViolation>true</failOnViolation>
<rulesets>
<ruleset>${rootlocation}/etc/pmd/pmd-ruleset.xml</ruleset>
</rulesets>
</configuration>
```
I guess most Maven projects probably use, for the sake of simplicity and probably the most intuitive, a direct hierarchical structure which is also reflected on the file system. So do I, with a few exceptions where I used a parent module that was next to the child modules. When using the `relativePath` element, we can have all sorts of parent-child relationships where submodules might have different parents and it can get very complicated. Most people probably like to think of a common ancestor in a project but it is not, as I understand it, something that maven imposes.
I understand that people can have quite complex project structures and maybe also in a mono-repo and that Maven should be able to support it. To me it sounds reasonable to assume a `.mvn` directory as the root when using a subfolder structured project but there may be use cases where that is not correct either.
For me, regardless of which submodule I'm building from, I want to be able to find my shared artefacts up in the hierarchy (file structure). This is what many tools does and most people are used to it and it is quite accepted. I do think that mixing it with pom parent relation makes it a lot more complicated.
One solution could be to use different strategies for resolving the project root (topdir) and one strategy, the default one, could be to traverse the directory tree searching for a marker, e.g. `.mvn` directory. To make it more flexible when traversing the tree, then maybe it should be possibility for the user to override the marker, for what is considered a project root, with another directory or filename.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288878456
> The solution I've been using for the last few years is the `build-helper-maven-plugin` and the `rootlocation` goal. I don't know how it resolves the root location, but it has worked in all my projects without any problems. (The only problem with this solution is that a plugin is bound to a phase and since there is no default phase to bind to, I always have to run validate before if I want to execute the plugin goal from the command line, like this: `$ mvn validate spotless:check`. But that is an entirely different issue)
Fwiw, the `build-helper-maven-plugin` uses the following heuristic: it goes up the list of parent directories and at each step, checks if there's a `pomx.ml`, loads it and checks if the loaded project has the current project as a child module (so not in the sense of parent/child inheritance, but using a `<module>` element that is used to define the reactor). The benefit is that it works with a traditional project, even if the model's parent is not located in the parent's directory. The particular point is that if a project is aggregated in a bigger one, it will go up the chain, so may go out of the project tree. And it won't stop when there's a `.mvn` project. Another downside is that it uses maven to load the parent project so that heuristic can not be used from early shell scripts.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] kwin commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
kwin commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1286597191
> I found in the [init](https://github.com/apache/maven/blob/18eff3baeb899ddd27b34635c8f0d7e47f5c027b/apache-maven/src/assembly/shared/init#L33) script there is something called basedir
IIUC then the property value of the newly introduced `project.topdir` relies on exactly this value (https://github.com/apache/maven/pull/840/commits/f7ad2cd1761158ced919327e68c12a23f6d80f25#diff-5ac9f422973753d652e14ce805f3882b3de8ad6bbe158f93251c19ff1ee06a52R19).
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1287888704
> I think I ran into a chicken-egg type of problem.
>
> * I would like to have the project.topdir available as a variable that can be used in the pom.xml to pin point things. This implies it must be available before that point.
> * Also I would like to base loading a project specific settings.xml opon this variable ([MNG-5659](https://issues.apache.org/jira/browse/MNG-5659))
> * Yet the only viable way to determine it is after the pom.xml has been parsed and at least the parents are available.
>
> I would like to have some suggestions on how to handle this is.
This would have to be computed inside the `DefaultModelBuilder`. The models are built in two phases. After the first phase is done, all models have been read and the needed information should be available. So the best place may be (without much thoughts) in the `DefaultModelBuilder`, just before the model interpolation. The parents (and all models from the reactor) should be available on the model building request. The relevant code is [here](https://github.com/apache/maven/blob/24329561fc9092ba7a10aa9c7a378b392e0d9301/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L883-L886).
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
michael-o commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288054316
I think before anything can be decided, I'd expect a full documentation of all possible cases where such a directory can be calculated. It hink that a project property should not mutate during the build since it is bound to the current module being executed.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] nielsbasjes commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288063561
@gnodet Thanks for the code pointer. This really helps in my understanding the code.
> For the per-project settings.xml, I don't think they should use the topdir, at least not using the parent hierarchy. I think the way the multiModelDirectory is currently computed would better fit the need. Especially if the settings.xml is to be located in the .mvnd/ directory.
I disagree with this because if you want the settings.xml in a `.mvnd` then you currently must also create a `.mvn` with a dummy file or it will not find the correct directory.
Also the absense of a `.mvn` in a project can lead to unexpected effects.
@michael-o Yes, good point.
I agree with the property being immutable from an as early moment in the build as possible.
My current thoughts about the meaning of the topdir:
- It is the `filesystem directory` of the top module `within` the project. So I intend to walk up the `project/module tree` instead of the `filesystem directory tree`.
- Walking up stops if there is no parent defined or the parent is outside the project (relative path is empty).
- So if there is a pom.xml without a parent, yet in the parent `filesystem directory` there is a pom.xml, walking up will still terminate because there is no parent relation defined.
- This also means that in a single module project it is the same as the `project.basedir`.
The important difference with the `multiModelDirectory` is that that one walks up the `file system` directories until it finds a `.mvn` subdirectory (or /). This has a real possibility of walking out of the project. So the same project on the same machine in a directory under the same user with all environment variables the same may still be built differently only because it was checked out in a different subdirectory where one of the parent folders contains a `.mvn` with some kind of config file that is picked up.
So the `topdir` definition I have in mind does not depend on the existence of `.mvn` or `.mvnd` or anything else and as such can be used more reliably in all projects.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288063458
> I think before anything can be decided, I'd expect a full documentation of all possible cases where such a directory can be calculated. It hink that a project property should not mutate during the build since it is bound to the current module being executed.
Agreed on all points. For the project specific properties, it could be either:
* be made available for interpolation during the project building
* or added as project property in addition to user properties defined in the pom
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] merikan commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
merikan commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288932108
> Fwiw, the `build-helper-maven-plugin` uses the following heuristic: it goes up the list of parent directories and at each step, checks if there's a `pomx.ml`, loads it and checks if the loaded project has the current project as a child module (so not in the sense of parent/child inheritance, but using a `<module>` element that is used to define the reactor). The benefit is that it works with a traditional project, even if the model's parent is not located in the parent's directory. The particular point is that if a project is aggregated in a bigger one, it will go up the chain, so may go out of the project tree. And it won't stop when there's a `.mvn` project. Another downside is that it uses maven to load the parent project so that heuristic can not be used from early shell scripts.
thanks for the update. I didn't know the build-helper-maven plugin worked like that, although I probably suspected it. Good to know what the reason is, if it ever goes outside my project tree
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #840: [MNG-7038] Introducing project.topdir
Posted by GitBox <gi...@apache.org>.
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288634911
I'm wondering if it would make sense to add a new element in the build POM model (which would be removed in the consumer pom) to specify that a given pom is the _top level pom_. The heuristic to obtain the `multiModuleDirectory` would then be update to go up in parent directories until we find a pom flagged as root. This would allow not forcing the use of an empty `.mvn` directory.
I do think that this need to be thought with projects aggregation in mind.
This could be either an attribute `<project type="root" ...` or an element `<type>root</type>`. We may need another value for specifying _aggregate_ poms if we end up having to specify them explicitly to change some behaviours. Aggregators could be identified by having one `pom.xml` in a parent directory flagged with `type='aggregator'` in which case, the `multiModuleDirectory` would point to the aggregator root, while project specific resources (to locate file in the source tree) would not go upper than the `root` project.
--
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-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org