Hello, If I understood it correctly the modules on the MP must be unique and are not merged, thats why the order inside the directory does not matter for the named modules.
Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Robert Scholte <rfscho...@apache.org> To: jigsaw-dev@openjdk.java.net Cc: Maven Developers List <d...@maven.apache.org> Sent: Do., 14 Jan. 2016 21:14 Subject: Re: Specifying module paths Hi, on the maven-dev list I've received a couple of responses. The following comments are worth mentioning: Igor Fedorenko says: "This is a very good proposal. My only suggestion is to extend javax.tools CompilationTask API to take modulepath map as in-memory parameter. Not a big deal, but it'll be silly to write properties file to disk for it to be immediately read by the code executed in the same jvm." I agree with Igor on the in-memory option: JDK-8144665 is first of all initiated as a request to have a more effective way to handle modules *for build-tools*. Paul Benedict says: "It sounds like Maven will have to generate many .properties file in a build. 1) Modules to compile main source 2) Modules to compile test source 3) Modules to execute tests 4) And what about forking? I am concerned #4 is going to create issues unless the .properties file name is unique enough. Perhaps it can be based on process id." I haven't had a look at surefire (framework for executing tests) yet, so we still need to analyze the impact for it. What Tibor Digana told me is that it leans on the Classpath element of the MANIFEST file. My remarks: There are 2 things important to me: a. reference must result in a single file A Maven Artifact coordinate refers to exactly one file. In the local repository the folder containing that artifact often contains other files as well and you cannot predict which files were intended to be added to the class/module path just by referring to that folder. A properties file would at least result in a 1:1 mapping from dependency to file. b. predictable order With the classpath it was the order of the cp-entries specified, and Maven calculated that order based the "distance" of that dependency in relation to the Java project, especially important with transitive dependencies. Based on what I read about JEP-261 and 'order' it is *not* the "requires X" from the module-info which decides the order. Just like the cp argument it is based on the mp argument. This is interesting, because what's the order of files within a folder? It depends on the OS [1]. bq. There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order. Reordering dependencies is a well known trick in case of class collisions. Regarding the extra file, I'm still not sure about it. To me it adds unnecessary complexity. We didn't ask for a replacement of the current behavior, just to *add* support for jars as -mp argument. For those who want to use the commandline, the can still refer to module folders. As for Maven (I cannot speak for other tools), we use the CompilerAPI, so commandline-length is not the issue. thanks, Robert Scholte [1] https://docs.oracle.com/javase/7/docs/api/java/io/File.html#list() --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
