[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-3050) Project Archives freezes with large includes

[Rob Stryker (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBIDE-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455851#action_12455851 ] 

Rob Stryker commented on JBIDE-3050:
------------------------------------

1) UI wise, there has been no change for screenshots or anything that might affect docs.  Functionality wise, the "preview" will only show the first 30 results. I know this is relatively arbitrary and non-configurable, and I expect future JIRA issues requesting either a workspace preference or a preference in some dialogs to show full results. I didn't want that in there right away, though. 

If you think this is stupid, I expect to hear about it ;)

2) Honestly, I've been moving the Directory Scanner from a tiny fork of the apache version into its own thing. The changes now are large enough that really to try to keep it the same is silly.  The class no longer implements the ant interfaces it implemented before. This made it acceptable to remove those methods if they didn't apply to how I was using the class.  So not only comments, but also entire methods.

Often times the methods had changed so much that the doc / comments were innacurate. 

3) As I said before, I was trying to slim the class down to its core use. My archives descriptor didn't have any way to set following sym links or not and since those methods were unused, I removed them. Following symlinks is now by default (it always was actually. There was no way to turn it off. Now I just removed it from "a variable that always evaluated to true" to just "true".) 

This also allowed me to simplify several of the methods that required separate logic. 

4) The point of the test is to make sure that in the end, the sizes are the same. You don't need to test if it actually "stops" because the way to "stop" it is to not ask for the "next". Essentially, if you're using an iterator, it only scans one folder and doesn't recurse. Instead, it adds all subfolders to a list of folders that can be scanned on the next hasNext() call.   

A call to hasNext() will either return the next file in the queue that's already been scanned, or if there's no files left but still folders to scan, it will scan the next folder (non-recurse) to see if there are any matches there. If not, the next folder, etc.  Can you point me to an ArrayList test that checks to see if the iterator can be "stopped"? No. The proper method of stopping an iterator is... to stop iterating ;) 

5) Nothing's wrong with enums or long. I use doubles for the same reason I had eggplant for dinner last night. It seemed like a good idea at the time and there didn't seem to be anything horribly wrong about it.  Also, that's not in scope for this bug.

6) Great idea. Not right now. But great idea. 

> Project Archives freezes with large includes
> --------------------------------------------
>
>                 Key: JBIDE-3050
>                 URL: https://jira.jboss.org/jira/browse/JBIDE-3050
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: Archives
>    Affects Versions: 3.0.0.beta1
>            Reporter: Max Rydahl Andersen
>            Assignee: Rob Stryker
>            Priority: Critical
>             Fix For: 3.1.0
>
>
> It looks like everything is copied/calculated in bulk and not incrementally
> Try using fileset with / as the root and do a **/*.pdf or similar many hit pattern.
> The Preview Table does not show it is actually working
> When it returns there is a risk for outof memory since it is fetching *all* matching files instead of just a subset(preview)
> When pressing finish the dialog just freezes waiting for the packaging to finish - why is that not done in a background job ?
> During this i always end up getting an outofmemory exception ... 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira