Re: module naming syntax
On 2019-05-14, Glenn Burkhardt wrote: >module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade"> > > > > > Running 'ant' in verbose mode, it shows that the argument "-m > com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java > program. I think what happens here is CommandlineJava#setModule is called with executableType being null and thus Commandline#setExecutable is called without the second argument which would prevent slash translation. >From the top of my head I don't recall why we have a case for executableType being null here at all rather than switching to module mode immediately and processing the argument after that. There must be a reason for that but figuring things out requires a bit more thought. On second thought from looking at the code the java task seems to expect you'd use
Re: module naming syntax
Windows 10, Ant 1.10.6 On 5/14/2019 1:27 AM, Jaikiran Pai wrote: Hello Glenn, I don't expect the module name's front slash to be replaced with a file separator. I haven't checked the code yet. I'll take a look later today. What operating system are you on and which exact version of Ant are you using? -Jaikiran On 14/05/19 6:07 AM, Glenn Burkhardt wrote: I'm puzzled about which utility should be more flexible about the module naming convention. With Java 11 from OpenJDK, I notice that java --module-path=jaxb-ri/mod -m com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade -d out -p generated Schema_Specification.xsd works as desired, but java --module-path=jaxb-ri/mod -m com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade -d out -p generated.armisxml Schema_Specification.xsd does not (only difference is the use of '\' and '/' in the module name). When one tries to use a Java task in 'ant', it translates the forward slash to a backward slash, e.g., Running 'ant' in verbose mode, it shows that the argument "-m com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java program. So, which program should be more flexible? I haven't found a specification of what the module name specification should be. But the OpenJDK Java program requires that a forward slash be used. Should 'ant' not translate the forward slash into a backslash? Or should the OpenJDK Java program accept either one? - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org
Re: module naming syntax
The question is about the module attribute (which gets translated into a "-m" argument for 'java'), not the modulepath. [java] Executing 'C:\Program Files\AdoptOpenJDK\jdk-11.0.3.7-openj9\bin\java.exe' with arguments: [java] '--module-path' [java] 'C:\Users\glenn\Documents\utc\jaxb\jaxb-ri\mod' [java] '-m' [java] 'com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade' [java] '-d out' [java] '-p generated' [java] 'Schema_Specification.xsd' [java] [java] The ' characters around the executable and arguments are [java] not part of the command. [java] java.lang.module.FindException: Module com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade not found On 5/14/2019 2:25 AM, Jaikiran Pai wrote: On 14/05/19 11:48 AM, Stefan Bodewig wrote: On 2019-05-14, Jaikiran Pai wrote: I don't expect the module name's front slash to be replaced with a file separator. Ant does, I'm pretty sure. The type of 's modulepath is an Ant Path and as such each entry is treated as a file name and the usual file separator suspects are mapped to their OS specific versions. From what I understood of Glenn's mail, I thought he was talking about the "module" attribute which is a name, unlike the modulepath, which as you rightly note is a "path". As far as I understand of the java command line, the -m option which specifies the module[/mainclassname] should be taken literally without any file separator conversions. So before we (Ant) pass off that module name to java command, IMO, we shouldn't do the conversion. -Jaikiran - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org
Re: module naming syntax
On 5/14/2019 3:01 AM, Stefan Bodewig wrote: On 2019-05-14, Glenn Burkhardt wrote: Running 'ant' in verbose mode, it shows that the argument "-m com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java program. I think what happens here is CommandlineJava#setModule is called with executableType being null and thus Commandline#setExecutable is called without the second argument which would prevent slash translation. From the top of my head I don't recall why we have a case for executableType being null here at all rather than switching to module mode immediately and processing the argument after that. There must be a reason for that but figuring things out requires a bit more thought. On second thought from looking at the code the java task seems to expect you'd use works. - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org
Re: module naming syntax
On 14/05/19 12:31 PM, Stefan Bodewig wrote:
> On 2019-05-14, Glenn Burkhardt wrote:
>
>> > module="com.sun.tools.xjc/com.sun.tools.xjc.XJCFacade">
>>
>>
>>
>>
>> Running 'ant' in verbose mode, it shows that the argument "-m
>> com.sun.tools.xjc\com.sun.tools.xjc.XJCFacade" is passed to the Java
>> program.
> I think what happens here is CommandlineJava#setModule is called with
> executableType being null and thus Commandline#setExecutable is called
> without the second argument which would prevent slash translation.
>
> From the top of my head I don't recall why we have a case for
> executableType being null here at all rather than switching to module
> mode immediately and processing the argument after that. There must be a
> reason for that but figuring things out requires a bit more thought.
>
Now that Glenn seems to have got past the issue by following the
workaround suggested, do you think we should fix this code, to handle
the case where the module name could have a slash character. I think the
fix could be as simple as:
diff --git a/src/main/org/apache/tools/ant/types/CommandlineJava.java
b/src/main/org/apache/tools/ant/types/CommandlineJava.java
index 876675332..9f9b444e7 100644
--- a/src/main/org/apache/tools/ant/types/CommandlineJava.java
+++ b/src/main/org/apache/tools/ant/types/CommandlineJava.java
@@ -397,7 +397,7 @@ public class CommandlineJava implements Cloneable {
*/
public void setModule(final String module) {
if (executableType == null) {
- javaCommand.setExecutable(module);
+ javaCommand.setExecutable(module, false);
} else {
switch (executableType) {
case JAR:
(of course with test cases added for this specific case).
Just like you, I'm not fully sure why that executableType == null check
is there. Maybe that whole if/else block along with the switch is trying
to take into account the case of attribute order parsing (for example,
the "classname" attribute having been parsed before the "module"
attribute because that's how the user used it?) while reading the
"" element?
-Jaikiran
-
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
