[JBoss JIRA] (JBDS-2719) Multiple Spring AOP problems when travel example is imported
by Joshua Wilson (JIRA)
[ https://issues.jboss.org/browse/JBDS-2719?page=com.atlassian.jira.plugin.... ]
Joshua Wilson commented on JBDS-2719:
-------------------------------------
[~nickboldt] I will need to test several different configurations to confirm my earlier guess. This is what I know so far.
First I would ask that you test with the [Kitchensink-Spring Quickstarts|https://github.com/jboss-developer/jboss-wfk-quickstarts] as I am working to keep them up to date and error free as much as possible. This specific error can be seen in the [kitchensink-spring-matrixvariable|https://github.com/jboss-developer/jbos...] quickstart. The Travel and PetClinic will be kept as close to the original as possible (and I haven't had a chance to update them yet).
With that in mind if I Build (with Eclipse/JBDS) [kitchensink-spring-matrixvariable|https://github.com/jboss-developer/jbos...] in JBDS 7.0.1 with Spring IDE 3.3 installed from JBoss Central, I get the aspectj error. However if I Build while in a standard Eclipse JEE install with JBDS and the stock Spring IDE/STS 3.4 installed, I do NOT get the aspectj error.
In order to truly confirm that adding both "AspectJ Compiler" and "AspectJ Development Tools" will fix the error, I would need to test that on my JBDS 7.0.1/SpringIDE 3.3 set up.
> Multiple Spring AOP problems when travel example is imported
> ------------------------------------------------------------
>
> Key: JBDS-2719
> URL: https://issues.jboss.org/browse/JBDS-2719
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification, upstream
> Affects Versions: 7.0.0.GA
> Environment: JBDS 7.0.0.GA, L64, Spring IDE 3.3 installed from JBoss Central
> Reporter: Jiri Peterka
> Assignee: Nick Boldt
> Fix For: 7.1.0.Beta1
>
>
> There are Multiple Spring AOP Errors after travel example is imported:
> {code}
> Build path is incomplete. Cannot find class file for org/aspectj/weaver/reflect/ReflectionWorld$ReflectionWorldException
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
1 day, 3 hours
[JBoss JIRA] (JBIDE-26643) Page "CDI Facets settings" page is not present in the "CDI Web Project" wizard when CDI 2.0 is used
by Jeff MAURY (Jira)
[ https://issues.jboss.org/browse/JBIDE-26643?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-26643:
-------------------------------
Fix Version/s: 4.12.0.Final
(was: 4.12.0.AM1)
> Page "CDI Facets settings" page is not present in the "CDI Web Project" wizard when CDI 2.0 is used
> ---------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26643
> URL: https://issues.jboss.org/browse/JBIDE-26643
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.11.0.Final
> Environment: OS X 10.14.5
> Reporter: Zbyněk Červinka
> Assignee: Jeff MAURY
> Priority: Major
> Fix For: 4.12.0.Final
>
> Attachments: page_missing_on_cdi_2_0.png
>
>
> Page captured on the "page_missing_on_cdi_2_0.png" img in Attachment is not present in the "CDI Web Project" wizard when CDI 2.0 is used. It is present when CDI 1.0, 1.1 or 1.2 is used and it should be either present for all CDI versions or not present at any CDI version (the wizard should be consistent and if there is not reason for that it should be the same for all versions).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
2 weeks, 1 day
[JBoss JIRA] (JBDS-3044) Align installation default path with installer filename
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3044?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-3044 at 5/28/14 10:36 AM:
------------------------------------------------------------
Martin did a quick test on OSX to see what the longest file paths are inside JBDS 8 Beta2:
{quote}
{code}
find jbdevstudio-* |awk '{ print length($0) ; }'|sort|uniq|egrep "2.+"
{code}
shows 251 as the longest path on Mac so not really safe
longest is ./studio/configuration/org.eclipse.osgi/949/data/c7ff8a0a591e0e90fe36069138e75f68/1012-1401176993555/org.springframework.ide.eclipse.core.java.ProjectClassLoaderCache$SourceAndOutputLocationResourceChangeListener$SourceAndOutputLocationResourceVisitor
but that is spring and it's data
{quote}
So we're already pushing the limit here for long paths on Windows / NTFS...
Related (with some LOLs): http://blog.codinghorror.com/filesystem-paths-how-long-is-too-long/
There are ways to achieve more-than-260-char paths, but do we want to?
was (Author: nickboldt):
Martin did a quick test on OSX to see what the longest file paths are inside JBDS 8 Beta2:
{quote}
{code}
find jbdevstudio-* |awk '{ print length($0) ; }'|sort|uniq|egrep "2.+"
{code}
shows 251 as the longest path on Mac so not really safe
longest is ./studio/configuration/org.eclipse.osgi/949/data/c7ff8a0a591e0e90fe36069138e75f68/1012-1401176993555/org.springframework.ide.eclipse.core.java.ProjectClassLoaderCache$SourceAndOutputLocationResourceChangeListener$SourceAndOutputLocationResourceVisitor
but that is spring and it's data
{quote}
So we're already pushing the limit here for long paths on Windows / NTFS...
> Align installation default path with installer filename
> -------------------------------------------------------
>
> Key: JBDS-3044
> URL: https://issues.jboss.org/browse/JBDS-3044
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Martin Malina
> Assignee: Denis Golovin
> Priority: Blocker
> Labels: discuss
> Fix For: 8.0.0.Beta3
>
>
> Now that Nick changed the installer filenames to jboss-devstudio in JBIDE-16871 (was jbdevstudio), shouldn't the default install path be changed similarly? Because it just went out of sync.
> This question is open for discussion. Nick pointed out some reasons against this suggestion:
> {quote}
> Martin Malina Re: changing the installation folder, I'll hold off on that change for the moment for a few reasons:
> a) Max is AFK, and will want to vet/veto this idea
> b) long paths for Windows users (80% of our user base) = bad news, especially considering how long some file paths can get already within Eclipse workspaces
> c) short paths for Windows (c:\jbdevstudio) & long paths for everyone else ~/jboss-devstudio) would be ill-advised from a documentation and cross-platform user experience
> So, either we stick w/ jbdevstudio, or we shorten to devstudio (losing the "jb" branding fragment). If we move to "jboss-devstudio" we increase the path by only 4 characters.
> Max Rydahl Andersen WDYT?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
1 month, 3 weeks
[JBoss JIRA] (ERT-748) [GTK3] Shell dispose slowdown [EBZ#549644]
by Eric Williams (Jira)
[ https://issues.jboss.org/browse/ERT-748?page=com.atlassian.jira.plugin.sy... ]
Eric Williams reassigned ERT-748:
---------------------------------
Sprint: devex #170 Aug 2019
Assignee: Eric Williams
> [GTK3] Shell dispose slowdown [EBZ#549644]
> ------------------------------------------
>
> Key: ERT-748
> URL: https://issues.jboss.org/browse/ERT-748
> Project: Eclipse Release Train
> Issue Type: Task
> Components: Platform
> Reporter: Friendly Jira Robot
> Assignee: Eric Williams
> Priority: Major
> Labels: 4.13_M3, SWT, bzira
>
> Created attachment 279428
> Snippet
> GTK version: 3.22.30
> SWT version: 4928
> With the fix from Bug 547227, SWTBot unit tests are sometimes able to complete on GTK3 successfully. However sometimes the build still fails with Tycho return code 137.
> Running a loop to continuously create and dispose a ControlExample in a Shell shows that the dispose gets progressively slower.
> Doing this with the SWTBot ControlExample (a modified copy) crashes the build after less than 700 iterations, with the dispose time starting around 300 ms and ending around 2,300 ms:
> https://ci.eclipse.org/swtbot/job/swtbot-gerrit/1071/console
> By comparison, the same code with GTK2 on 2018-09 target platform crashes after more than 13,000 iterations, but the dispose time is stable around 50 ms throughout:
> https://ci.eclipse.org/swtbot/job/swtbot-gerrit/1070/console
> The slowdown problem can be reproduced locally using the original ControlExample from SWT. See the included snippet.
> Profiling this snippet shows that the majority of the time is spent in GTK._gtk_widget_destroy[native] for the Shell itself.
> main 100,341 ms (100%) 100,341 ms (100%)
> +SnippetControlExampleDispose.main () 100,341 ms (100%) 100,341 ms (100%)
> +org.eclipse.swt.widgets.Shell.dispose () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Widget.dispose () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Control.release () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Widget.release () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Widget.destroyWidget () 61,443 ms (61.2%) 61,443 ms (61.2%)
> +org.eclipse.swt.internal.gtk.GTK.gtk_widget_destroy () 61,443 ms (61.2%) 61,443 ms (61.2%)
> +org.eclipse.swt.internal.gtk.GTK._gtk_widget_destroy[native] () 61,443 ms (61.2%) 61,443 ms (61.2%)
> +org.eclipse.swt.widgets.Shell.releaseChildren () 2,954 ms (2.9%) 2,954 ms (2.9%)
> +org.eclipse.swt.examples.controlexample.ControlExample.<init> () 35,103 ms (35%) 35,103 ms (35%)
> +org.eclipse.swt.widgets.Shell.<init> () 840 ms (0.8%) 840 ms (0.8%)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (ERT-747) [GTK] Incorrect Table/Tree size [EBZ#546490]
by Eric Williams (Jira)
[ https://issues.jboss.org/browse/ERT-747?page=com.atlassian.jira.plugin.sy... ]
Eric Williams reassigned ERT-747:
---------------------------------
Sprint: devex #170 Aug 2019
Assignee: Eric Williams
> [GTK] Incorrect Table/Tree size [EBZ#546490]
> --------------------------------------------
>
> Key: ERT-747
> URL: https://issues.jboss.org/browse/ERT-747
> Project: Eclipse Release Train
> Issue Type: Task
> Components: Platform
> Reporter: Friendly Jira Robot
> Assignee: Eric Williams
> Priority: Major
> Labels: 4.13_M3, SWT, bzira
>
> Many errors related to Table and Tree size and packing of columns are demonstrated by the included snippets and screenshots.
> Table #1 with no items, 5 columns packed
> expected: height = header height, width = sum of packed columns
> actual 3.10: height = 1 pixel too much, fixed after resize
> actual 3.22: headers not drawn
> Table #2 with no items, 5 columns width=0
> expected: height = header height, width = 0
> actual 3.10: width = 64
> actual 3.22: width = 64
> Table #3 with no items, 5 columns width=100
> expected: height = header height, width = 500
> actual 3.10: all OK
> actual 3.22: headers not drawn
> Table #4 with 5 items, 5 columns width=100
> expected: height = header height + 5 x item height, width = 500
> actual 3.10: height = 5 x item height, fixed after resize
> actual 3.22: height = 5 x item height, fixed after resize
> Table #5 with 5 items, 5 columns packed
> expected: height = header height + 5 x item height, width = 500
> actual 3.10: height = 5 x item height, fixed after resize
> actual 3.22: height = 5 x item height, fixed after resize
> Shell with 5 tables, packed
> expected: height = sum of children heights, width = max of children widths
> actual 3.10: height is more than what is drawn
> actual 3.22: height is more than what is drawn
> Tree #1 with no items, 5 columns packed
> expected: height = header height, width = sum of packed columns
> actual 3.10: size = 64x64
> actual 3.22: size = 64x64
> Tree #2 with no items, 5 columns width=0
> expected: height = header height, width = 0
> actual 3.10: size = 64x64
> actual 3.22: size = 64x64
> Tree #3 with no items, 5 columns width=100
> expected: height = header height, width = 500
> actual 3.10: height = 64, fixed after resize
> actual 3.22: height = 64, fixed after resize but headers no longer drawn
> Tree #4 with 5 items, 5 columns width=100
> expected: height = header height + 5 x item height, width = 500
> actual 3.10: height = 5 x item height, fixed after resize
> actual 3.22: height = 5 x item height, fixed after resize
> Tree #5 with 5 items, 5 columns packed
> expected: height = header height + 5 x item height, width = 500
> actual 3.10: height = 5 x item height, fixed after resize, pack ignores header
> actual 3.22: height = 5 x item height, fixed after resize, pack ignores header
> Shell with 5 trees, packed
> expected: height = sum of children heights, width = max of children widths
> actual 3.10: OK, height is equal to what is drawn
> actual 3.22: OK, height is equal to what is drawn
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (ERT-746) [GTK] DateTime drop-down popup shell does not hiding on focus lost [EBZ#547811]
by Eric Williams (Jira)
[ https://issues.jboss.org/browse/ERT-746?page=com.atlassian.jira.plugin.sy... ]
Eric Williams resolved ERT-746.
-------------------------------
Resolution: Done
> [GTK] DateTime drop-down popup shell does not hiding on focus lost [EBZ#547811]
> -------------------------------------------------------------------------------
>
> Key: ERT-746
> URL: https://issues.jboss.org/browse/ERT-746
> Project: Eclipse Release Train
> Issue Type: Task
> Components: Platform
> Reporter: Friendly Jira Robot
> Assignee: Eric Williams
> Priority: Major
> Labels: SWT, bzira
>
> Debian Stretch
> GTK 3.22.30
> Eclipse SDK 4.12M3.
> When DateTime losts focus or when moving shell, drop down popup does not dissappear.
> It also reflects on GTK2 on SWT 3.108.
> It appears on the main shell of the application, but it does not appear on sub shell with style SWT.ON_TOP.
> If we comment the string DateTime.java:517 (handleFocus(SWT.FocusOut);) everything works fine. But i don't what this popupFilter needs for.
> I also attached snippet and video which reproduce the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (ERT-748) [GTK3] Shell dispose slowdown [EBZ#549644]
by Friendly Jira Robot (Jira)
Friendly Jira Robot created ERT-748:
---------------------------------------
Summary: [GTK3] Shell dispose slowdown [EBZ#549644]
Key: ERT-748
URL: https://issues.jboss.org/browse/ERT-748
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
Created attachment 279428
Snippet
GTK version: 3.22.30
SWT version: 4928
With the fix from Bug 547227, SWTBot unit tests are sometimes able to complete on GTK3 successfully. However sometimes the build still fails with Tycho return code 137.
Running a loop to continuously create and dispose a ControlExample in a Shell shows that the dispose gets progressively slower.
Doing this with the SWTBot ControlExample (a modified copy) crashes the build after less than 700 iterations, with the dispose time starting around 300 ms and ending around 2,300 ms:
https://ci.eclipse.org/swtbot/job/swtbot-gerrit/1071/console
By comparison, the same code with GTK2 on 2018-09 target platform crashes after more than 13,000 iterations, but the dispose time is stable around 50 ms throughout:
https://ci.eclipse.org/swtbot/job/swtbot-gerrit/1070/console
The slowdown problem can be reproduced locally using the original ControlExample from SWT. See the included snippet.
Profiling this snippet shows that the majority of the time is spent in GTK._gtk_widget_destroy[native] for the Shell itself.
main 100,341 ms (100%) 100,341 ms (100%)
+SnippetControlExampleDispose.main () 100,341 ms (100%) 100,341 ms (100%)
+org.eclipse.swt.widgets.Shell.dispose () 64,397 ms (64.2%) 64,397 ms (64.2%)
+org.eclipse.swt.widgets.Widget.dispose () 64,397 ms (64.2%) 64,397 ms (64.2%)
+org.eclipse.swt.widgets.Control.release () 64,397 ms (64.2%) 64,397 ms (64.2%)
+org.eclipse.swt.widgets.Widget.release () 64,397 ms (64.2%) 64,397 ms (64.2%)
+org.eclipse.swt.widgets.Widget.destroyWidget () 61,443 ms (61.2%) 61,443 ms (61.2%)
+org.eclipse.swt.internal.gtk.GTK.gtk_widget_destroy () 61,443 ms (61.2%) 61,443 ms (61.2%)
+org.eclipse.swt.internal.gtk.GTK._gtk_widget_destroy[native] () 61,443 ms (61.2%) 61,443 ms (61.2%)
+org.eclipse.swt.widgets.Shell.releaseChildren () 2,954 ms (2.9%) 2,954 ms (2.9%)
+org.eclipse.swt.examples.controlexample.ControlExample.<init> () 35,103 ms (35%) 35,103 ms (35%)
+org.eclipse.swt.widgets.Shell.<init> () 840 ms (0.8%) 840 ms (0.8%)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (ERT-747) [GTK] Incorrect Table/Tree size [EBZ#546490]
by Friendly Jira Robot (Jira)
Friendly Jira Robot created ERT-747:
---------------------------------------
Summary: [GTK] Incorrect Table/Tree size [EBZ#546490]
Key: ERT-747
URL: https://issues.jboss.org/browse/ERT-747
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
Many errors related to Table and Tree size and packing of columns are demonstrated by the included snippets and screenshots.
Table #1 with no items, 5 columns packed
expected: height = header height, width = sum of packed columns
actual 3.10: height = 1 pixel too much, fixed after resize
actual 3.22: headers not drawn
Table #2 with no items, 5 columns width=0
expected: height = header height, width = 0
actual 3.10: width = 64
actual 3.22: width = 64
Table #3 with no items, 5 columns width=100
expected: height = header height, width = 500
actual 3.10: all OK
actual 3.22: headers not drawn
Table #4 with 5 items, 5 columns width=100
expected: height = header height + 5 x item height, width = 500
actual 3.10: height = 5 x item height, fixed after resize
actual 3.22: height = 5 x item height, fixed after resize
Table #5 with 5 items, 5 columns packed
expected: height = header height + 5 x item height, width = 500
actual 3.10: height = 5 x item height, fixed after resize
actual 3.22: height = 5 x item height, fixed after resize
Shell with 5 tables, packed
expected: height = sum of children heights, width = max of children widths
actual 3.10: height is more than what is drawn
actual 3.22: height is more than what is drawn
Tree #1 with no items, 5 columns packed
expected: height = header height, width = sum of packed columns
actual 3.10: size = 64x64
actual 3.22: size = 64x64
Tree #2 with no items, 5 columns width=0
expected: height = header height, width = 0
actual 3.10: size = 64x64
actual 3.22: size = 64x64
Tree #3 with no items, 5 columns width=100
expected: height = header height, width = 500
actual 3.10: height = 64, fixed after resize
actual 3.22: height = 64, fixed after resize but headers no longer drawn
Tree #4 with 5 items, 5 columns width=100
expected: height = header height + 5 x item height, width = 500
actual 3.10: height = 5 x item height, fixed after resize
actual 3.22: height = 5 x item height, fixed after resize
Tree #5 with 5 items, 5 columns packed
expected: height = header height + 5 x item height, width = 500
actual 3.10: height = 5 x item height, fixed after resize, pack ignores header
actual 3.22: height = 5 x item height, fixed after resize, pack ignores header
Shell with 5 trees, packed
expected: height = sum of children heights, width = max of children widths
actual 3.10: OK, height is equal to what is drawn
actual 3.22: OK, height is equal to what is drawn
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months