[JBoss JIRA] (JBIDE-16934) faces-config.xml is not renamed
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16934?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-16934:
-----------------------------------
Fix Version/s: 4.3.x
(was: 4.2.0.Beta3)
> faces-config.xml is not renamed
> -------------------------------
>
> Key: JBIDE-16934
> URL: https://issues.jboss.org/browse/JBIDE-16934
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.2.0.Beta1
> Environment: JBDS 8.0.0.Beta1-v20140323-1410-B78 Linux
> Reporter: Vlado Pakan
> Assignee: Viacheslav Kabanovich
> Priority: Minor
> Fix For: 4.3.x
>
>
> 1. Create JSF 1.2 project
> 2. Open faces-config.xml via Web Projects view
> 3. Rename this file via Web Projects view context menu
> ASSERT: File is renamed in Web Project view
> ERROR: Editor title is not changed to new file name
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (JBIDE-17015) Restrict number of dependency links stored by project contexts
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17015?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-17015:
-----------------------------------
Fix Version/s: 4.2.0.CR1
(was: 4.2.0.Beta3)
> Restrict number of dependency links stored by project contexts
> --------------------------------------------------------------
>
> Key: JBIDE-17015
> URL: https://issues.jboss.org/browse/JBIDE-17015
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: jsp/jsf/xml/html source editing
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Fix For: 4.2.0.CR1
>
>
> If a large project has too many dependencies between resources, the number of links may get as big as a square of the number of resources. Storing and iterating collections of links in this case will deteriorate the performance. We can set a reasonable limit, say 10000, and if reached, report info message to log. Then, we can either do full validation each time instead of incremental, or add to log, that validation may fail fail to reevaluate some resources dependent on changed ones.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (JBIDE-16286) CDI builder (not import, workspace rebuild) is very slow in wildfly
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16286?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-16286:
-----------------------------------
Fix Version/s: 4.2.0.CR1
(was: 4.2.0.Beta3)
> CDI builder (not import, workspace rebuild) is very slow in wildfly
> -------------------------------------------------------------------
>
> Key: JBIDE-16286
> URL: https://issues.jboss.org/browse/JBIDE-16286
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi, maven
> Affects Versions: 4.1.1.Final
> Reporter: Andre Dietisheim
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Labels: performance
> Fix For: 4.2.0.CR1
>
> Attachments: cdi-builder.ogv, cleanBuild.png, full-bundle-listing.txt, maven-preferences-hide-children.png, thread-dump-7_05.txt, thread-dump-7_19.txt, updatingPom.png, VisualVM 1.3.2 _083.png
>
>
> When working in a wildfly workspace with all wildfly projects imported and CDI builder enabled, workspace rebuilds (that you trigger by changing poms and then do maven update project) are a lot slower than without it. Re-building the whole workspace can easily take up to 20 minutes for me.
> Hard to give more general purpose details, I did a quick screencast to give an impression how slow things are for me.
> [^cdi-builder.ogv]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (JBIDE-17591) org.jboss.tools.common.el.core.test fails on Max OS X Mavericks
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17591?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-17591:
-----------------------------------
Fix Version/s: 4.2.0.CR1
(was: 4.2.0.Beta3)
> org.jboss.tools.common.el.core.test fails on Max OS X Mavericks
> ---------------------------------------------------------------
>
> Key: JBIDE-17591
> URL: https://issues.jboss.org/browse/JBIDE-17591
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.2.0.Beta2
> Environment: Mac OS X Mavericks
> Reporter: Denis Golovin
> Assignee: Daniel Azarov
> Fix For: 4.2.0.CR1
>
> Attachments: org.jboss.tools.common.el.core.test.CommonELAllTests2.txt
>
>
> {code}junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertNotNull(Assert.java:256)
> at junit.framework.Assert.assertNotNull(Assert.java:248)
> at junit.framework.TestCase.assertNotNull(TestCase.java:417)
> at org.jboss.tools.common.el.core.test.resolver.TypeInfoCollectorTest.testTypeResolution(TypeInfoCollectorTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:123)
> at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:86)
> at org.eclipse.tycho.surefire.osgibooter.HeadlessTestApplication.run(HeadlessTestApplication.java:21)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:379)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (JBIDE-17209) only product for mylyn integration is JBossAS Server
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17209?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-17209:
-----------------------------------
Fix Version/s: 4.2.0.CR1
(was: 4.2.0.Beta3)
> only product for mylyn integration is JBossAS Server
> ----------------------------------------------------
>
> Key: JBIDE-17209
> URL: https://issues.jboss.org/browse/JBIDE-17209
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, common/jst/core, server
> Reporter: Max Rydahl Andersen
> Assignee: Alexey Kazakov
> Priority: Minor
> Fix For: 4.2.0.CR1
>
>
> Using "report bug or enhancement" JBoss Tools shows up but then after that a list of "products" is shown and it just list JBossAS Server.
> I would have expected Developer Studio too at least, and a few more key components.
> Note: this might not be something base should add, but put it into central or jbds product makes sense I think.
> -- Configuration Details --
> Product: Eclipse 4.4.0.20140301-1817 (org.eclipse.epp.package.jee.product)
> Installed Features:
> org.jboss.ide.eclipse.as.feature 3.0.0.Beta2-v20140421-1626-B483
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (JBIDE-16272) Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16272?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-16272:
-----------------------------------
Fix Version/s: 4.3.x
(was: 4.2.x)
> Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
> ---------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16272
> URL: https://issues.jboss.org/browse/JBIDE-16272
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.1.1.Final
> Reporter: Juraj Húska
> Assignee: Alexey Kazakov
> Fix For: 4.3.x
>
> Attachments: a4jTagLibCtrlClick.png, jbtca.png, jbthtml.png, jsfTagProposals.png, myAutocompletion1.png, myAutocompletion2.png, myAutocompletion3.png, scr.png, scr2.png, scr3.png, taglib2.png, tagLibraries1.png
>
>
> When I create new JSF project, where I add RichFaces libraries needed to create _RichFaces 4.5_ (a special version which should be some kind of bridge between RichFaces 4 and 5) application:
> * richfaces-5.0.0.Alpha2.jar
> * richfaces-components-a4j-4.5.0.Alpha1.jar
> * richfaces-components-rich-4.5.0.Alpha1.jar
> Then if you have all supported namespaces included, auto completion triggered e.g. on {{<a4j:}} will provides also non existing components, like {{<a4j:calendar}} (it should be {{<rich:calendar}} )
> Please see steps to reproduce.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months