[JBoss JIRA] (JBIDE-21151) Button file system in OpenShift Application wizard causes an error
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-21151:
-------------------------------------
Summary: Button file system in OpenShift Application wizard causes an error
Key: JBIDE-21151
URL: https://issues.jboss.org/browse/JBIDE-21151
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Marián Labuda
Priority: Blocker
In New OpenShift Application wizard on the first wizard page where selection of a template is, there is a button "File system..." which is supposed to open a file browser dialog, but nothing happens after click on it and following error with stacktrace is present in error log:
{code}
Unhandled event loop exception
java.lang.NullPointerException
at org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:137)
at org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:87)
at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:592)
at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:358)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage.substituteVariables(TemplateListPage.java:956)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage.isFile(TemplateListPage.java:545)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage.access$2(TemplateListPage.java:544)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage$14.createFileDialog(TemplateListPage.java:710)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage$14.widgetSelected(TemplateListPage.java:702)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1329)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3819)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3430)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
at org.eclipse.jface.window.Window.open(Window.java:803)
at org.jboss.tools.common.ui.WizardUtils.openWizardDialog(WizardUtils.java:279)
at org.jboss.tools.common.ui.WizardUtils.openWizardDialog(WizardUtils.java:270)
at org.jboss.tools.openshift.internal.ui.handler.NewApplicationHandler.execute(NewApplicationHandler.java:37)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:799)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:675)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$7(HandledContributionItem.java:659)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:592)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1329)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3819)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3430)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
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:139)
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:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
at org.eclipse.equinox.launcher.Main.main(Main.java:1488)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21150) Provide a way to change one's mind about accepting an SSL certificate
by Jan Richter (JIRA)
Jan Richter created JBIDE-21150:
-----------------------------------
Summary: Provide a way to change one's mind about accepting an SSL certificate
Key: JBIDE-21150
URL: https://issues.jboss.org/browse/JBIDE-21150
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Jan Richter
The tooling will only give the user one chance to accept/deny the SSL certificate, which happens on start of the session. This is particularly annoying when for some reason the user denies the certificate (or just cancels the dialog) because the only way to reset it is to restart the IDE.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21141) OpenShift Application Wizard: Tags for application templates should be grey
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21141?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-21141:
---------------------------------------
Yeah, it seems to be GTK3 issue because it is not happening on windows.
> OpenShift Application Wizard: Tags for application templates should be grey
> ---------------------------------------------------------------------------
>
> Key: JBIDE-21141
> URL: https://issues.jboss.org/browse/JBIDE-21141
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Marián Labuda
> Priority: Minor
> Labels: application_wizard, openshift_v3
>
> In New OpenShift application on first wizard page is tree of server application templates. Application templates of internal OSE 3 instance are currently shown together with tags in the same way. It would be nice if tags - the key words in parenthesis e.g. "(java, eap, jboss, xpaas)" - would be shown as styled text (gray) as less significant information. We should show difference between template name and tags.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21149) Improve implementation of EGitUtils.getDefaultRemoteRepo()
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21149?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21149:
-------------------------------------
Fix Version/s: 4.3.1.Beta1
4.4.0.Alpha1
> Improve implementation of EGitUtils.getDefaultRemoteRepo()
> ----------------------------------------------------------
>
> Key: JBIDE-21149
> URL: https://issues.jboss.org/browse/JBIDE-21149
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: code_quality
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it is a good idea to keep to right patterns to avoid an accidental applying a wrong one to a critical case.
> Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
> Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21149) Improve implementation of EGitUtils.getDefaultRemoteRepo()
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21149?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich updated JBIDE-21149:
------------------------------------------
Description:
When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it is a good idea to keep to right patterns to avoid an accidental applying a wrong one to a critical case.
Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
was:
When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it a good idea to keep to right patterns to avoid an accidental applying a wrong pattern to a critical case.
Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
> Improve implementation of EGitUtils.getDefaultRemoteRepo()
> ----------------------------------------------------------
>
> Key: JBIDE-21149
> URL: https://issues.jboss.org/browse/JBIDE-21149
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: code_quality
>
> When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it is a good idea to keep to right patterns to avoid an accidental applying a wrong one to a critical case.
> Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
> Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21149) Improve implementation of EGitUtils.getDefaultRemoteRepo()
by Viacheslav Kabanovich (JIRA)
Viacheslav Kabanovich created JBIDE-21149:
---------------------------------------------
Summary: Improve implementation of EGitUtils.getDefaultRemoteRepo()
Key: JBIDE-21149
URL: https://issues.jboss.org/browse/JBIDE-21149
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.0.Alpha1
Reporter: Viacheslav Kabanovich
Assignee: Viacheslav Kabanovich
When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it a good idea to keep to right patterns to avoid an accidental applying a wrong pattern to a critical case.
Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21141) OpenShift Application Wizard: Tags for application templates should be grey
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21141?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-21141:
------------------------------------------
[~mlabuda] this afaics an issue in GTK3, since i noticed this in the quickstarts-tree in the v2 application wizard, too. Can you please verify this on windows or mac?
> OpenShift Application Wizard: Tags for application templates should be grey
> ---------------------------------------------------------------------------
>
> Key: JBIDE-21141
> URL: https://issues.jboss.org/browse/JBIDE-21141
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Marián Labuda
> Priority: Minor
> Labels: application_wizard, openshift_v3
>
> In New OpenShift application on first wizard page is tree of server application templates. Application templates of internal OSE 3 instance are currently shown together with tags in the same way. It would be nice if tags - the key words in parenthesis e.g. "(java, eap, jboss, xpaas)" - would be shown as styled text (gray) as less significant information. We should show difference between template name and tags.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21143) Triggering action on one connection refresh whole OpenShift Explorer view
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21143?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21143:
-------------------------------------
Fix Version/s: 4.3.1.Beta1
> Triggering action on one connection refresh whole OpenShift Explorer view
> -------------------------------------------------------------------------
>
> Key: JBIDE-21143
> URL: https://issues.jboss.org/browse/JBIDE-21143
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Marián Labuda
> Labels: explorer
> Fix For: 4.3.1.Beta1
>
>
> Actions such as deleting or creating a new project for an OpenShift connection (those which change content of OpenShift Explorer visually) causes refreshing all connection in OpenShift Explorer view - I have spotted it when I was creating a project for a connection of local OpenShift instance and while this project was being shown in OpenShift Explorer view under the connection, a connection to internal OSE instance had been refreshed too and loading tree item was shown underneath.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-20521) Show In - Web Browser is enabled and do nothing when there are no routes
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20521?page=com.atlassian.jira.plugi... ]
Fred Bricon resolved JBIDE-20521.
---------------------------------
Assignee: Fred Bricon
Resolution: Done
A warning message ("Could not find a route that points to an url to show in a browser.") will be displayed if there's nothing to open.
Fixed in master/4.3.x
> Show In - Web Browser is enabled and do nothing when there are no routes
> ------------------------------------------------------------------------
>
> Key: JBIDE-20521
> URL: https://issues.jboss.org/browse/JBIDE-20521
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.CR1
> Reporter: Marián Labuda
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.3.1.Beta1
>
>
> When I am having a project with an application without any route, the Show In - Web Browser context menu of a project is enabled for this project and it does not do anything (after click nothing happens). Context menu should be disable if there are no routes for an application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21145) Component-install job does not reliably install all JBT IUs and so does not see changes between CI builds
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21145?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-21145 at 11/27/15 10:58 AM:
---------------------------------------------------------------
[~psrna] Please define "broken".
[~mlabuda] I see a build from today here:
http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui... (4.3.1-SNAPSHOT (Beta1-v20151124-0059-B142))
That's the same build linked in the composite site http://download.jboss.org/jbosstools/mars/snapshots/updates/
So... looks like the composite install worked a few days ago, but it's missing the latest openshift CI build.
---
Looking into the log [1], I see
{code}
+ tee /mnt/hudson_workspace/workspace/jbosstools-composite-install_master/install.log.txt
Unable to initialize GTK+
Unable to initialize GTK+
Fri Nov 27 09:30:53 EST 2015
334M /mnt/hudson_workspace/workspace/jbosstools-composite-install_master/eclipse/
Unable to initialize GTK+
Fri Nov 27 09:30:53 EST 2015
334M /mnt/hudson_workspace/workspace/jbosstools-composite-install_master/eclipse/
{code}
[1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
Which shows that the install ONLY installed Eclipse, and failed to perform the JBT install (the before/after sizes on disk were the same).
So... I'm going to try to run this again on RHEL6+ instead of RHEL5+ as I'm hoping that will resolve the "Unable to initialize GTK+" problem and allow Eclipse to start properly.
was (Author: nickboldt):
[~psrna] Please define "broken".
[~mlabuda] I see a build from today here:
http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui... (4.3.1-SNAPSHOT (Beta1-v20151124-0059-B142))
That's the same build linked in the composite site http://download.jboss.org/jbosstools/mars/snapshots/updates/
So... looks like the composite install worked a few days ago, but it's missing the latest openshift CI build.
---
Looking into the log, I see
{code}
+ tee /mnt/hudson_workspace/workspace/jbosstools-composite-install_master/install.log.txt
Unable to initialize GTK+
Unable to initialize GTK+
Fri Nov 27 09:30:53 EST 2015
334M /mnt/hudson_workspace/workspace/jbosstools-composite-install_master/eclipse/
Unable to initialize GTK+
Fri Nov 27 09:30:53 EST 2015
334M /mnt/hudson_workspace/workspace/jbosstools-composite-install_master/eclipse/
{code}
Which shows that the install ONLY installed Eclipse, and failed to perform the JBT install (the before/after sizes on disk were the same).
So... I'm going to try to run this again on RHEL6+ instead of RHEL5+ as I'm hoping that will resolve the "Unable to initialize GTK+" problem and allow Eclipse to start properly.
> Component-install job does not reliably install all JBT IUs and so does not see changes between CI builds
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21145
> URL: https://issues.jboss.org/browse/JBIDE-21145
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Pavol Srna
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> We have often seen old artifacts on nightly sites (mars and neon too).
> It seems that the composite-install job [0], [1] is not reliable. So, the downstream JBT aggregate builds [2], [3] are not triggered automatically to pick up all new changes in the upstream JBT component site builds.
> [0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-...
> [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-...
> [2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-site... (latest build shows: "Nov 27, 2015 6:15 AM NOT PUBLISHED: UNCHANGED")
> [3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-site... (latest build shows: "Nov 27, 2015 3:43 AM NOT PUBLISHED: UNCHANGED")
> Please investigate.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month