-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[MNG-8713] SourceRoot.directory() default value should include the module when present #2278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,11 +37,26 @@ public interface SourceRoot { | |
* The path is relative to the <abbr>POM</abbr> file. | ||
* | ||
* <h4>Default implementation</h4> | ||
* The default value is <code>src/{@linkplain #scope() scope}/{@linkplain #language() language}</code> | ||
* as a relative path. Implementation classes may override this default with an absolute path instead. | ||
* The default value depends on whether a {@linkplain #module() module name} is specified in this source root: | ||
* <ul> | ||
* <li> | ||
* If no module name, then the default directory is | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. shifting from main/java to java/main feels like a really big change. Is there a very compelling reason to do this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reminder: this pull request does not change the convention of non-modular projects or projects that do not use the module source hierarchy: for them, the default stay The reason for putting The reason for putting There is precedents: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That makes sense to me. @elharo ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not convinced. That feels very wrong to me, and I expect users will be unnecessarily confused. What we've had in the past is src/main/java/package-structure and the natural extension of that is src/main/java/module/package-structure If other languages come into play (which I really don't think will happen or is something we need to worry about) then src/main/python/module or whatever Changing anything to src/java/main introduces inconsistency we don't have now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure that's the right angle to look at. If a given project has multiple modules, those modules kinda act as subprojects, so it makes sense to group their files together, rather than splitting main / tests. In that case, each test directory is testing the code of the module, so having them close to each other makes more sense to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed, the rational is as Guillaume said. While we try to avoid disruption for users who are not interested in JPMS, those who want to embrace fully JPMS will have to change some habits anyway, some of them out of our control (e.g., the directory layout of There is a difficulty with resources, which are considered as a language and therefore would be stored apart with a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This layout is closer to the usual maven layout and may be less disruptive. It just adds the module before the scope. I like it better actually. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The inconvenient of the alternative proposal is that if a subproject has two or more languages, the modules of different languages will be mixed in the same directory. However, it may not be important if, as suggested in other comments, we choose to not let the multi-languages issue influences the decision. Note: this difficulty come from the fact that in the current non-modular layout, If there is no objection or alternative proposal, I will change the layout to |
||
* <code>src/{@linkplain #scope() scope}/{@linkplain #language() language}</code>. | ||
* </li><li> | ||
* If a module name is present, then the default directory is | ||
* <code>src/{@linkplain #module() module}/{@linkplain #scope() scope}/{@linkplain #language() language}</code>. | ||
* </li> | ||
* </ul> | ||
* | ||
* The default value is relative. | ||
* Implementation may override with absolute path instead. | ||
*/ | ||
default Path directory() { | ||
return Path.of("src", scope().id(), language().id()); | ||
Path src = Path.of("src"); | ||
return module().map(src::resolve) | ||
.orElse(src) | ||
.resolve(scope().id()) | ||
.resolve(language().id()); | ||
} | ||
|
||
/** | ||
|
Uh oh!
There was an error while loading. Please reload this page.