[JBoss JIRA] (JBIDE-19853) GTK3 (only): Erroneous labels in application wizard tree
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19853?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-19853:
---------------------------------------
The issue is caused by a bug described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=466499.
It can be reproduced on a distribution containing GTK >= 3.14 (Ubuntu 15, Fedora 21, Fedora 22...).
I have created a patch that hasn't been applied yet.
> GTK3 (only): Erroneous labels in application wizard tree
> --------------------------------------------------------
>
> Key: JBIDE-19853
> URL: https://issues.jboss.org/browse/JBIDE-19853
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Snjezana Peco
> Priority: Blocker
> Labels: application_wizard
> Attachments: gtk2-new-app-wizard-1.png, gtk2-new-app-wizard-2.png, gtk3-new-app-wizard-1.png, gtk3-new-app-wizard-2.png
>
>
> When run in GTK3 the tree in the v2 application wizard is showing completely erroneous labels. The labels even switch content when the tree items are unfolded.
> When running Eclipse using (export SWT_GTK3=0) the tree in the application wizard looks in the following correct way:
> !gtk2-new-app-wizard-1.png!
> unfolding the "Basic Cartridges" produces the following:
> !gtk2-new-app-wizard-2.png!
> Without the above env variable, which makes Eclipse use GTK3, the application wizard looks as follows:
> !gtk3-new-app-wizard-1.png!
> ... and when unfolding "Basic Cartridges" the labels for the 3 main cathegories and all the children change to display the same:
> !gtk3-new-app-wizard-2.png!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-18772) Include publish steps in pom files
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-18772:
----------------------------------------
{quote}What you're asking is currently possible, and is being done today. {quote}
It would require to introduce and use a additional properties in the parent pom to define the destination. I believe it's a good path to follow, however, it's one step after this Jira, it should probably be tracked separately.
> Include publish steps in pom files
> ----------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Priority: Critical
> Fix For: 4.3.0.Beta1
>
> Attachments: jbds-publish-to-snapshots.png
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-10120) find a way to display a project example once when several versions targeted for different runtimes exist
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10120?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-10120:
--------------------------------
Fix Version/s: 4.3.x
(was: 3.3.x)
> find a way to display a project example once when several versions targeted for different runtimes exist
> --------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-10120
> URL: https://issues.jboss.org/browse/JBIDE-10120
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: project-examples
> Affects Versions: 3.3.0.M3
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Labels: eap6-ux
> Fix For: 4.3.x
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> Given the upcoming (40+) new quickstart projects, we'll most likely have duplicates between the community and enterprise versions.
> In order to reduce the amount of quickstarts in the Project Examples UI, in addtion to adding a Runtime filter (JBIDE-10119),
> we could also regroup similar projects under one entry. So, for example, instead of seeing 2 entries for kitchensink (community) and kitchensink (eap6)
> We could display only one kitchensink entry in the UI, and upon selection, choose the actual version / target runtime we want to create.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBDS-3030) Spring conflicting handler message after Spring perspective is reset
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3030?page=com.atlassian.jira.plugin.... ]
Fred Bricon updated JBDS-3030:
------------------------------
Fix Version/s: 9.x
(was: 8.x)
> Spring conflicting handler message after Spring perspective is reset
> --------------------------------------------------------------------
>
> Key: JBDS-3030
> URL: https://issues.jboss.org/browse/JBDS-3030
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: 3rd-party-certification, upstream
> Affects Versions: 8.0.0.Beta1
> Reporter: Jiri Peterka
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 9.x
>
> Attachments: spring-conflicting-handler-cr1b.png
>
>
> Conflicting handlers for AUTOGEN:::org.springsource.ide.eclipse.commons.launch.actionSet/org.springsource.ide.eclipse.commons.launch.relaunch.action: {ActionDelegateHandlerProxy(null,org.springsource.ide.eclipse.commons.ui.launch.StopProcessPullDownToolbarDelegate)} vs {ActionDelegateHandlerProxy(null,org.springsource.ide.eclipse.commons.ui.launch.RelaunchProcessPullDownToolbarDelegate)}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-14396) Imported maven projects sometimes fail to resolve required classpath dependencies for tests
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14396?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-14396:
--------------------------------
Fix Version/s: LATER
(was: 4.2.x)
> Imported maven projects sometimes fail to resolve required classpath dependencies for tests
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14396
> URL: https://issues.jboss.org/browse/JBIDE-14396
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Lincoln Baxter III
> Assignee: Fred Bricon
> Fix For: LATER
>
> Attachments: m2e-forge.site-0.0.1-SNAPSHOT.zip
>
>
> Example project: https://github.com/forge/core/tree/M2ECLIPSE-BUG
> Steps to reproduce:
> * Import all modules into the workspace.
> * Select "aesh-tests" project.
> * Run as -> JUnit Test
> You should see the test fail to launch because of the following Class not found exception:
> {code}
> java.lang.NoClassDefFoundError: Lorg/jboss/forge/aesh/TestShellConfiguration;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2300)
> at java.lang.Class.getDeclaredFields(Class.java:1745)
> at org.junit.runners.model.TestClass.<init>(TestClass.java:49)
> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:75)
> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:57)
> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.ClassNotFoundException: org.jboss.forge.aesh.TestShellConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 25 more
> {code}
> This can be solved by manually adding required projects in the workspace as classpath dependencies of the JUnit launch configured for the project being tested, but this is obviously not right, and should be configured automatically by the M2E integration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months