[JS2-1334] unpack overwrite rule not being honoured

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.3.0
• Fix Version/s: 2.3.1
• Component/s: Other
• Assignee: David Sean Taylor
• Reporter: Graham
• Created: 12/Aug/15 15:21
• Updated: 03/May/16 04:29
• Resolved: 03/May/16 04:29

Description

The Jetspeed unpack plugin notes taken from https://portals.apache.org/jetspeed-2/buildguide/jetspeed-unpack-plugin.html describe the 'overwrite' rule as :-

"When a selected resource from the resource archive already exists in its target directory, the overwrite setting will determine if the existing resource is overwritten, even if it has a more recent timestamp than the archived resource.
Note: if the archived resource has a more recent timestamp the existing resource will always be overwritten."

but even though we have specified <overwrite>true</overwrite> we still see the message

"xxxx skipped: already exists at xxxxx"

Looking at src/main/java/org/apache/jetspeed/maven/utils/UnpackResources.java (line 433) it looks like it will still skip if the destintation filename timestamp is >= the source filename timestamp regardless of the overwrite flag being set.

 if ( destFile.lastModified() >= fileEntry.getTime() || !unpackResources[i].isOverwrite() )
                                {
                                    if (verbose) {
                                        log.info(fileEntry.getName()+" skipped: already exists at "+destFile.getAbsolutePath());
                                    }
                                    else{
                                        log.debug(fileEntry.getName()+" skipped: already exists at "+destFile.getAbsolutePath());
                                    }
                                    continue;
                                }

Is this intentional or is it a bug? I thought setting overwrite to true would always overwrite it regardless of the timestamp as the documentation says it will be overwritten even if it has a more recent timestamp than the archived resource.