[JBoss JIRA] (ERT-663) Display.getClientArea() includes toolbar on Linux [EBZ#33659]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-663:
---------------------------------------
Summary: Display.getClientArea() includes toolbar on Linux [EBZ#33659]
Key: ERT-663
URL: https://issues.jboss.org/browse/ERT-663
Project: Eclipse Release Train
Issue Type: Task
Components: Platform
Reporter: Friendly Jira Robot
20030227
The client area on Linux Motif also includes the toolbar whereas on other
playforms it doesn't.
STEPS
1) Set you display to 1024 x 768
2) Execute Display.getClientArea()
3) Value us 1024,768
4) Switch to XP
5) Execute Display.getClientArea()
6) Value us 1024,738
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (JBIDE-26304) File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26304?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-26304:
-------------------------------------
Description:
JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
h2. Steps:
I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
# ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
# ASSERT: Initially I have
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="hello"
{code}.
# ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
# EXEC: I go project preferences > Maven and choose the "openshift" profile
# ASSERT: I see component settings being updated on disk.
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="ROOT"
{code}.
# RESULT: the configured module for my OpenShift server adapter is still called *hello*.
# ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
# EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
# RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
h2. Fix:
To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
{code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
protected void cleanAllDelegates() {
Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
while(i.hasNext()) {
i.next().clearCache();
}
+ clearModuleCache();
modulesChanged();
}
+ @Override
+ public void clearModuleCache() {
+ clearCache(null);
+ }
{code}
ps. notice the oddness in terms of API:
{code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
was:
JBIDE-22138 was reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
While implementing it was discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
h2. Steps:
I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
# ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
# ASSERT: Initially I have
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="hello"
{code}.
# ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
# EXEC: I go project preferences > Maven and choose the "openshift" profile
# ASSERT: I see component settings being updated on disk.
{code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
deploy-name="ROOT"
{code}.
# RESULT: the configured module for my OpenShift server adapter is still called *hello*.
# ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
# EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
# RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
h2. Fix:
To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
{code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
protected void cleanAllDelegates() {
Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
while(i.hasNext()) {
i.next().clearCache();
}
+ clearModuleCache();
modulesChanged();
}
+ @Override
+ public void clearModuleCache() {
+ clearCache(null);
+ }
{code}
ps. notice the oddness in terms of API:
{code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
> File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
> ----------------------------------------------------------------------
>
> Key: JBIDE-26304
> URL: https://issues.jboss.org/browse/JBIDE-26304
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.9.0.AM3
> Reporter: Andre Dietisheim
> Fix For: 4.9.0.AM3
>
>
> JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
> While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
> We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
> h2. Steps:
> I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
> The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
> # ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
> # ASSERT: Initially I have
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="hello"
> {code}.
> # ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
> # EXEC: I go project preferences > Maven and choose the "openshift" profile
> # ASSERT: I see component settings being updated on disk.
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="ROOT"
> {code}.
> # RESULT: the configured module for my OpenShift server adapter is still called *hello*.
> # ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
> # EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
> # RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
> h2. Fix:
> To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
> {code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
> protected void cleanAllDelegates() {
> Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
> while(i.hasNext()) {
> i.next().clearCache();
> }
> + clearModuleCache();
> modulesChanged();
> }
> + @Override
> + public void clearModuleCache() {
> + clearCache(null);
> + }
> {code}
> ps. notice the oddness in terms of API:
> {code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (JBIDE-26304) File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26304?page=com.atlassian.jira.plugi... ]
Andre Dietisheim reassigned JBIDE-26304:
----------------------------------------
Assignee: Andre Dietisheim
> File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
> ----------------------------------------------------------------------
>
> Key: JBIDE-26304
> URL: https://issues.jboss.org/browse/JBIDE-26304
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.9.0.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.9.0.AM3
>
>
> JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
> While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
> We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
> h2. Steps:
> I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
> The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
> # ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
> # ASSERT: Initially I have
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="hello"
> {code}.
> # ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
> # EXEC: I go project preferences > Maven and choose the "openshift" profile
> # ASSERT: I see component settings being updated on disk.
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="ROOT"
> {code}.
> # RESULT: the configured module for my OpenShift server adapter is still called *hello*.
> # ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
> # EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
> # RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
> h2. Fix:
> To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
> {code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
> protected void cleanAllDelegates() {
> Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
> while(i.hasNext()) {
> i.next().clearCache();
> }
> + clearModuleCache();
> modulesChanged();
> }
> + @Override
> + public void clearModuleCache() {
> + clearCache(null);
> + }
> {code}
> ps. notice the oddness in terms of API:
> {code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (JBIDE-26170) Define JAVAxx and OPENJDKxx for new JDKs and OpenJDKs installed
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26170?page=com.atlassian.jira.plugi... ]
Martin Malina resolved JBIDE-26170.
-----------------------------------
Resolution: Done
Resolving this issue. The linked ticket is now closed. Feel free to open a new issue or ticket if some of the jdks still don't work.
> Define JAVAxx and OPENJDKxx for new JDKs and OpenJDKs installed
> ---------------------------------------------------------------
>
> Key: JBIDE-26170
> URL: https://issues.jboss.org/browse/JBIDE-26170
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.6.0.Final
> Reporter: Jeff MAURY
> Assignee: Martin Malina
> Fix For: 4.9.0.AM3
>
> Attachments: jdk_paths.png, jdk_vars.png
>
>
> The JBoss Tools JDK9+ jobs rely on JAVAxx and OPENJDKxx variables through the toolchains.xml file. As we want to move those jobs to Java10 and Java11, we need those variables to be defined
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (JBIDE-26313) checkUnresolvedIssues.py no longer works with latest python or latest JIRA release
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26313?page=com.atlassian.jira.plugi... ]
Nick Boldt closed JBIDE-26313.
------------------------------
> checkUnresolvedIssues.py no longer works with latest python or latest JIRA release
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-26313
> URL: https://issues.jboss.org/browse/JBIDE-26313
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.9.0.AM2
>
>
> A couple months ago, I could run this script and it would automatically move JIRAs from last sprint to next sprint.
> {code}
> export userpass=JIRAUSER:JIRAPWD
> # can filter out labels using --skipLabels "releasework, task, qa" etc.
> # can do a dry run (list issues, do not change them) with -D
> # skip verifying JIRA fixversions with -S
> # automatically apply changes with -A
> # for the latest sprint names see agile board https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=641&view=planning
> # sometimes the sprint_NEXT is already created, but with a name that's different from what you might expect (eg., different month, wrong year)
> # if previous sprint is done, use sprint=sprint_NEXT here
> sprint="devex #153 August 2018"
> sprint_NEXT="devex #154 September 2018"
> versionWithRespin_jbt=4.9.0.AM2
> versionWithRespin_jbt_NEXT=4.9.0.AM3
> versionWithRespin_ds=12.9.0.AM2
> versionWithRespin_ds_NEXT=12.9.0.AM3
> python -W ignore /tmp/jbt.github/jbosstools-build-ci/util/checkUnresolvedIssues.py -S --jira https://issues.jboss.org \
> --jbt ${versionWithRespin_jbt} --jbt_NEXT ${versionWithRespin_jbt_NEXT} \
> --ds ${versionWithRespin_ds} --ds_NEXT ${versionWithRespin_ds_NEXT} \
> --sprint "${sprint}" --sprint_NEXT "${sprint_NEXT}" --skipLabels "task, releasework" -A
> {code}
> Now it's broken because ...? not sure. Problem happens on line 191.
> {code}
> Traceback (most recent call last):
> File "/tmp/jbt.github/jbosstools-build-ci/util/checkUnresolvedIssues.py", line 191, in <module>
> updateIssues(components.getIssuesFromQuery(query, jiraserver, jirauser, jirapwd), True, \
> File "/home/nboldt/tru/jbosstools-build-ci/util/components.py", line 196, in getIssuesFromQuery
> return doQuery(query, 'item', jiraserver, jirauser, jirapwd, 1000)
> File "/home/nboldt/tru/jbosstools-build-ci/util/components.py", line 215, in doQuery
> xml = minidom.parseString(q.text)
> File "/usr/lib64/python2.7/xml/dom/minidom.py", line 1928, in parseString
> return expatbuilder.parseString(string)
> File "/usr/lib64/python2.7/xml/dom/expatbuilder.py", line 940, in parseString
> return builder.parseString(string)
> File "/usr/lib64/python2.7/xml/dom/expatbuilder.py", line 223, in parseString
> parser.Parse(string, True)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 172594: ordinal not in range(128)
> {code}
> Seems to be a problem with `xml = minidom.parseString(q.text)` on line 215 of components.py
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months