[JBoss JIRA] (JBIDE-13417) Maven plugin org.jboss.tools.tycho-plugins:repository-utils fails to update p2repository archive in full jbosstools build
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13417?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-13417.
---------------------------------
Closing.
> Maven plugin org.jboss.tools.tycho-plugins:repository-utils fails to update p2repository archive in full jbosstools build
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13417
> URL: https://issues.jboss.org/browse/JBIDE-13417
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Reporter: Denis Golovin
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> Noticed that base/site build fails with error during the full jbosstools build with error below, but it is fine for component build. The problem is that jbosstools-maven-plugins module is not using jbosstools/parent and thus using tycho version 0.15.0 which is defined in jbosstools-maven-plugins/pom.xml After setting it to the same version as in jbosstools/parent/pom.xml problem is gone.
> {code}[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.0.1-SNAPSHOT:generate-repository-facade (generate-facade) on project server.site: Execution generate-facade of goal org.jboss.tools.tycho-plugins:repository-utils:0.0.1-SNAPSHOT:generate-repository-facade failed: A required class was missing while executing org.jboss.tools.tycho-plugins:repository-utils:0.0.1-SNAPSHOT:generate-repository-facade: org/jboss/tools/tycho/sitegenerator/GenerateRepositoryFacadeMojo$2
> [ERROR] -----------------------------------------------------
> [ERROR] realm = plugin>org.jboss.tools.tycho-plugins:repository-utils:0.0.1-SNAPSHOT
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/jboss/tools/tycho-plugins/repository-utils/0.0.1-SNAPSHOT/repository-utils-0.0.1-SNAPSHOT.jar
> [ERROR] urls[1] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[2] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> [ERROR] urls[3] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> [ERROR] urls[4] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/eclipse/tycho/tycho-packaging-plugin/0.15.0/tycho-packaging-plugin-0.15.0.jar
> [ERROR] urls[5] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> [ERROR] urls[6] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> [ERROR] urls[7] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[8] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[9] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/codehaus/plexus/plexus-utils/2.0.4/plexus-utils-2.0.4.jar
> [ERROR] urls[10] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/apache/maven/maven-archiver/2.4/maven-archiver-2.4.jar
> [ERROR] urls[11] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/codehaus/plexus/plexus-archiver/1.2/plexus-archiver-1.2.jar
> [ERROR] urls[12] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/org/codehaus/plexus/plexus-io/1.0.1/plexus-io-1.0.1.jar
> [ERROR] urls[13] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/net/sf/saxon/saxon/8.7/saxon-8.7.jar
> [ERROR] urls[14] = file:/home/eskimo/Projects/jbds/jbosstools-fork-submodules/../.m2/jbosstools-fork-submodules-maximum1/master/net/sf/saxon/saxon-dom/8.7/saxon-dom-8.7.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm ClassRealm[project>org.jboss.tools:base:4.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> [ERROR]
> [ERROR] -----------------------------------------------------: org.jboss.tools.tycho.sitegenerator.GenerateRepositoryFacadeMojo$2
> {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
13 years
[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-13817:
-------------------------------
Description:
The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site.
[0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
There is also this file [2] produced by this job [3], which might make things easier:
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
[3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
was:
The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built).
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
There is also this file [2] produced by this job [3], which might make things easier:
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
[3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
> aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13817
> URL: https://issues.jboss.org/browse/JBIDE-13817
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha2
>
>
> The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site.
> [0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
> The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
> * reads the upstream composite site [1], and
> ** for each child site listed,
> *** downloads a zip matching the last CI build for that project
> **** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
> Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
> There is also this file [2] produced by this job [3], which might make things easier:
> [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
> [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
--
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
13 years
[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-13817:
-------------------------------
Description:
The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site.
[0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
There is also this file [2] produced by this job [3], which might make things easier:
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
[3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
was:
The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site.
[0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
There is also this file [2] produced by this job [3], which might make things easier:
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
[3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
> aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13817
> URL: https://issues.jboss.org/browse/JBIDE-13817
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha2
>
>
> The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site.
> [0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
> The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
> * reads the upstream composite site [1], and
> ** for each child site listed,
> *** downloads a zip matching the last CI build for that project
> **** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
> Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
> There is also this file [2] produced by this job [3], which might make things easier:
> [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
> [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
--
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
13 years
[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-13817:
-------------------------------
Description:
The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built).
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
There is also this file [2] produced by this job [3], which might make things easier:
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
[3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
was:
The old way to pull zips is with build-sites/aggregate/build.xml. It is an incomplete solution.
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
> aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13817
> URL: https://issues.jboss.org/browse/JBIDE-13817
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha2
>
>
> The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built).
> The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
> * reads the upstream composite site [1], and
> ** for each child site listed,
> *** downloads a zip matching the last CI build for that project
> **** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
> Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/,
> There is also this file [2] produced by this job [3], which might make things easier:
> [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
> [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
--
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
13 years
[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-13817:
----------------------------------
Summary: aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site
Key: JBIDE-13817
URL: https://issues.jboss.org/browse/JBIDE-13817
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Build/Releng, updatesite
Affects Versions: 4.1.0.Alpha1
Reporter: Nick Boldt
Assignee: Mickael Istria
Fix For: 4.1.0.Alpha2
The old way to pull zips is with build-sites/aggregate/build.xml. It is an incomplete solution.
The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which:
* reads the upstream composite site [1], and
** for each child site listed,
*** downloads a zip matching the last CI build for that project
**** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report.
Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found.
--
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
13 years
[JBoss JIRA] (JBIDE-13346) DirectoryScanner fails on non-existing folders
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13346?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-13346.
---------------------------------
Already verified - closing again.
> 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
13 years
[JBoss JIRA] (JBIDE-13271) BrowserSim: simulator is closing unexpectedly while changing skin
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13271?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov commented on JBIDE-13271:
------------------------------------------------
[~vpakan], you close JBIDE-13480, which is the same as this issue, but for 4.0.1. Does it mean that this issue also can be closed?
> BrowserSim: simulator is closing unexpectedly while changing skin
> -----------------------------------------------------------------
>
> Key: JBIDE-13271
> URL: https://issues.jboss.org/browse/JBIDE-13271
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Visual Page Editor core
> Affects Versions: 4.0.0.CR1
> Environment: Windows 7
> Reporter: Yahor Radtsevich
> Assignee: Konstantin Marmalyukov
> Priority: Critical
> Fix For: 4.1.0.Alpha2
>
>
> On some web pages BrowserSim is closing with the following stack trace while changing skin (see steps to reproduce):
> {code}
> Exception in thread "main" org.eclipse.swt.SWTException: Widget is disposed
> at org.eclipse.swt.SWT.error(SWT.java:4361)
> at org.eclipse.swt.SWT.error(SWT.java:4276)
> at org.eclipse.swt.SWT.error(SWT.java:4247)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:468)
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:340)
> at org.eclipse.swt.widgets.Control.setVisible(Control.java:3725)
> at org.jboss.tools.vpe.browsersim.ui.skin.ios.AppleIPhone3ResizableSkin.
> progressChanged(AppleIPhone3ResizableSkin.java:247)
> at org.jboss.tools.vpe.browsersim.ui.BrowserSim$3.changed(BrowserSim.jav
> a:251)
> at org.eclipse.swt.browser.WebResourceLoadDelegate.identifierForInitialR
> equest(WebResourceLoadDelegate.java:225)
> at org.eclipse.swt.browser.WebResourceLoadDelegate$1.method3(WebResource
> LoadDelegate.java:45)
> at org.eclipse.swt.internal.ole.win32.COMObject.callback3(COMObject.java
> :92)
> at org.eclipse.swt.internal.win32.OS.SetFocus(Native Method)
> at org.eclipse.swt.browser.WebKit$4.handleEvent(WebKit.java:650)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058)
> at org.eclipse.swt.widgets.Control.sendFocusEvent(Control.java:2822)
> at org.eclipse.swt.widgets.Widget.wmSetFocus(Widget.java:2417)
> at org.eclipse.swt.widgets.Control.WM_SETFOCUS(Control.java:5152)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:4598)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
> at org.eclipse.swt.internal.win32.OS.VtblCall(Native Method)
> at org.eclipse.swt.internal.webkit.IWebView.setHostWindow(IWebView.java:
> 76)
> at org.eclipse.swt.browser.WebKit.onDispose(WebKit.java:1064)
> at org.eclipse.swt.browser.WebKit$4.handleEvent(WebKit.java:646)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058)
> at org.eclipse.swt.widgets.Widget.release(Widget.java:808)
> at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:873)
> at org.eclipse.swt.widgets.Widget.release(Widget.java:811)
> at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:873)
> at org.eclipse.swt.widgets.Widget.release(Widget.java:811)
> at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:873)
> at org.eclipse.swt.widgets.Widget.release(Widget.java:811)
> at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:873)
> at org.eclipse.swt.widgets.Widget.release(Widget.java:811)
> at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:873)
> at org.eclipse.swt.widgets.Canvas.releaseChildren(Canvas.java:167)
> at org.eclipse.swt.widgets.Decorations.releaseChildren(Decorations.java:
> 790)
> at org.eclipse.swt.widgets.Shell.releaseChildren(Shell.java:1290)
> at org.eclipse.swt.widgets.Widget.release(Widget.java:811)
> at org.eclipse.swt.widgets.Widget.dispose(Widget.java:446)
> at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:448)
> at org.eclipse.swt.widgets.Shell.dispose(Shell.java:715)
> at org.jboss.tools.vpe.browsersim.ui.BrowserSim.setSelectedDevice(Browse
> rSim.java:673)
> at org.jboss.tools.vpe.browsersim.ui.BrowserSim$11$1.update(BrowserSim.j
> ava:433)
> at java.util.Observable.notifyObservers(Unknown Source)
> at java.util.Observable.notifyObservers(Unknown Source)
> at org.jboss.tools.vpe.browsersim.ui.BrowserSim$22.widgetSelected(Browse
> rSim.java:651)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:
> 248)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
> at org.jboss.tools.vpe.browsersim.ui.BrowserSim.main(BrowserSim.java:156
> )
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.swtjar.SWTLoader.main(SWTLoader.java:38)
> {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
13 years