[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1475911408 > > That looks like mvnd but without keeping daemons alive... > > Not really since mvnd is a full mvn process whereas here it would just be a launcher responsible to handle the actual java command line to respect properly jvm.config. That's a wrong assumption. Mvnd has a client which boots a JVM (the daemon) and which is compiled to native with graalvm. The client does not load maven. -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1475696499 > > Fwiw, that will mean that the computation needs to be duplicated somehow, so that the maven launch script can locate the .mvn/jvm.config file and read it before starting the JVM... > > Well, we still have issues with `jvm.config` (spaces, quotes, EOL, ...) in terms of parsing so wonder if we shouldn't revisit it anyway. I had in mind a small native binary (either using graalvm without http and all the options making it fat or whatever is fast to launch) which could handle it to actually fork (unix)/trigger the real execution but, IMHO, it must belong to maven and not any enclosing tooling otherwise it is not part of maven and lost easily in any integration which must mimic our fragile script. That looks like `mvnd` but without keeping daemons alive... -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1475391796 > I'd be to make it public but also not controlled by scripts to always be accurate. Fwiw, that will mean that the computation needs to be duplicated somehow, so that the maven launch script can locate the `.mvn/jvm.config` file and read it before starting the JVM... -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1475052848 > I'd be to make it public but also not controlled by scripts to always be accurate. I have no problem with that.The point is to have a proper definition and thus computation for it. Having a `.mvn` directory gives a clear and simple definition and computation. Not having it may lead to go outside the source tree (if the project is part of a bigger project) or unable to be detected (in which case the `multiModuleProjectDirectory` defaults to the current dir). -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1474986407 > @gnodet guess worse case we can do 2 passes since parent/child relationship does not support interpolation properly anyway by design. Point is that the .mvn requirement is high for a so often needed prop so 1. I'd live to not have it (technically it is cleaner too even if .mvn does not prevent to "stop bubbling") and 2. if kept like that it must be named mvn.mvn.rootdir and be made it obvious it must not be used in parent poms, boms and plugins probably (indeed i hope we avoid that since tech we dont need .mvn presence in 99% of the cases). The goal is to make have a public property that can be used, not to hide it. We already have the hidden `multiModuleProjectDirectory` which is hidden. What's the point of having it hidden ? -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1474976612 > @gnodet sharing the use case, just adding that rootdir must not require .mvn dir presence as a marker so must use the pom hierarchy and take the highest parent, was just detailling a bit the impl idea. I think that would require another property, I'm all for defining additional properties. But a property based on parent/child relationship would be made available after projects are built, so it would not be able to be used during interpolation imho. -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1474972026 > Think rootdir must be the first module of the hierarchy (child to parent order) without a parent in the same relativepath (not null) or parent dir and listing the child. Would be bad to require .mvn presence imho. The main use case for the `rootdir` is for build related files location, for example, locate files shared throughout the build. This is currently a bit difficult to use. I have not seen any real use case for the parent/child relationship. > For me topdir is useless since we already have it somehow . We do, it's called `executionRootDir`. -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1474752190 > Before we agree on new names, we need to agree what these properties should contain and the expectations/requirements from users. @michael-o so I propose the following: * `topdir` : _the directory of the top-most project being built_, this is usually the current directory, or the one pointed by the `-f`/`--file` option * `rootdir` : _the parent directory containing a child `.mvn` directory_. If there's no such directory, print a warning and use a `topdir` This needs to be clarified when using `-pl`/`-am`/`-amd` options. -- 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
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introducing project.topdir
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1474103158 > Do these three properties represent the same value? I suppose you're talking about `topdir`, `project.topdir` and `session.topdir` ? They are aliases, but I don't think the `project.topdir` is a good idea, since it's not really a project attribute. I'm still thinking about renaming the new property to `rootdir`, and introduce a `topdir` for the execution directory in a consistent way. And deprecate `MavenSession.getExecutionRootDirectory()`, `MavenExecutionRequest.getBasedir()`, `MavenExecutionRequest.getMultiModuleProjectDirectory()` accordingly. I'm open to any naming, but things are a bit inconsistent, so I'd rather fix 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-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
