[JBoss JIRA] (JBIDE-18968) IllegalArgumentException: "Argument not valid" occurs every time central is opened
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18968?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-18968:
--------------------------------
Fix Version/s: 4.3.0.Beta1
(was: 4.3.0.Alpha2)
> IllegalArgumentException: "Argument not valid" occurs every time central is opened
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-18968
> URL: https://issues.jboss.org/browse/JBIDE-18968
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, upstream
> Affects Versions: 4.2.1.Final
> Reporter: Denis Golovin
> Assignee: Fred Bricon
> Fix For: 4.3.0.Beta1
>
>
> {code}java.lang.IllegalArgumentException: Argument not valid
> at org.eclipse.swt.SWT.error(SWT.java:4422)
> at org.eclipse.swt.SWT.error(SWT.java:4356)
> at org.eclipse.swt.SWT.error(SWT.java:4327)
> at org.eclipse.swt.graphics.Image.init(Image.java:1294)
> at org.eclipse.swt.graphics.Image.<init>(Image.java:200)
> at org.eclipse.ui.forms.widgets.Section.onPaint(Section.java:344)
> at org.eclipse.ui.forms.widgets.ExpandableComposite$1.paintControl(ExpandableComposite.java:561)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1397)
> at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3174)
> at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:171)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2060)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:5513)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4668)
> at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9106)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
> at org.eclipse.swt.internal.gtk.OS._gdk_window_process_all_updates(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gdk_window_process_all_updates(OS.java:5946)
> at org.eclipse.swt.widgets.Display.update(Display.java:4621)
> at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:3825)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3396)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19590) Update module's README.md files with information about dependencies to other modules
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19590?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19590:
---------------------------------------------
i've been wondering if we could have an eclipse project import set for each module that defines which to import.
> Update module's README.md files with information about dependencies to other modules
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-19590
> URL: https://issues.jboss.org/browse/JBIDE-19590
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Affects Versions: 4.3.0.Alpha2
> Reporter: Denis Golovin
>
> For almost every JBoss Tools module there are three major steps to configure eclipse workspace for development:
> 1. Set up target platform in preferences
> 2. Import JBT module sources into workspace
> 3. Import required JBT module sources into worksapce
> (1) and (2) are well documented in README.md files, but (3) is not (see forum reference for jbosstools-hibernate as an example).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3285) Easy Import of non-eclipse projects
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3285:
-------------------------------------------
difference between hide and fix ? fix it - that users not having m2e installed will be able to use it, hide it - stll broken ;)
Sounds like .project importer should block out sub dirs too somehow (different jira/issues)
> Easy Import of non-eclipse projects
> -----------------------------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.0.Alpha2
>
> Attachments: import-me.zip
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively): https://wiki.eclipse.org/E4/UI/Smart_Import
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3285) Easy Import of non-eclipse projects
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3285:
--------------------------------------
What's the difference between hide and fix?
Explanation is that the classes/ folder contains META-INF/MANIFEST.MF (which is currently detected as a PDE plugin - that's something to improve, but that's another topic), so the PDE detector applies.
However, when you have the Maven detector, it first detects your project as a Maven project, and it also computes a list of directories to exclude from analysis. In the case of Maven, it's the target/ folder. So the import framework just know that it doesn't have to get into the target/ folder in that case, and does try to import its content.
> Easy Import of non-eclipse projects
> -----------------------------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.0.Alpha2
>
> Attachments: import-me.zip
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively): https://wiki.eclipse.org/E4/UI/Smart_Import
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-17591) org.jboss.tools.common.el.core.test fails on Max OS X Mavericks
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17591?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-17591:
----------------------------------------
Sprint: Sprint to Beta3 Release (was: Sprint to Beta3 Release, Sprint #2 April 2015)
> 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.3.x
>
> 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.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3285) Easy Import of non-eclipse projects
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen edited comment on JBDS-3285 at 4/14/15 3:49 PM:
--------------------------------------------------------------------
Looking at fred's .zip file this definitely should not result in 2 projects created - the .project file in the root should make everything else below not relevant unless there is another clear project "marker".
And osgi/pde should not think if it finds a manifest.mf is enough to create a project - it should also find some .java source.
So even without ordering the current configurators are not great and will fail if users don't have m2e loaded etc to catch this case (for example).
I still think we should add it into alpha2 but we definitely must improve this API for beta1 since these are things we already knew about back in november and we got plenty of usecases now.
was (Author: maxandersen):
Looking at fred's .zip file this definitely should not result in 2 projects created - the .project file in the root should make everything else below not relevant unless there is another clear project "marker".
And osgi/pde should not think if it finds a manifest.mf is enough to create a project - it should also find some .java source.
> Easy Import of non-eclipse projects
> -----------------------------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.0.Alpha2
>
> Attachments: import-me.zip
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively): https://wiki.eclipse.org/E4/UI/Smart_Import
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3285) Easy Import of non-eclipse projects
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3285:
-------------------------------------------
Looking at fred's .zip file this definitely should not result in 2 projects created - the .project file in the root should make everything else below not relevant unless there is another clear project "marker".
And osgi/pde should not think if it finds a manifest.mf is enough to create a project - it should also find some .java source.
> Easy Import of non-eclipse projects
> -----------------------------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Mickael Istria
> Labels: usability
> Fix For: 9.0.0.Alpha2
>
> Attachments: import-me.zip
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
> Progress/Status (updated progressively): https://wiki.eclipse.org/E4/UI/Smart_Import
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years