[JBoss JIRA] (JBIDE-19506) Connection wizard, Connection: should have unit tests
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19506?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-19506:
------------------------------------------
Connection is now fully covered. Still need more tests for ConnectionWizardPageModel. Moving to sprint #117
> Connection wizard, Connection: should have unit tests
> ------------------------------------------------------
>
> Key: JBIDE-19506
> URL: https://issues.jboss.org/browse/JBIDE-19506
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, tests
> Fix For: 4.4.x
>
> Original Estimate: 2 days
> Time Spent: 3 days
> Remaining Estimate: 3 days
>
> In the new implementation of the connection wizard, that allows v2 and v3 connections (JBIDE-19096) we have rather complex behaviour that we should assert via unit tests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-19506) Connection wizard, Connection: should have unit tests
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19506?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19506:
-------------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> Connection wizard, Connection: should have unit tests
> ------------------------------------------------------
>
> Key: JBIDE-19506
> URL: https://issues.jboss.org/browse/JBIDE-19506
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, tests
> Fix For: 4.4.x
>
> Original Estimate: 2 days
> Time Spent: 3 days
> Remaining Estimate: 3 days
>
> In the new implementation of the connection wizard, that allows v2 and v3 connections (JBIDE-19096) we have rather complex behaviour that we should assert via unit tests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ERT-53) Need to add Launch Configuration for grunt [EBZ#486233]
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/ERT-53?page=com.atlassian.jira.plugin.sys... ]
Ilya Buziuk resolved ERT-53.
----------------------------
Resolution: Done
> Need to add Launch Configuration for grunt [EBZ#486233]
> -------------------------------------------------------
>
> Key: ERT-53
> URL: https://issues.jboss.org/browse/ERT-53
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Max Rydahl Andersen
> Assignee: Angel Misevski
> Labels: 3.8_M6, General, bzira
> Fix For: Neon.1 (4.6)
>
> Original Estimate: 1 day, 7 hours
> Remaining Estimate: 1 day, 7 hours
>
> Grunt support should have not only Launch Shortcut but also a separate Lauch Configuration / Launch Config Type for task invocations. The main improvements are:
> - Ability to configure tasks
> - Tasks will be added to Launch Bar
> LC should be placed under org.eclipse.ui.externaltools the same as Ant
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ERT-52) Need to add Launch Configuration for gulp [EBZ#486232]
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/ERT-52?page=com.atlassian.jira.plugin.sys... ]
Ilya Buziuk resolved ERT-52.
----------------------------
Resolution: Done
> Need to add Launch Configuration for gulp [EBZ#486232]
> ------------------------------------------------------
>
> Key: ERT-52
> URL: https://issues.jboss.org/browse/ERT-52
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Max Rydahl Andersen
> Assignee: Angel Misevski
> Labels: 3.8_M6, General, bzira
> Fix For: Neon.1 (4.6)
>
> Original Estimate: 1 day, 7 hours
> Remaining Estimate: 1 day, 7 hours
>
> Gulp support should have not only Launch Shortcut but also a separate Lauch Configuration / Launch Config Type for task invocations. The main improvements are:
> - Ability to configure tasks
> - Tasks will be added to Launch Bar
> LC should be placed under org.eclipse.ui.externaltools the same as Ant
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22658) Infinite or very long hang in CDI builder with Payara embedded maven dep
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22658?page=com.atlassian.jira.plugi... ]
Alexey Kazakov edited comment on JBIDE-22658 at 7/1/16 3:52 PM:
----------------------------------------------------------------
BTW, you can try [nightly build|http://tools.jboss.org/downloads/jbosstools/neon/4.4.x.Nightly.html] if you don't want to wait for official update.
We are working on bringing 4.4.x nightly builds back. Hope the build which includes that fix will be ready soon.
Please let us know if it's still not fast enough.
was (Author: akazakov):
BTW, you can try http://tools.jboss.org/downloads/jbosstools/neon/4.4.x.Nightly.html[nightly build] if you don't want to wait for official update.
We are working on bringing 4.4.x nightly builds back. Hope the build which includes that fix will be ready soon.
Please let us know if it's still not fast enough.
> Infinite or very long hang in CDI builder with Payara embedded maven dep
> ------------------------------------------------------------------------
>
> Key: JBIDE-22658
> URL: https://issues.jboss.org/browse/JBIDE-22658
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Reporter: arjan tijms
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.1.AM1
>
>
> In the latest JBoss Tools for Eclipse Mars .2 (would be great if it was easy to see the main version easily, but I guess it's 4.3.1), the CDI builder either infinitely hangs or takes an enormous amount of time (an hour at least on a core M laptop) when payara embedded is present as (test) dependency in a maven project.
> During this hang I took a stack trace, which looks as follows:
> {noformat}
> "Worker-20" #96 prio=5 os_prio=31 tid=0x0000000101512000 nid=0x14803 runnable [0x0000700003fde000]
> java.lang.Thread.State: RUNNABLE
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.zip.ZipFile.<init>(ZipFile.java:163)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2678)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2644)
> at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:156)
> at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:355)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:290)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:284)
> at org.eclipse.jdt.internal.core.ClassFile.buildStructure(ClassFile.java:93)
> at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
> at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
> at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:579)
> at org.eclipse.jdt.internal.core.BinaryType.getElementInfo(BinaryType.java:287)
> at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:302)
> at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:220)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.process(ImplementationCollector.java:41)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.<init>(ImplementationCollector.java:32)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.rebuildBeans(CDIProject.java:1309)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.update(CDIProject.java:1216)
> - locked <0x000000078ecd93d8> (a org.jboss.tools.cdi.internal.core.impl.CDICache)
> at org.jboss.tools.cdi.internal.core.impl.definition.DefinitionContext.applyWorkingCopy(DefinitionContext.java:442)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:267)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
> I debugged Eclipse with a second Eclipse, and it appeared that the code is repeatedly opening {{.m2/repository/fish/payara/extras/payara-embedded-all/4.1.1.162/payara-embedded-all-4.1.1.162.jar}} from {{CDIProject#rebuildBeans}}.
> The specific line of code is:
> {code:java}
> ImplementationCollector ic = new ImplementationCollector(typeDefinitions);
> {code}
> The number of type definitions it seems to go through in {{ImplementationCollector#process}} is *33009* and the loop looks to be making progress, so it's more likely just incredibly slow and not an infinite hang.
> The dependency in pom.xml looks as follows:
> {code:xml}
> <dependency>
> <groupId>fish.payara.extras</groupId>
> <artifactId>payara-embedded-all</artifactId>
> <version>4.1.1.162</version>
> <scope>test</scope>
> </dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22658) Infinite or very long hang in CDI builder with Payara embedded maven dep
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22658?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-22658:
----------------------------------------
BTW, you can try http://tools.jboss.org/downloads/jbosstools/neon/4.4.x.Nightly.html[nightly build] if you don't want to wait for official update.
We are working on bringing 4.4.x nightly builds back. Hope the build which includes that fix will be ready soon.
Please let us know if it's still not fast enough.
> Infinite or very long hang in CDI builder with Payara embedded maven dep
> ------------------------------------------------------------------------
>
> Key: JBIDE-22658
> URL: https://issues.jboss.org/browse/JBIDE-22658
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Reporter: arjan tijms
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.1.AM1
>
>
> In the latest JBoss Tools for Eclipse Mars .2 (would be great if it was easy to see the main version easily, but I guess it's 4.3.1), the CDI builder either infinitely hangs or takes an enormous amount of time (an hour at least on a core M laptop) when payara embedded is present as (test) dependency in a maven project.
> During this hang I took a stack trace, which looks as follows:
> {noformat}
> "Worker-20" #96 prio=5 os_prio=31 tid=0x0000000101512000 nid=0x14803 runnable [0x0000700003fde000]
> java.lang.Thread.State: RUNNABLE
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.zip.ZipFile.<init>(ZipFile.java:163)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2678)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2644)
> at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:156)
> at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:355)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:290)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:284)
> at org.eclipse.jdt.internal.core.ClassFile.buildStructure(ClassFile.java:93)
> at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
> at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
> at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:579)
> at org.eclipse.jdt.internal.core.BinaryType.getElementInfo(BinaryType.java:287)
> at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:302)
> at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:220)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.process(ImplementationCollector.java:41)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.<init>(ImplementationCollector.java:32)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.rebuildBeans(CDIProject.java:1309)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.update(CDIProject.java:1216)
> - locked <0x000000078ecd93d8> (a org.jboss.tools.cdi.internal.core.impl.CDICache)
> at org.jboss.tools.cdi.internal.core.impl.definition.DefinitionContext.applyWorkingCopy(DefinitionContext.java:442)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:267)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
> I debugged Eclipse with a second Eclipse, and it appeared that the code is repeatedly opening {{.m2/repository/fish/payara/extras/payara-embedded-all/4.1.1.162/payara-embedded-all-4.1.1.162.jar}} from {{CDIProject#rebuildBeans}}.
> The specific line of code is:
> {code:java}
> ImplementationCollector ic = new ImplementationCollector(typeDefinitions);
> {code}
> The number of type definitions it seems to go through in {{ImplementationCollector#process}} is *33009* and the loop looks to be making progress, so it's more likely just incredibly slow and not an infinite hang.
> The dependency in pom.xml looks as follows:
> {code:xml}
> <dependency>
> <groupId>fish.payara.extras</groupId>
> <artifactId>payara-embedded-all</artifactId>
> <version>4.1.1.162</version>
> <scope>test</scope>
> </dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22658) Infinite or very long hang in CDI builder with Payara embedded maven dep
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22658?page=com.atlassian.jira.plugi... ]
arjan tijms commented on JBIDE-22658:
-------------------------------------
{quote}Fixed in master. Full CDI build still can take long time for projects with huge CDI jars but it can now take minutes. Not hours.{quote}
Thanks Alexey, I'll try it out soon, and certainly will try it when 4.4.1 comes in as update.
> Infinite or very long hang in CDI builder with Payara embedded maven dep
> ------------------------------------------------------------------------
>
> Key: JBIDE-22658
> URL: https://issues.jboss.org/browse/JBIDE-22658
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Reporter: arjan tijms
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.1.AM1
>
>
> In the latest JBoss Tools for Eclipse Mars .2 (would be great if it was easy to see the main version easily, but I guess it's 4.3.1), the CDI builder either infinitely hangs or takes an enormous amount of time (an hour at least on a core M laptop) when payara embedded is present as (test) dependency in a maven project.
> During this hang I took a stack trace, which looks as follows:
> {noformat}
> "Worker-20" #96 prio=5 os_prio=31 tid=0x0000000101512000 nid=0x14803 runnable [0x0000700003fde000]
> java.lang.Thread.State: RUNNABLE
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.zip.ZipFile.<init>(ZipFile.java:163)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2678)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2644)
> at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:156)
> at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:355)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:290)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:284)
> at org.eclipse.jdt.internal.core.ClassFile.buildStructure(ClassFile.java:93)
> at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
> at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
> at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:579)
> at org.eclipse.jdt.internal.core.BinaryType.getElementInfo(BinaryType.java:287)
> at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:302)
> at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:220)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.process(ImplementationCollector.java:41)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.<init>(ImplementationCollector.java:32)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.rebuildBeans(CDIProject.java:1309)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.update(CDIProject.java:1216)
> - locked <0x000000078ecd93d8> (a org.jboss.tools.cdi.internal.core.impl.CDICache)
> at org.jboss.tools.cdi.internal.core.impl.definition.DefinitionContext.applyWorkingCopy(DefinitionContext.java:442)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:267)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
> I debugged Eclipse with a second Eclipse, and it appeared that the code is repeatedly opening {{.m2/repository/fish/payara/extras/payara-embedded-all/4.1.1.162/payara-embedded-all-4.1.1.162.jar}} from {{CDIProject#rebuildBeans}}.
> The specific line of code is:
> {code:java}
> ImplementationCollector ic = new ImplementationCollector(typeDefinitions);
> {code}
> The number of type definitions it seems to go through in {{ImplementationCollector#process}} is *33009* and the loop looks to be making progress, so it's more likely just incredibly slow and not an infinite hang.
> The dependency in pom.xml looks as follows:
> {code:xml}
> <dependency>
> <groupId>fish.payara.extras</groupId>
> <artifactId>payara-embedded-all</artifactId>
> <version>4.1.1.162</version>
> <scope>test</scope>
> </dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22658) Infinite or very long hang in CDI builder with Payara embedded maven dep
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22658?page=com.atlassian.jira.plugi... ]
Alexey Kazakov edited comment on JBIDE-22658 at 7/1/16 3:39 PM:
----------------------------------------------------------------
Fixed in master. Full CDI build still can take long time for projects with huge CDI jars but it can now take minutes. Not hours.
was (Author: akazakov):
Fixed in master. Full CDI build still can take long time for projects with huge CDI jars but it can now takes minutes. Not hours.
> Infinite or very long hang in CDI builder with Payara embedded maven dep
> ------------------------------------------------------------------------
>
> Key: JBIDE-22658
> URL: https://issues.jboss.org/browse/JBIDE-22658
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Reporter: arjan tijms
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.1.AM1
>
>
> In the latest JBoss Tools for Eclipse Mars .2 (would be great if it was easy to see the main version easily, but I guess it's 4.3.1), the CDI builder either infinitely hangs or takes an enormous amount of time (an hour at least on a core M laptop) when payara embedded is present as (test) dependency in a maven project.
> During this hang I took a stack trace, which looks as follows:
> {noformat}
> "Worker-20" #96 prio=5 os_prio=31 tid=0x0000000101512000 nid=0x14803 runnable [0x0000700003fde000]
> java.lang.Thread.State: RUNNABLE
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.zip.ZipFile.<init>(ZipFile.java:163)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2678)
> at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2644)
> at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:156)
> at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:355)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:290)
> at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:284)
> at org.eclipse.jdt.internal.core.ClassFile.buildStructure(ClassFile.java:93)
> at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
> at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
> at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:579)
> at org.eclipse.jdt.internal.core.BinaryType.getElementInfo(BinaryType.java:287)
> at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:302)
> at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:220)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.process(ImplementationCollector.java:41)
> at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.<init>(ImplementationCollector.java:32)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.rebuildBeans(CDIProject.java:1309)
> at org.jboss.tools.cdi.internal.core.impl.CDIProject.update(CDIProject.java:1216)
> - locked <0x000000078ecd93d8> (a org.jboss.tools.cdi.internal.core.impl.CDICache)
> at org.jboss.tools.cdi.internal.core.impl.definition.DefinitionContext.applyWorkingCopy(DefinitionContext.java:442)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:267)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
> I debugged Eclipse with a second Eclipse, and it appeared that the code is repeatedly opening {{.m2/repository/fish/payara/extras/payara-embedded-all/4.1.1.162/payara-embedded-all-4.1.1.162.jar}} from {{CDIProject#rebuildBeans}}.
> The specific line of code is:
> {code:java}
> ImplementationCollector ic = new ImplementationCollector(typeDefinitions);
> {code}
> The number of type definitions it seems to go through in {{ImplementationCollector#process}} is *33009* and the loop looks to be making progress, so it's more likely just incredibly slow and not an infinite hang.
> The dependency in pom.xml looks as follows:
> {code:xml}
> <dependency>
> <groupId>fish.payara.extras</groupId>
> <artifactId>payara-embedded-all</artifactId>
> <version>4.1.1.162</version>
> <scope>test</scope>
> </dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months