[
https://issues.jboss.org/browse/JBIDE-7333?page=com.atlassian.jira.plugin...
]
Rob Stryker commented on JBIDE-7333:
------------------------------------
The huge increase in times seems to be caused by updateTimestamp, a method written on our
end. This is meant to register a particular timestamp for each resource, and also for the
folders above it, for example, if you copy in bin/some/folder/My.class, it should update
the timestamp of My.class, folder, some, and bin, such that each folder has an accurate
representation of the last time that resource was modified.
This is important for incremental builds, where a change in one file will want to change
the overall timestamp of the archive and parent folders, but on a full build, the
difference in timestamp is extremely minimal. If you have a folder 10 levels deep
(org/my/package/name/is/really/long) and that folder has 300 class files, that means each
build will have 300*10 calls to change resource timestamps, which seems to be a
significant cause of delay.
I'll see if I can get a patch in for this long-standing issue.
Build project archive is slow
-----------------------------
Key: JBIDE-7333
URL:
https://issues.jboss.org/browse/JBIDE-7333
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Archives
Environment: Windows 2003 x64
Helios SR1
Java 1.6
JBoss Archives Tools 3.2.0.v20101013-0144-H81-Beta2
Reporter: Krasimir Goutcev
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.x
Attachments: diffout
This operation takes me more than 7 min .
WAR is 7MB
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira