[JBoss JIRA] (JBDS-4224) Include OpenJDK 1.8.0.111-3.b15 release into installer
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-4224?page=com.atlassian.jira.plugin.... ]
Jan Richter closed JBDS-4224.
-----------------------------
Verified in build 73.
> Include OpenJDK 1.8.0.111-3.b15 release into installer
> ------------------------------------------------------
>
> Key: JBDS-4224
> URL: https://issues.jboss.org/browse/JBDS-4224
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Task
> Components: platform-installer
> Affects Versions: 10.3.0.AM1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 10.3.0.AM2
>
>
> From [~akashche]:
> Public download: https://developers.redhat.com/download-manager/file/java-1.8.0-openjdk-1....
> sha256: d4fa67a45cef119325e9ef775ea53dee0e2754b2df511618f91abf5acda6ddf0
> Notable changes that can affect DevSuite are:
> 1) MSI installer now includes Update Notifier utility. This utility is not installed by default. In installer UI form with installation directory chooser is changed, but should behave the same (jdk installed into default directory, notifier not installed) on default "Next" action.
> For silent install MSI now contains two named "installation features": "jdk" and "update_notifier". msiexec invocation without specifying features:
> msiexec /quiet /i jdk.msi
> should behave the same way if only jdk feature will be specified:
> msiexec /quiet /i jdk.msi ADDLOCAL=jdk
> INSTALLDIR variable also should continue to work.
> To install both jdk and update_notifier (that is probably not needed for DevSuite) the following can be used:
> msiexec /quiet /i jdk.msi ADDLOCAL=jdk,update_notifier
> 2) MSI installer size grew up to 103MB, that is mostly caused not by update_notifier (that is less than 5MB) but by inclusion of additional Java sources into src.zip bundle that is installed into jdk directory. Now debugging of all jdk-internal Java packages (sun.*, com.sun.*) should work in Eclipse.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23769) New Application: Do not throw exception in error log when provided template is of wrong kind.
by Radim Hopp (JIRA)
Radim Hopp created JBIDE-23769:
----------------------------------
Summary: New Application: Do not throw exception in error log when provided template is of wrong kind.
Key: JBIDE-23769
URL: https://issues.jboss.org/browse/JBIDE-23769
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.3.AM1
Reporter: Radim Hopp
Priority: Minor
When creating new application from local template one selects wrong file (not of kind "Template", but kind "Pod" for example) multiple (same) exceptions are thrown into error log:
{noformat}
!ENTRY org.eclipse.core.databinding 4 0 2017-01-19 13:56:20.472
!MESSAGE Unhandled exception: Wrong resource kind: Pod
!STACK 0
org.jboss.tools.openshift.internal.ui.wizard.newapp.NotATemplateException: Wrong resource kind: Pod
at org.jboss.tools.openshift.internal.ui.wizard.newapp.NewApplicationWizardModel.getLocalAppSource(NewApplicationWizardModel.java:139)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.NewApplicationWizardModel.loadAppSource(NewApplicationWizardModel.java:293)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.ApplicationSourceListPage$17.run(ApplicationSourceListPage.java:824)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{noformat}
I think it's enough to inform the user in the wizard (this is already happening).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ERT-479) Javascript Object's prototype property is not supported [EBZ#510677]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-479:
---------------------------------------
Summary: Javascript Object's prototype property is not supported [EBZ#510677]
Key: ERT-479
URL: https://issues.jboss.org/browse/ERT-479
Project: Eclipse Release Train
Issue Type: Task
Components: JSDT
Reporter: Friendly Jira Robot
As we get rid of complex model calculations and type inference in JSDT 2.0, we still have a need to support objects and their properties/functions defined via class prototype property in order to make it possible to correctly show/expand such properties/functions on the Outline as well as to propose/show them in content assistant, searching and for the validation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-23766) ZipException in CDICoreBuilder when indexing some Camel artifacts
by Aurélien Pupier (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23766?page=com.atlassian.jira.plugi... ]
Aurélien Pupier commented on JBIDE-23766:
-----------------------------------------
another thing to try is to configure the maven staging repositories insettings;xml of ;m2 folder: http://download.eng.bos.redhat.com/brewroot/repos/jb-fis-2.0-maven-build/... and http://download.eng.brq.redhat.com/brewroot/repos/jb-fuse-6.2-build/lates...
> ZipException in CDICoreBuilder when indexing some Camel artifacts
> -----------------------------------------------------------------
>
> Key: JBIDE-23766
> URL: https://issues.jboss.org/browse/JBIDE-23766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.4.2.Final
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.4.3.AM2
>
> Attachments: FT_blankBlueprintProj.log, FuseToolingInstalledSW.png, blankBlueprintPomError.png
>
>
> it would be nice to provide more information in log such as teh classes in inspection by CDI Core Builder
> {noformat}
> !ENTRY org.jboss.tools.common.core 4 0 2017-01-17 11:17:20.815
> !MESSAGE invalid LOC header (bad signature)
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:717)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:419)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at java.io.DataInputStream.readFully(DataInputStream.java:195)
> at java.io.DataInputStream.readFully(DataInputStream.java:169)
> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433)
> at org.jboss.jandex.Indexer.index(Indexer.java:689)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months