June 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-19820) Batch feature makes wildfly import way slower

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19820?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-19820: --------------------------------------------- so slava says 3 minutes as base and rastislav has 10 minutes as its based ? That is quite some difference. is this machine dependent or because rastislav imported with validation enabled ? > Batch feature makes wildfly import way slower > --------------------------------------------- > > Key: JBIDE-19820 > URL: https://issues.jboss.org/browse/JBIDE-19820 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: batch > Affects Versions: 4.3.0.Alpha2 > Reporter: Rastislav Wagner > Assignee: Viacheslav Kabanovich > Priority: Critical > Fix For: 4.3.0.Beta1 > > > I made a comparison between Eclipse M6 and Eclipse M6 with batch feature installed while importing wildfly. WF is imported as maven project, maven is set to offline mode and local repository contains all needed dependencies. > I did a 4 runs with following results: > M6 was able to import WF 628,575,577,612 (in seconds) = average 598s > M6 with batch feature: 843,832,924,877 (in seconds) = average 869s -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19820) Batch feature makes wildfly import way slower

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19820?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-19820: --------------------------------------------- rastislav - and how was these numbers *before* the suggested fix ? > Batch feature makes wildfly import way slower > --------------------------------------------- > > Key: JBIDE-19820 > URL: https://issues.jboss.org/browse/JBIDE-19820 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: batch > Affects Versions: 4.3.0.Alpha2 > Reporter: Rastislav Wagner > Assignee: Viacheslav Kabanovich > Priority: Critical > Fix For: 4.3.0.Beta1 > > > I made a comparison between Eclipse M6 and Eclipse M6 with batch feature installed while importing wildfly. WF is imported as maven project, maven is set to offline mode and local repository contains all needed dependencies. > I did a 4 runs with following results: > M6 was able to import WF 628,575,577,612 (in seconds) = average 598s > M6 with batch feature: 843,832,924,877 (in seconds) = average 869s -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19808) Teiid Designer would like to depend on org.apache.directory.studio plugins

