[jbosstools-issues] [JBoss JIRA] (JBIDE-13346) DirectoryScanner fails on non-existing folders

[Michelle Murray (JIRA)]

     [ https://issues.jboss.org/browse/JBIDE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michelle Murray updated JBIDE-13346:
------------------------------------

    Release Notes Docs Status: Documented as Known Issue  (was: Not Yet Documented)
                       Writer: mmurray
           Release Notes Text: Deployment Assembly is used to control which files should be deployed with an application to the runtime server and it can be accessed via the Properties of a project. Previously, if Deployment Assembly contained information about nonexistent directories, error messages were generated when the project was built. These error messages were noncritical and did not have an impact on the project's build success. Server Tools has been amended so that it no longer logs the noncritical error messages for nonexistent directories and, consequently, these error messages do not appear in error logs of project builds.  (was: Cause:  If the Deployment assembly preference for projects referenced directories that does not exist an error was unnecessarily logged as an error with a full stack trace. 

Consequence: A user having a project where not all directories are present during the build cycle could see this error and think it was a bug even when it has no impact on his project. 

Fix:  Server tools do no longer log the error, as it is not a critical error. 

Result: There are no more logging of this special case and users should not get a long list of these errors on every build cycle.)

    
> DirectoryScanner fails on non-existing folders
> ----------------------------------------------
>
>                 Key: JBIDE-13346
>                 URL: https://issues.jboss.org/browse/JBIDE-13346
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: Archives, JBossAS/Servers
>    Affects Versions: 4.0.0.Final
>         Environment: Windows XP/Windows 7
> Eclipse 4.3M4
>            Reporter: Jesper Skov
>            Assignee: Rob Stryker
>            Priority: Minor
>             Fix For: 4.0.1.Final, 4.1.0.Alpha1
>
>         Attachments: org.eclipse.wst.common.component
>
>
> DirectoryScanner can be made to fail on non-existing folders.
> In our setup, these folders are possibly picked up from the Deployment Assembly settings.
> The folders are created by our custom Builder with highest priority, so appears to work properly with everything else in Eclipse.
> But it seems the Archive DirectoryScanner runs before our builder.
> The stack trace looks like this:
>  
> {code}
> java.lang.IllegalStateException: basedir C:\udvikler\ws\plugins\jb.it.reuters\build\gen-lib-deployable is not a directory
>     at org.jboss.ide.eclipse.archives.core.asf.DirectoryScanner.scanPrepare(DirectoryScanner.java:552)
>     at org.jboss.ide.eclipse.archives.core.asf.DirectoryScanner.scan(DirectoryScanner.java:588)
>     at org.jboss.ide.eclipse.archives.core.model.DirectoryScannerFactory.createDirectoryScanner(DirectoryScannerFactory.java:66)
>     at org.jboss.ide.eclipse.archives.webtools.filesets.vcf.WorkspaceFilesetVirtualComponent$WorkspaceFilter.<init>(WorkspaceFilesetVirtualComponent.java:100)
>     at org.jboss.ide.eclipse.archives.webtools.filesets.vcf.WorkspaceFilesetVirtualComponent.getRootFolder(WorkspaceFilesetVirtualComponent.java:53)
>     at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.consumeComponent(FlatVirtualComponent.java:203)
>     at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.addConsumedReferences(FlatVirtualComponent.java:196)
>     at org.eclipse.jst.j2ee.internal.common.ClasspathLibraryExpander.optimize(ClasspathLibraryExpander.java:47)
>     at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.cacheResources(FlatVirtualComponent.java:119)
>     at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.fetchResources(FlatVirtualComponent.java:101)
>     at org.eclipse.jst.j2ee.internal.common.ClasspathLibraryExpander.fetchResource(ClasspathLibraryExpander.java:74)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.getBaseEARLibRefs(J2EEComponentClasspathContainer.java:463)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.requiresUpdate(J2EEComponentClasspathContainer.java:208)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.refresh(J2EEComponentClasspathContainer.java:540)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$ModuleUpdateJob.processModules(J2EEComponentClasspathUpdater.java:311)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$ModuleUpdateJob.access$4(J2EEComponentClasspathUpdater.java:295)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$ModuleUpdateJob$1.run(J2EEComponentClasspathUpdater.java:336)
>     at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
>     at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$ModuleUpdateJob.run(J2EEComponentClasspathUpdater.java:321)
>     at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira