DO NOT REPLY [Bug 23725] New: - In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension.

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23725>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23725

In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension.

           Summary: In offline generation mode, when I start Cocoon with a
                    Uris list file, the argument confirm extensions (-e) is
                    not used, and the created files are forced with the
                    default mime type extension.
           Product: Cocoon 2
           Version: 2.1.2
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: core
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: vincent.arbousset@keyword.fr


In offline generation mode, when I start Cocoon with a Uris list file, the 
argument confirm extensions (-e) is not used, and the created files are forced 
with the default mime type extension.
Cause of the problem : URIs are parsed during analysis of the –f argument, and 
this argument is analysed before the confirm extensions argument (-e). The 
consequence is that the confirm extensions is not taken into account. This 
occur in the main method of the ora.apache.cocoon.Main class. 
See the code below :
        if (line.hasOption(URI_FILE_OPT)) {
            // URIs file is parsed
            cocoon.addTargets(processURIFile(line.getOptionValue
(URI_FILE_OPT)), destDir);
        }
        if (line.hasOption(FOLLOW_LINKS_OPT)) {
            cocoon.setFollowLinks(yesno(line.getOptionValue(FOLLOW_LINKS_OPT)));
        }
        if (line.hasOption(CONFIRM_EXTENSIONS_OPT)) {
            // Confirm extensions property is set
            cocoon.setConfirmExtensions(yesno(line.getOptionValue
(CONFIRM_EXTENSIONS_OPT, "yes")));
        }
        if (line.hasOption(LOAD_CLASS_OPT)){
            cocoon.addLoadedClasses(Arrays.asList(line.getOptionValues
(LOAD_CLASS_OPT)));
        }

        cocoon.addTargets(line.getArgList(), destDir);

 The following changes correct the problem :
        if (line.hasOption(FOLLOW_LINKS_OPT)) {
            cocoon.setFollowLinks(yesno(line.getOptionValue(FOLLOW_LINKS_OPT)));
        }
        if (line.hasOption(CONFIRM_EXTENSIONS_OPT)) {
            // Confirm extensions property is set
            cocoon.setConfirmExtensions(yesno(line.getOptionValue
(CONFIRM_EXTENSIONS_OPT, "yes")));
        }
        if (line.hasOption(LOAD_CLASS_OPT)){
            cocoon.addLoadedClasses(Arrays.asList(line.getOptionValues
(LOAD_CLASS_OPT)));
        }
        if (line.hasOption(URI_FILE_OPT)) {
            // URIs file is parsed when all arguments have been analysed
            cocoon.addTargets(processURIFile(line.getOptionValue
(URI_FILE_OPT)), destDir);
        }

Vincent.