by Paul Richardson (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19808?page=com.atlassian.jira.plugi... ] Paul Richardson commented on JBIDE-19808: ----------------------------------------- Hey [~nickboldt] So I did create a jenkins at {code}$JENKINS/job/jbosstools-apache-directory-update-site/{code} over the weekend. You may want to take a look at the publishing script component to determine whether it can be improved. Build #12 executed successfully, publishing [this|http://download.jboss.org/jbosstools/updates/requirements/apache-dir...]. This snapshot validates in JBT-IS successfully and works with no issues in Teiid Designer. > Teiid Designer would like to depend on org.apache.directory.studio plugins > -------------------------------------------------------------------------- > > Key: JBIDE-19808 > URL: https://issues.jboss.org/browse/JBIDE-19808 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: target-platform, teiid > Affects Versions: 4.2.3.Final > Reporter: Paul Richardson > Assignee: Barry LaFond > Attachments: build.xml, p2.diff > > > *Reason:* > Teiid Designer currently employs a UI for interrogating and importing metadata from an LDAP server. This UI (2 wizards) is limited and prone to issues, eg. [TEIIDDES-2478|https://issues.jboss.org/browse/TEIIDDES-2478]. > The project [directory.apache.org|https://directory.apache.org] provides a more sophisticated LDAP browser View UI but has componentized into smaller reusable widgets. The BrowserWidget provides the main tree view and querying ability. Teiid would like to reuse this widget in its UI. Originally, an attempt was made to copy the widget yet porting in this fashion required the porting of 100+ classes hence a dependency makes far more sense. > The current working implementation of Teiid with this widget can be found here: > https://github.com/phantomjinx/teiid-designer/tree/ldap-studio > The current release of the apache.directory project is 2 years old. However, speaking to one of the developers on #apache-directory, the project is being actively maintained and a release is being considered with the next couple of months. In addition, the [svn repository|https://svn.apache.org/repos/asf/directory/studio/trunk] is receiving commits. > *Project page/sources:* > * [directory.apache.org|https://directory.apache.org] > * [svn repository|https://svn.apache.org/repos/asf/directory/studio/trunk] > * [udpate site | http://directory.apache.org/studio/update/2.x/] > *Version:* 2.0.0 > *License and owner:* Apache licence and Foundation > *Original p2 repo:* http://directory.apache.org/studio/update/2.x/ > *JBoss mirror:* http://download.jboss.org/jbosstools/updates/requirements/apache-director... > *Include Sources:* Not available from existing update site but may well be in the next release. > *Affected projects:* Teiid Designer > *Include in JBDS:* Yes > *Type of dependency:* distribution > *List of bundles added/removed:* > * org.apache.directory.api.ldap.model > * org.apache.directory.studio.common.core > * org.apache.directory.studio.common.ui > * org.apache.directory.studio.connection.core > * org.apache.directory.studio.connection.ui > * org.apache.directory.studio.ldapbrowser.common > * org.apache.directory.studio.ldapbrowser.core > * -org.apache.directory.studio.ldapbrowser.ui- Eliminated the dependency > {code} >  > <location includeAllPlatforms="false" includeMode="slicer" includeSource="true" type="InstallableUnit"> > <repository location="http://directory.apache.org/studio/update/2.x/"/> > <unit id="org.apache.directory.studio.ldapbrowser.feature.feature.group" version="2.0.0.v20130628"/> > </location> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19551) Ionic Palette: Empty list item

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19551?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-19551. ------------------------------- Verified with JBT 4.3.0-Beta1-v20150528-2309-B9993 > Ionic Palette: Empty list item > ------------------------------ > > Key: JBIDE-19551 > URL: https://issues.jboss.org/browse/JBIDE-19551 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsp/jsf/xml/html source editing > Affects Versions: 4.3.0.Alpha2 > Environment: Linux Ubuntu. GTK 3. > Reporter: Alexey Kazakov > Assignee: Viacheslav Kabanovich > Fix For: 4.3.0.Beta1 > > Attachments: fixed.png, list.png > > > In New List wizard, if there is more than one item then all items but the first are empty: > !list.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19793) Update HTML5 Ionic palette to the latest ionic 1.0 JS/CSS

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19793?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-19793. ------------------------------- Verified with JBT 4.3.0-Beta1-v20150528-2309-B9993 > Update HTML5 Ionic palette to the latest ionic 1.0 JS/CSS > --------------------------------------------------------- > > Key: JBIDE-19793 > URL: https://issues.jboss.org/browse/JBIDE-19793 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: jsp/jsf/xml/html source editing > Affects Versions: 4.3.0.Beta1 > Reporter: Alexey Kazakov > Assignee: Alexey Kazakov > Fix For: 4.3.0.Beta1 > > > Ionic 1.0 has been released: > http://blog.ionic.io/announcing-ionic-1-0/ > http://code.ionicframework.com/ > We should add the following links when using Ionic Palette: > {code:html} > <link rel="stylesheet" href="http://code.ionicframework.com/1.0.0/css/ionic.css" /> > <script src="http://code.ionicframework.com/1.0.0/js/ionic.bundle.js"></script> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19693) Exception when invoking code assist for external HTML file

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19693?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-19693. ------------------------------- Verified with JBT 4.3.0-Beta1-v20150528-2309-B9993 > Exception when invoking code assist for external HTML file > ---------------------------------------------------------- > > Key: JBIDE-19693 > URL: https://issues.jboss.org/browse/JBIDE-19693 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsp/jsf/xml/html source editing > Affects Versions: 4.3.0.Alpha2 > Environment: JBDS 9.0.0.Alpha2-v20150421-1151-B25, Linux 64 bit, Oracle JDK 1.7 > Reporter: Vlado Pakan > Assignee: Alexey Kazakov > Priority: Critical > Fix For: 4.3.0.Beta1 > > > 1. Open external html file in VPE > 2. Invoke code assist > ERROR (appears 3 times): > {noformat} > !ENTRY org.jboss.tools.jst.web.ui 4 0 2015-04-23 08:57:43.421 > !MESSAGE Cannot find existing file by its document. > !STACK 0 > java.lang.IllegalStateException: Cannot find existing file by its document. > at org.jboss.tools.jst.web.ui.internal.editor.contentassist.computers.AbstractXmlCompletionProposalComputer.createContext(AbstractXmlCompletionProposalComputer.java:125) > at org.jboss.tools.jst.web.ui.internal.editor.contentassist.computers.FaceletsELCompletionProposalComputer.createContext(FaceletsELCompletionProposalComputer.java:127) > at org.jboss.tools.jst.web.ui.internal.editor.contentassist.computers.AbstractXmlCompletionProposalComputer.computeCompletionProposals(AbstractXmlCompletionProposalComputer.java:83) > at org.jboss.tools.jst.web.ui.internal.editor.contentassist.computers.FaceletsELCompletionProposalComputer.computeCompletionProposals(FaceletsELCompletionProposalComputer.java:74) > at org.eclipse.wst.sse.ui.internal.contentassist.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:284) > at org.eclipse.wst.sse.ui.internal.contentassist.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:290) > at org.eclipse.wst.sse.ui.contentassist.StructuredContentAssistProcessor.collectProposals(StructuredContentAssistProcessor.java:484) > at org.eclipse.wst.sse.ui.contentassist.StructuredContentAssistProcessor.computeCompletionProposals(StructuredContentAssistProcessor.java:255) > at org.eclipse.wst.sse.ui.internal.contentassist.CompoundContentAssistProcessor.computeCompletionProposals(CompoundContentAssistProcessor.java:127) > at org.eclipse.jface.text.contentassist.ContentAssistant$5.run(ContentAssistant.java:1904) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) > at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1902) > at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:573) > at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:570) > at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:505) > at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) > at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:499) > at org.eclipse.jface.text.contentassist.ContentAssistant$2.run(ContentAssistant.java:384) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) > at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3790) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3428) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1112) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:993) > at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156) > at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) > at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) > at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) > 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:380) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) > 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:606) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19695) Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems."

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19695?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-19695. ------------------------------- Verified with JBT 4.3.0-Beta1-v20150528-2309-B9993 > Annoying message "Be sure, may be you also should rename setter methods to avoid compilation problems." > ------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19695 > URL: https://issues.jboss.org/browse/JBIDE-19695 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsf, jsp/jsf/xml/html source editing, seam2 > Affects Versions: 4.2.3.Final > Reporter: Clovis Seragiotto > Assignee: Alexey Kazakov > Fix For: 4.3.0.Beta1 > > Attachments: after installation.png, renaming a get method.png, Version chosen.png > > > When renaming a get-method in Eclipse, the warning "Be sure, may be you also should rename setter methods to avoid compilation problems." is displayed. > It should be possible to turn this warning off (and the sentence should be fixed). > By Googling the message, I found: > JBoss Tools SVN: r40216 - trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/core. > That is why I suppose the right component is seam. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19845) Project context menu: Creating a new OpenShift application via Configure always uses first connection from OpenShift Explorer view

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19845?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-19845: ------------------------------------- Comment: was deleted (was: IMHO we're starting from context menu with a connection (or a domain) selected (otherwise "New->Application" wouldnt show up). Thus it's clear for what connection the user wants to create an application. I tested in JBDS8 and that's how it behaved, you couldnt choose a different connection, the one that's use is the one that's selected in the explorer. IMHO the bug here is that we're not using the selected connection but the 1st one that exists. I'm updating the description accordingly.) > Project context menu: Creating a new OpenShift application via Configure always uses first connection from OpenShift Explorer view > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19845 > URL: https://issues.jboss.org/browse/JBIDE-19845 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Marián Labuda > Assignee: Andre Dietisheim > Priority: Critical > Labels: application_wizard > Fix For: 4.3.0.Beta1 > > > If user wants to create a new OpenShift application via context menu of a project, it is possible to do it via context menu "Configure - New/Import OpenShift application". Previously this selection prompted user to choose desired connection where to create a new application. Nowadays the first existing connection in OpenShift explorer view is selected and it is not possible to change connection. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19845) Project context menu: Creating a new OpenShift application via Configure always uses first connection from OpenShift Explorer view

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19845?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-19845: ------------------------------------------ IMHO we're starting from context menu with a connection (or a domain) selected (otherwise "New->Application" wouldnt show up). Thus it's clear for what connection the user wants to create an application. I tested in JBDS8 and that's how it behaved, you couldnt choose a different connection, the one that's use is the one that's selected in the explorer. IMHO the bug here is that we're not using the selected connection but the 1st one that exists. I'm updating the description accordingly. > Project context menu: Creating a new OpenShift application via Configure always uses first connection from OpenShift Explorer view > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19845 > URL: https://issues.jboss.org/browse/JBIDE-19845 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Marián Labuda > Assignee: Andre Dietisheim > Priority: Critical > Labels: application_wizard > Fix For: 4.3.0.Beta1 > > > If user wants to create a new OpenShift application via context menu of a project, it is possible to do it via context menu "Configure - New/Import OpenShift application". Previously this selection prompted user to choose desired connection where to create a new application. Nowadays the first existing connection in OpenShift explorer view is selected and it is not possible to change connection. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-18837. ------------------------------- Verified with nightly JBT > because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18837 > URL: https://issues.jboss.org/browse/JBIDE-18837 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, central, common/jst/core, project-examples > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Beta1 > > Attachments: generated-vs-soource-zip.png > > > When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples. > Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating. > And we need to use the maven enforcer plugin to fail the build if these versions get out of sync. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues June 2015