[ https://issues.jboss.org/browse/JBDS-3532?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3532: ---------------------------------- If it's the deploy step that's causing a rebuild, then we could return to deploying in Jenkins by calling rsync.sh directly, rather than wrapping that w/ a profile in a pom. But I'm not sure that's the cause here. The other reason we might be seeing two different timestamps is that in the Jenkins job, we rebuild the update site zip so that it excludes the packed artifacts, in order to make the zip smaller. (This is because when you're using the live (unpacked) update site, pack.gz artifacts are approx 40% smaller and therefore faster to download; but if you have the time to download the whole zip, you won't ever use BOTH the packed and unpacked jars from the update site archive. So including both sets of artifacts just eats disk and wastes users' time.) A better solution to "just rebuild it without the -Ppack200 profile" would be to find a way to have tycho EXCLUDE the unpacked plugins and keep only the pack.gz ones. Then both the update site and zip can be the same, and both will also be smaller & more efficient. The need for both sets of artifacts (pack200'd and unpacked) went away when everyone moved from Java 5 to 6, but the tools for building update sites (AFAIK) never got an update to allow a site w/ ONLY packed artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)